ecco Posted July 20, 2013 Report Posted July 20, 2013 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? Quote
dakupoto Posted July 21, 2013 Report Posted July 21, 2013 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. Quote
maehne Posted July 23, 2013 Report Posted July 23, 2013 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 1 Quote
apfitch Posted July 23, 2013 Report Posted July 23, 2013 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 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.