5 ms·

What is a core dump and how do you parse one?

118 points by sbahra 11y ago

dekhn 11y ago
A core dump is when your transistor-based computer has a fault and has to dump the magnetic cores to tape. You parse it by running a magnetometer along the tape to read the values. Real programmers just harness gamma rays directly.
- kylek 11y ago
  There's probably an emacs command for that (https://xkcd.com/378/ https://xkcd.com/378/)
- mutagen 11y ago
  What will core dumps look like for a quantum computer?
  - johncolanduoni 11y ago
    Well, if you looked at it then you've already destroyed it.
    - FroshKiller 11y ago
      Not exactly. You just can't know the state of every register at once.
kruhft 11y ago
gdb program core Assuming you compiled with -g, this might or might not be useful.
- bsilvereagle 11y ago
  For some architectures & compilers, you need -ggdb, not just -g.
kleer001 11y ago
tl;dr OP shows you what a core dump is and how to parse it.
DonHopkins 11y ago
Sun's "desktop productivity" tools for OpenWindows supported core dumps really well. The file manager skeuomorphically showed a core dump as a red bomb. You could effortlessly double click on the bomb, and it would predictably attempt to load it into the XView text editor, which would then intuitively explode, replacing the core dump with an even bigger, more sophisticated core dump.
dap 11y ago
Great post on the structure of core files. It feels like a lot of people have an allergic reaction to core files. (Maybe because they remind you that your program just crashed? Or because they seem to take superhuman understanding to work with?) What's great about them is that they decouple the debugging process from restoring service. In production, when something's broken and you have a hunch will be fine if you restart it, you can save a core file, restart it, restore service, then debug it. In dev and test, when another dev or tester runs into a bug in your area, they can just send you a core file instead of waiting for you to drop everything and debug it right away.
- sbahra 11y ago
  Glad you liked it. Unfortunately, core files can be massive and require you to have a lot of the assets from the environment the fault occurred in to debug. Last but not least, it would be good if they gave us more of a head-start on root cause. These are all things we're directly tackling at Backtrace.
  - dap 11y ago
    That sounds interesting. I heard about you all through Abel at Surge last month and I'm looking forward to checking that out. I work primarily on illumos, where we do dump program text, and we're working on getting CTF everywhere. It's almost always possible to debug without the original binaries and usually on different systems as well.
    - sbahra 11y ago
      Oh, cool! We hope to publish something soon on this. ;-) It would be great to learn more about the work you're doing.
peter303 11y ago
It was the dreaded "thick printed output" in ancient days of IBM mainframes. It meant your program crashed overnight. In the old days you batch compiled and batch ran your program from punch card job deck. If you were a poor student you probably ran your jobs at night because your dollars went three times farther then. Researchers on fat government grants and school administration could afford day runs. For the most part these dumps werent too useful beyond the contents of machine registers. You could probably figure out where you died in the code. If you were computing a scientific array of numbers in memory you could probably see how the computation got and whether it was generating garbage. Also in the old days you bought like 16 kilobytes or 64 kilobytes of core, so a full dump printout was super large. I think you could tailor the format of the dump with the Job Control Language. But I dont remember.
mcguire 11y ago
And for your next trick, undump: convert the core file into an executable program which recreates the process in the same state it was originally dumped (nearly).
- bbanyc 11y ago
  This was (is?) a step in compiling Emacs. Compile the C code into an uninitialized binary of the Lisp interpreter, start the interpreter, load in a bunch of Lisp code, dump core, then undump the core into /usr/bin/emacs.
  - mcguire 11y ago
    And many other Lisps like Franz and AKCL/GCL.
todd8 11y ago
After about a month of trying to debug a real-time process control program written in assembler by my boss, I had to resort to desperate measures. The program was about 150 pages long and written in unstructured assembly language. It ran on a minicomputer with the company's own operating system. The program controlled a machine full of hydrofluoric acid that etched semiconductor chips on big slices of silicon. It was a real-time program with a few dozen asynchronous parts and couldn't be slowed down because of the process machinery that it ran. If it wasn't for the other junior programmer assigned to the project, I might have just given up in despair, but the two of us would come in on weekends when the clean room was down and crank up the program and look for problems in its execution. We finally debugged the problems by taking a much larger computer with a fast line printer and used it to do direct memory access to the minicomputer, hex dumping the section of memory containing the bad program's data structures as fast as the line printer could print the pages. By calling out to me what was going on with the silicon etch machine I could annotate our core dumps as they printed and we could go back to our desks with the 9 inch thick listing and figure out what was going wrong. Those were the days (1976).
femngi 11y ago
How does this Backtrace file format differ from Microsoft's Minidump format which is also used on Unix as part of Breakpad?

118 points by sbahra 11y ago

dekhn 11y ago

A core dump is when your transistor-based computer has a fault and has to dump the magnetic cores to tape. You parse it by running a magnetometer along the tape to read the values. Real programmers just harness gamma rays directly.

kylek 11y ago
There's probably an emacs command for that (https://xkcd.com/378/ https://xkcd.com/378/)
mutagen 11y ago
What will core dumps look like for a quantum computer?
- johncolanduoni 11y ago
  Well, if you looked at it then you've already destroyed it.
  - FroshKiller 11y ago
    Not exactly. You just can't know the state of every register at once.

kruhft 11y ago

gdb program core Assuming you compiled with -g, this might or might not be useful.

bsilvereagle 11y ago
For some architectures & compilers, you need -ggdb, not just -g.

kleer001 11y ago

tl;dr OP shows you what a core dump is and how to parse it.

DonHopkins 11y ago

Sun's "desktop productivity" tools for OpenWindows supported core dumps really well. The file manager skeuomorphically showed a core dump as a red bomb. You could effortlessly double click on the bomb, and it would predictably attempt to load it into the XView text editor, which would then intuitively explode, replacing the core dump with an even bigger, more sophisticated core dump.

dap 11y ago

Great post on the structure of core files. It feels like a lot of people have an allergic reaction to core files. (Maybe because they remind you that your program just crashed? Or because they seem to take superhuman understanding to work with?) What's great about them is that they decouple the debugging process from restoring service. In production, when something's broken and you have a hunch will be fine if you restart it, you can save a core file, restart it, restore service, then debug it. In dev and test, when another dev or tester runs into a bug in your area, they can just send you a core file instead of waiting for you to drop everything and debug it right away.

sbahra 11y ago
Glad you liked it. Unfortunately, core files can be massive and require you to have a lot of the assets from the environment the fault occurred in to debug. Last but not least, it would be good if they gave us more of a head-start on root cause. These are all things we're directly tackling at Backtrace.
- dap 11y ago
  That sounds interesting. I heard about you all through Abel at Surge last month and I'm looking forward to checking that out. I work primarily on illumos, where we do dump program text, and we're working on getting CTF everywhere. It's almost always possible to debug without the original binaries and usually on different systems as well.
  - sbahra 11y ago
    Oh, cool! We hope to publish something soon on this. ;-) It would be great to learn more about the work you're doing.

peter303 11y ago

It was the dreaded "thick printed output" in ancient days of IBM mainframes. It meant your program crashed overnight. In the old days you batch compiled and batch ran your program from punch card job deck. If you were a poor student you probably ran your jobs at night because your dollars went three times farther then. Researchers on fat government grants and school administration could afford day runs. For the most part these dumps werent too useful beyond the contents of machine registers. You could probably figure out where you died in the code. If you were computing a scientific array of numbers in memory you could probably see how the computation got and whether it was generating garbage. Also in the old days you bought like 16 kilobytes or 64 kilobytes of core, so a full dump printout was super large. I think you could tailor the format of the dump with the Job Control Language. But I dont remember.

mcguire 11y ago

And for your next trick, undump: convert the core file into an executable program which recreates the process in the same state it was originally dumped (nearly).

bbanyc 11y ago
This was (is?) a step in compiling Emacs. Compile the C code into an uninitialized binary of the Lisp interpreter, start the interpreter, load in a bunch of Lisp code, dump core, then undump the core into /usr/bin/emacs.
- mcguire 11y ago
  And many other Lisps like Franz and AKCL/GCL.

todd8 11y ago

After about a month of trying to debug a real-time process control program written in assembler by my boss, I had to resort to desperate measures. The program was about 150 pages long and written in unstructured assembly language. It ran on a minicomputer with the company's own operating system. The program controlled a machine full of hydrofluoric acid that etched semiconductor chips on big slices of silicon. It was a real-time program with a few dozen asynchronous parts and couldn't be slowed down because of the process machinery that it ran. If it wasn't for the other junior programmer assigned to the project, I might have just given up in despair, but the two of us would come in on weekends when the clean room was down and crank up the program and look for problems in its execution. We finally debugged the problems by taking a much larger computer with a fast line printer and used it to do direct memory access to the minicomputer, hex dumping the section of memory containing the bad program's data structures as fast as the line printer could print the pages. By calling out to me what was going on with the silicon etch machine I could annotate our core dumps as they printed and we could go back to our desks with the 9 inch thick listing and figure out what was going wrong. Those were the days (1976).

femngi 11y ago

How does this Backtrace file format differ from Microsoft's Minidump format which is also used on Unix as part of Breakpad?