...

...

Anchor
_82h6p1c2zt5d _82h6p1c2zt5d

Gdb Crash Dump Guide

Anchor
_hu4xv4bc83aa _hu4xv4bc83aa

Analysing Crash Dumps

Anchor
_mw2vxxf7vimc _mw2vxxf7vimc

Initiating GDB

Command:

Prompt $ sudo gdb <executable> <corefile>

...

Here we can see we died with a SIGSEGV, Segmentation fault in /lib/x86_64-linux-gnu/libc.so.6

Anchor
_u8i4bilunxwl _u8i4bilunxwl

Visual Mode

Or use the additional switch -tui to enter visual mode e.g.

...

Using select <n> will switch to stack frame N and handily show the source associated with that frame.

Anchor
_v4jydm84gkyu _v4jydm84gkyu

If it’s a Segfault - what’s the referenced address:

The _siginfo structure provides this

(gdb) print $_siginfo._sifields._sigfault.si_addr

Anchor
_163uvq1uclyn _163uvq1uclyn

Looking at the stack (backtrace)

Command:

(gdb) bt

Or

(gdb) backtrace

...

Where we see that ippe_debug_print caused the crash and the offending line was 13627 of /tmp/Default.c - which is the temporary file created by ./peplc default_Enterprise.pepl - the Default comes from the module name at the top of this pepl source file

Anchor
_9cv1tfxc0yja _9cv1tfxc0yja

Full Stack Traces (bt full)

Sometimes the brief backtrace just doesn’t offer enough and we want a full backtrace

...

This gives much more information about the parameter passed etc, unfortunately in the case of IPPERTE/PEPL much is optimised out

Anchor
_c5hdmbypwyh6 _c5hdmbypwyh6

Equating c names to pepl names

Anchor
_qjfo5ifun4zi _qjfo5ifun4zi

C Function names to PEPL Class and Procs

There’s no exact way of doing this for scalar variables the pepl and c variable names are identical for example in frame 5 of bt full above:

...

So now we clearly know what pepl proc was running at the time of the problem. Stack frame 4 tells us that the pepl had called: ippe_register_port

Anchor
_cgum1iy1y3mp _cgum1iy1y3mp

Internal Function names

So from the above we see that the function ippe_register_port was called, but in our PEPL source code there is no such call. Of course we might guess that’s it’ll be related to port registration but there is a way to be more certain:

...

Port_Out_Id = registerPort(Port_Out, False, True)

Anchor
_bk1vaos9mbgw _bk1vaos9mbgw

Variable names

Variables in PEPL generally match closely to their C names. Here are some variables defined half way into the PEPL proc UserInput in the class we are using as an example Symmetric_Routing

...

What happened to the variable declared as: Number i - it is not in the c struct? The answer to this is that it was never used and so PEPL optimised it out.

Anchor
_v2bzimkk4n4k _v2bzimkk4n4k

Displaying Variable Contents

While bt full will show you the values of variables in the stack frames - which is good sometimes we want to see the contents of memory, where available:

...

Show whether gdb stops printing an array on the first null character.

Anchor
_69jzjoffzur9 _69jzjoffzur9

Printing stdin and stdout

It can be useful to see what’s just been input or output (note for the ipperte for this may give a good clue as the last command processed and therefore the time…):

...

_vtable_offset = 0 '\000', _shortbuf = "", _lock = 0x7f59373829e0, _offset = -1, __pad1 = 0x0, __pad2 = 0x7f59373814e0, __pad3 = 0x0, __pad4 = 0x0, __pad5 = 0, _mode = -1, _unused2 = '\000' <repeats 19 times>

Anchor
_5n425ck9cumg _5n425ck9cumg

Moving around the stack

Sometimes we want to inspect variables in stack frames other than 0, to do this we can use the command select <n> to change reference to a different stack frame e.g.

...