CrashLog explained?

4 posts / 0 new

Log in or register to post comments

Last post

Sat, 2020-11-28 18:08

#1

walkero

walkero's picture

Offline

Last seen: 3 months 2 weeks 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.

Sun, 2020-11-29 09:34

#2

kas1e

kas1e's picture

Offline

Last seen: 3 months 3 days 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.

Mon, 2020-11-30 16:34

#3

walkero

walkero's picture

Offline

Last seen: 3 months 2 weeks 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?

Tue, 2020-12-01 18:37

(Reply to #3) #4

hypex

hypex's picture

Offline

Last seen: 3 months 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:

Crash log for task "Bad byte"
Generated by GrimReaper 53.19
Crash occured in module test at address 0x7BB752EC
Type of crash: DSI (Data Storage Interrupt) exception
Alert number: 0x80000003
 
Register dump:
GPR (General Purpose Registers):
   0: 00000000 46F57DC0 323D4A58 00000000 46F57E84 00000000 00000000 00000103 
   8: 00000000 00000000 00000005 02963054 33953995 C5C5C5C5 46E4CAE4 4A19A880 
  16: 02B20000 DF784850 02B20000 00000000 46E4CAE0 00000000 49EB96A0 7BB88090 
  24: 46E4CA98 00000000 FFFFFFFF 02A7B092 46E4CAE0 00000000 0280652C 46F57DC0 
 
SPRs (Special Purpose Registers):
           Machine State (msr) : 0x0000F030
                Condition (cr) : 0x45368DA0
      Instruction Pointer (ip) : 0x7BB752EC
       Xtended Exception (xer) : 0x02027504
                   Count (ctr) : 0x00000000
                     Link (lr) : 0x00000000
            DSI Status (dsisr) : 0x02046428
            Data Address (dar) : 0x00000000
 
Symbol info:
Instruction pointer 0x7BB752EC belongs to module "test" (HUNK/Kickstart)
 
Stack trace:
    module test at 0x7BB752EC (section 4 @ 0x342C8)
    module test at 0x7BB7A9D0 (section 4 @ 0x399AC)
    module test at 0x7BB7CA24 (section 4 @ 0x3BA00)
    module test at 0x7BB87BF0 (section 4 @ 0x46BCC)
    module test at 0x7BB88348 (section 4 @ 0x47324)
    native kernel module dos.library.kmod+0x000255c8
    native kernel module kernel+0x000420ac
    native kernel module kernel+0x000420f4
 
PPC disassembly:
 7bb752e4: 801f0028   lwz               r0,40(r31)
 7bb752e8: 7d290214   add               r9,r9,r0
*7bb752ec: 88090000   lbz               r0,0(r9)
 7bb752f0: 5400063e   rlwinm            r0,r0,0,24,31
 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