Strange behavior with Eclipse (or Terminal) debugging in INETMANET

[Shezi A]

Dear all, 

I hope everyone is doing well. I have been experiencing a strange behavior with my INETMANET debugging

I have been modifying the DSR protocol under Manet Routing. 

I am logging different Network readings from various nodes in a multi-hop communication. 

My program runs fine without any problems with all the data being correctly logged until the end of the simulation. 

However in the Eclipse debug mode when i reach a certain breakpoint. After a few number of step Overs or step Intos the program abruptly stops with the Segmentation Fault. As follows:

<terminated>ceeqos_esi (1) [OMNeT++ Simulation]

<terminated>gdb/mi (2/13/13 6:10 PM) (Exited. Signal 'SIGSEGV' received. Description: Segmentation fault.)

<terminated, exit value: 0>gdb (2/13/13 6:10 PM)

<terminated, exit value: 0>/home/shezi/omnetpp-4.2.2/bin/opp_run (2/13/13 6:10 PM)

In the past, whenever I had faced Segmentation fault I have switched to the terminal based gdb debugger and then, when the Segmentation Fault occurs i would usually backtrace to the source of problem. 

Only this time however, the gdb debugger runs fine when i perform the same debugging steps via Terminal. The program finishes as follows:

Run till exit from #0  CommonStringPool::~CommonStringPool (

    this=0x7ffff7309240 <cResultListener::getPooled(char const*)::namesPool>, 

    __in_chrg=<optimized out>) at stringpool.cc:27

__run_exit_handlers (status=0, listp=0x7ffff5b626a8 <__exit_funcs>, 

    run_list_atexit=true) at exit.c:79

79 exit.c: No such file or directory.

(gdb) step

46 in exit.c

(gdb) finish

Run till exit from #0  __run_exit_handlers (status=0, 

    listp=0x7ffff5b626a8 <__exit_funcs>, run_list_atexit=true) at exit.c:46

[Inferior 1 (process 18290) exited normally]

So, to conclude the program is apparently running normal (checked from my log files), and so is the gdb debugger via Terminal but the Eclipse debugger crashes once I perform Debug Steps after reaching a certain breakpoint (I have tried changing breakpoints, but in vein). 

Any guidance in this matter is highly appreciated. 

Thank you in advance for your time and kind assistance.

Kind regards, 

Shezi

[Rudolf Hornig]

I'm not exactly sure, but am I seeing it right that when this happen you did not get a backtrace but the whole debugging process has stopped? I.e. it seems that gdb itself has crashed and not the debugged program?

I have only a single guess. The debugger in 4.2.2 has pretty printers enabled, and we have experienced that sometimes the debugger can go berserk and crash when those pretty printers are executed. If you have enabled them manually (see misc/gdb folder in omnetpp) try to disable them. If you are on windows, the pretty printers are enabled by default (in this case rename the .gdbinit file to something else in the omnetpp root). This will disable the pretty printers...

Just a guess, but pretty printers are the only major difference between the gdb started from eclipse and from the terminal.

Rudolf