4 ms·

"instead of reading an exception trace, you get to load the actual moment the exception was triggered into your local debugger and pick up from there as if it j

"instead of reading an exception trace, you get to load the actual moment the exception was triggered into your local debugger and pick up from there as if it just happened locally!" I want this.

nitrogen 15y ago
You could do it with C++ by enabling core dumps and wrapping any "throw" statements (or altering the constructor for the exception classes you want to monitor) with an operation that dumps the core. There's also the "gcore" utility I discovered while researching this comment.
Negitivefrags 15y ago
You already have it! This is what our good old friend the core dump is for. Load the core dump in GDB and there you are. I'd argue that on windows it's even easier. You can create a symbol server to store all the debugging info (the PDB files) and the debugger can download the correct symbols for that particular compiled version. The PDB format supports having an arbitrary commands added to procure each source file. You can connect this up to your version control system so that not only do you have the stack and symbols, you can actually browse around the source code of whatever version of the code actually crashed just as if it had crashed locally. On linux you have to work out a system for archiving your symbols and getting them for the correct version of your software yourself, but the effort is certainly worth it. We have a system to generate HTML reports each day by grouping crash dumps by the functions near the top of the stack (if the top 5 functions are the same, it's considered the same crash), so each day we can see what the most important crash is.
- drothlis 15y ago
  Except for the article's steps 3 & 4: 3. You enter some code and hit proceed 4. The app continues like nothing happened A short (<3min) video demoing the same: http://vimeo.com/27850933 http://vimeo.com/27850933
- pnathan 15y ago
  Yeah, when a native app crashes, it just dies. Whereas, generally with Common Lisp, I can trap the condition, fix the problem, and keep running. I know what languages I'd consider starting grounds for 100% uptime systems (not 5 9s), and languages that segfault and die as part of their usual crash hangling are not among them. (Erlang, Lisp, and Smalltalk would be my shortlist)
  - bonzoesc 15y ago
    Picking nits here, but (limited) crashing (by design) is exactly why Erlang's failure handling is solid. It's like an automotive crumple zone for your application.
    - william42 15y ago
      An Erlang crash is of an Erlang process, which is a tiny green-thread with shared-nothing. That's very different from a C program segfaulting.
      - bonzoesc 15y ago
        Not if your application is a bunch of small C programs that monitor each other a la DJB.
  - Negitivefrags 15y ago
    On windows at least, this functionality is all available for native code. On linux the situation is a little harder. I am not aware of edit and continue on that platform. Any kind of crash is catchable. For example, we get minidumps of our windows software uploaded by the crashing process by catching any kind of crash that is possible, and handling it. However, I would argue that you want to crash and dump a core as fast as possible when something unanticipated is happening. Process death should not be a problem in a well designed system!

"instead of reading an exception trace, you get to load the actual moment the exception was triggered into your local debugger and pick up from there as if it just happened locally!" I want this.

nitrogen 15y ago

You could do it with C++ by enabling core dumps and wrapping any "throw" statements (or altering the constructor for the exception classes you want to monitor) with an operation that dumps the core. There's also the "gcore" utility I discovered while researching this comment.

Negitivefrags 15y ago

You already have it! This is what our good old friend the core dump is for. Load the core dump in GDB and there you are. I'd argue that on windows it's even easier. You can create a symbol server to store all the debugging info (the PDB files) and the debugger can download the correct symbols for that particular compiled version. The PDB format supports having an arbitrary commands added to procure each source file. You can connect this up to your version control system so that not only do you have the stack and symbols, you can actually browse around the source code of whatever version of the code actually crashed just as if it had crashed locally. On linux you have to work out a system for archiving your symbols and getting them for the correct version of your software yourself, but the effort is certainly worth it. We have a system to generate HTML reports each day by grouping crash dumps by the functions near the top of the stack (if the top 5 functions are the same, it's considered the same crash), so each day we can see what the most important crash is.

drothlis 15y ago
Except for the article's steps 3 & 4: 3. You enter some code and hit proceed 4. The app continues like nothing happened A short (<3min) video demoing the same: http://vimeo.com/27850933 http://vimeo.com/27850933
pnathan 15y ago
Yeah, when a native app crashes, it just dies. Whereas, generally with Common Lisp, I can trap the condition, fix the problem, and keep running. I know what languages I'd consider starting grounds for 100% uptime systems (not 5 9s), and languages that segfault and die as part of their usual crash hangling are not among them. (Erlang, Lisp, and Smalltalk would be my shortlist)
- bonzoesc 15y ago
  Picking nits here, but (limited) crashing (by design) is exactly why Erlang's failure handling is solid. It's like an automotive crumple zone for your application.
  - william42 15y ago
    An Erlang crash is of an Erlang process, which is a tiny green-thread with shared-nothing. That's very different from a C program segfaulting.
    - bonzoesc 15y ago
      Not if your application is a bunch of small C programs that monitor each other a la DJB.
- Negitivefrags 15y ago
  On windows at least, this functionality is all available for native code. On linux the situation is a little harder. I am not aware of edit and continue on that platform. Any kind of crash is catchable. For example, we get minidumps of our windows software uploaded by the crashing process by catching any kind of crash that is possible, and handling it. However, I would argue that you want to crash and dump a core as fast as possible when something unanticipated is happening. Process death should not be a problem in a well designed system!