Incomplete core dump

[ecco]

I have a systemc model that is crashing (I instantiate several submodules, its hard to find exactly where the problem is just by looking at the code). The core is being dumped but it is "incomplete". There is enough space in the hard drive and there is no limit for the size of the core dump file. Nevertheless, an incomplete core dump is being generated which prevents me from finding out exactly where the application crashes.

 

root@ubox:/home/ec/project1# ulimit -a
core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 128077
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 128077
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

root@ubox:/home/ec/project1# gdb main core
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /home/ec/project1/main...done.
BFD: Warning: /home/ec/project1/core is truncated: expected core file size >= 5169152, found: 1114112.
[New LWP 10943]

 

Any ideas on how to solve this?

[dakupoto]

Hello,

Segmentation faults and related core dumps are a real

pain, especially when they are incomplete, and only the

programmer knows the details of the code. The only fool

proof way is to use divide and conquer.

First comment out everything except for a bare minimum

module (SystemC equivalent of standard 'Hello World').

and run it. Then add a few simple modules, compile and

run. Use appropriate stubs as necessary. After a few

iterations, you will reach a stage where addition of one

particular module causes the whole application to

segmentation fault. The problem lies in that module.

Remember what Brian Kernighan, the co-creator of

the C language once said at a conference -- "a few

strategically placed print statements are better than

any goddamn debugger".

Trying to digest the segmentation fault or core dump

message will waste a lot of time, and achieve very

little.

Hope that helps.

 

[maehne]

Hello,

 

Why don't you try to start your SystemC model directly under the control of gdb. If then, the program segfaults, you can do a back trace using the command "bt" to see the call stack. The cause of the segfault is in most cases located in the last function being called that was implemented by you. Watch out for pointers being accessed without verifying, whether they point to valid addresses.

 

Regards, Torsten

[apfitch]

You could try a static analyzer - I managed to find a bug during the regressions of SystemC 2.3 using cppcheck http://cppcheck.sourceforge.net/

 

Also I have had some success running the same simulation on Windows and Linux (if that's possible). The reason seems to be that on Linux, the process memory is cleared to zero, so it can be hard to find uninitialized variables; on Windows, uninitialized pointers and integers seem to start with the most negative 2's complement number which can be easier to spot,

 

regards

Alan