Counter exit code 139 when running, but gdb make it through

Question

My question sounds specific, but I doubt it still can be of a C++ debug issue.

I am using omnet++ which is to simulate wireless network. omnet++ itself is a c++ program.

I encountered a queer phenomena when I run my program (modified inet framework with omnet++ 4.2.2 in Ubuntu 12.04): the program exit with exit code 139 (people say this means memory fragmentation) when touching a certain part of the codes, when I try to debug, gdb doesn't report anything wrong with the 'problematic' codes where the simulation exits previously, actually, the debug goes through this part of codes and output expected results.

gdb version info: GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04

Could anybody tell me why the run fails but debug doesn't?

Many thanks!

Solution 1

exit code 139 (people say this means memory fragmentation)

No, it means that your program died with signal 11 (SIGSEGV on Linux and most other UNIXes), also known as segmentation fault.

Could anybody tell me why the run fails but debug doesn't?

Your program exhibits undefined behavior, and can do anything (that includes appearing to work correctly sometimes).

Your first step should be running this program under Valgrind, and fixing all errors it reports.

If after doing the above, the program still crashes, then you should let it dump core (ulimit -c unlimited; ./a.out) and then analyze that core dump with GDB: gdb ./a.out core; then use where command.

Solution 2

this error is also caused by null pointer reference. if you are using a pointer who is not initialized then it causes this error.

to check either a pointer is initialized or not you can try something like

Class *pointer = new Class();
if(pointer!=nullptr){
    pointer->myFunction();
}

Comments

[Joseph Mansfield]

Sounds like undefined behaviour. We can't help without seeing the problematic code.

[ulyssis2]

thanks for your quick reply, i am looking for how to run the program in command prompt, i am now stuck by the simulator. I will report back after analyzing with valgrind.

[ulyssis2]

Now I can run and debug the program via command prompt, both run and debug stride over the "problematic codes", then I use eclipse IDE again, I find that in debug mode, it stops at the same place with using command prompt, when I run the program step by step, it also execute through the "problematic codes", but when I run it, program collapses somewhere around the "problematic codes". I guess this is due to IDE, as the GUI itself is also a program, and can not work well under normal run mode. I have no idea why.

[Employed Russian]

@ulyssis2 What does Valgrind say? The program may appear to work outside of IDE, but Valgrind should still tell you about your bug.

[ulyssis2]

Thanks buddy. valgrind does report, but not on the "problematic codes" where "run" with IDE stucks, valgrind reports "Segmentation fault (core dumped)" which happens in the latter part of my codes. That bug relates to unordered map, I am trying to launch a new thread for that.

[Goswin von Brederlow]

When I do *(char*)0 = 0; the program says: Segmentation fault. It doesn't just silently exit(139).