0

c++ program terminated with no exceptions or stacktrace

I have a multi threaded application

If one of my threads has an access violation with reading out of bounds on an array (or any seg fault condition) my entire application immediately terminates.

If this happens on my windows counter part using visual studio I get a nice stacktrace of where the error was, and what the issue was.

I desperately need this type of debugging environment to be able to succeed at my project. I have too many threads and too many developers running different parts of the project to have one person not handle an exception properly and it destroys the entire project.

I am running Fedora Core 14 I am compiling with gcc 4.5.1 gdb is fedora 7.2-16.fc14 My IDE is eclipse Juno I am using the CDT builder my toolchain is the cross GCC and my builder is the CDT Internal Builder

Is there ANY setting for the gdb or gcc or eclipse that will help me detect these type of situations?

GregM
  • 3,624
  • 3
  • 35
  • 51

2 Answers2

2

That's what's supposed to happen. Under Unix, you get a full core dump (which you can examine in the debugger), provided you've authorized them. (ulimits -c—traditionally, they were authorized by default, but Linux seems to have changed this.)

Of course, to get any useful information from the core dump, you'll need to have compiled the code with symbol information, and not stripped it later. (On the other hand, you can copy the core dump from your users machine onto your development machine, and see what happened there.)

James Kanze
  • 150,581
  • 18
  • 184
  • 329
  • interesting... I haven't seen that before - I am guessing you mean ulimit not ulimits according to this page I need to do somthing to enable it - of course my profile file doesn't contain anything to do with ulimit though... http://en.linuxreviews.org/HOWTO_enable_core-dumps if I do the command you suggestion (minus the plural) it returns 0 – GregM Mar 19 '13 at 15:29
  • 1
    Value `0` means, that core dumps are disabled. If you want them enabled only for a single program, then there's no need to edit your profile. Simply run `ulimit -c unlimited` from a terminal and core dumps will be enabled for programs executed from this terminal only. – v154c1 Mar 19 '13 at 15:52
  • I followed this http://www.akadia.com/services/ora_enable_core.html to enable my core dumps after a restart and doing ulimit -a I can see I now have unlimited as my -c. at this point when it crashes I get a core dump file next to my executable - I can then run gdb against my binary and against my dump file like it states here http://stackoverflow.com/questions/5115613/core-dump-file-analysis – GregM Mar 19 '13 at 16:02
0

You're definitely looking for core dumps, as James Kanze wrote.

I would just add that core dumps will show you where the program crashed, which is not necessarily the same place as where the problem (memory corruption etc.) occurred. And of course some out-of-bounds reads/writes may not exhibit themselves by crashing immediately.

You can narrow the search by enabling check for incorrect memory allocations/deallocations in glibc. The simplest way is to set environmental variable MALLOC_CHECK_. Set it to 2 and glibc will check for heap corruption with every memory allocation/deallocation and abort the program when it founds any problem (producing a core dump, if enabled). This often helps to get closer to the real problem.

http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html

v154c1
  • 1,698
  • 11
  • 19
  • For problems like heap corruption, he should really use ValGrind. – James Kanze Mar 19 '13 at 17:46
  • Right, ValGrind will show much more info and is generally much stronger tool. But it slows the execution down considerably and some bugs (especially in multi-threaded environment, e.g. race-conditions) simply won't exhibit. I usually prefer using 'lighter' tools unless I really need the heavy ones. But I agree that ValGrind is much more powerful. – v154c1 Mar 19 '13 at 19:02