CrashLog explained?

4 posts / 0 new
Last post
walkero
walkero's picture
Offline
Last seen: 3 months 2 days ago
Joined: 2009-05-03 16:54
CrashLog explained?

Hello guys,
I am trying to understand how I can use a crashlog to find were the problem is on my programs. Is there any documentation anywhere that gives some information on how to use that information? I checked the wiki.amigaos.net and couldn't find something there.

Thanks for your help.

kas1e
kas1e's picture
Offline
Last seen: 1 year 5 months ago
Joined: 2010-11-30 15:30
Re: CrashLog explained?

There still some information on the wiki: check the Tutorials/Debugging section.

But not sure if it will help to understand why the app crashes. Usually, most of the important info non-developer or just a C developer can get, is a stack trace (when app builds with -gstab, meaning debug information stored in binary, and GR can get it to the stack trace with the pointing out on the source file and line where it crashes).

Then, all other information is mostly for developers: some values in some registers may help to understand what kind of crash happens (null pointer crash, or something else). PPC disassembly may also point to something. But that all for a low-level developer who knows assembler and internals of the memory layouts, heap constructions, how a stack works, and so on.

walkero
walkero's picture
Offline
Last seen: 3 months 2 days ago
Joined: 2009-05-03 16:54
Re: CrashLog explained?

Thanks kas1e for your reply.
I also found your comment at https://www.os4coding.net/comment/986#comment-986 which seems to cover some part of the changelog output.
It seems both memguard and GrimReaper output similar information, or am I completely wrong?

hypex
hypex's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 2011-09-09 16:20
Re: CrashLog explained?

It does help knowing some machine language. And common PPC instructions for loading and storing. But here is a sample crash log for examination:

  1. Crash log for task "Bad byte"
  2. Generated by GrimReaper 53.19
  3. Crash occured in module test at address 0x7BB752EC
  4. Type of crash: DSI (Data Storage Interrupt) exception
  5. Alert number: 0x80000003
  6.  
  7. Register dump:
  8. GPR (General Purpose Registers):
  9. 0: 00000000 46F57DC0 323D4A58 00000000 46F57E84 00000000 00000000 00000103
  10. 8: 00000000 00000000 00000005 02963054 33953995 C5C5C5C5 46E4CAE4 4A19A880
  11. 16: 02B20000 DF784850 02B20000 00000000 46E4CAE0 00000000 49EB96A0 7BB88090
  12. 24: 46E4CA98 00000000 FFFFFFFF 02A7B092 46E4CAE0 00000000 0280652C 46F57DC0
  13.  
  14. SPRs (Special Purpose Registers):
  15. Machine State (msr) : 0x0000F030
  16. Condition (cr) : 0x45368DA0
  17. Instruction Pointer (ip) : 0x7BB752EC
  18. Xtended Exception (xer) : 0x02027504
  19. Count (ctr) : 0x00000000
  20. Link (lr) : 0x00000000
  21. DSI Status (dsisr) : 0x02046428
  22. Data Address (dar) : 0x00000000
  23.  
  24. Symbol info:
  25. Instruction pointer 0x7BB752EC belongs to module "test" (HUNK/Kickstart)
  26.  
  27. Stack trace:
  28. module test at 0x7BB752EC (section 4 @ 0x342C8)
  29. module test at 0x7BB7A9D0 (section 4 @ 0x399AC)
  30. module test at 0x7BB7CA24 (section 4 @ 0x3BA00)
  31. module test at 0x7BB87BF0 (section 4 @ 0x46BCC)
  32. module test at 0x7BB88348 (section 4 @ 0x47324)
  33. native kernel module dos.library.kmod+0x000255c8
  34. native kernel module kernel+0x000420ac
  35. native kernel module kernel+0x000420f4
  36.  
  37. PPC disassembly:
  38. 7bb752e4: 801f0028 lwz r0,40(r31)
  39. 7bb752e8: 7d290214 add r9,r9,r0
  40. *7bb752ec: 88090000 lbz r0,0(r9)
  41. 7bb752f0: 5400063e rlwinm r0,r0,0,24,31
  42. 7bb752f4: 7c030378 mr r3,r0

This is stripped slightly to focus on relevant sections.

Now we can see the task and type at the top. This one is a common DSI (Data Storage Interrupt) exception. Which translates to an illegal memory address. This could be unmapped memory, a bad address or even a null pointer. We see here the Data Address (dar) is zero. So this one was a null pointer. (Note that on the X1000 I have found the DSI to contain mismatched data.)

The Instruction Pointer (ip) contains the address of the offending instruction.

The Stack trace is top down. On top the last address it found pointing to the crash. On bottom the first address leading up to the crash.

The PPC disassembly lists the bad code. Pointed to by an asterix. In this case it was an lbz, a byte load from register r9, offset zero. If we check r9 in the Register dump we can confirm it contains a zero. Therefore, it tried to read a byte from address zero. An illegal operation. Easily caught on OS4/PPC. Easily missed on OS3/68K.

If your binary has debug symbols these will also be showed. Usually as function name and offset from entry. Which can help to narrow it down to where it crashed and with what.

Log in or register to post comments