OMNeT++/OMNEST Bug Tracker - OMNeT++
View Issue Details
0000161OMNeT++IDE / C++ developmentpublic2010-04-30 13:022010-05-18 15:11
0000161: gdb fails when started from the IDE with "unknown target exception 0xc0000135 at 0x7c9766c6"
I experience an issue in OMNeT++ 4.1 beta4. Thought the
issue in Ticket 146 ( [^])
seems to be solved in 4.1b4, the debugger is still unusable at the mingw

I cannot debug programs as gbd exits with
gdb: unknown target exception 0xc0000135 at 0x7c9766c6

The environment set up by eclipse may have influence on the
issue as I can debug the program by using gdb at the command line
provided by "mingwenv.cmd":

$ gdb ../src/myprog.exe
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later < [^]
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<>... [^]
Reading symbols from d:\sim\myprog\simulations/../src/
(gdb) run
Starting program: d:\sim\myprog\simulations/../src/myprog.exe
[New Thread 4920.0x4e0]
OMNeT++ Discrete Event Simulation (C) 1992-2010 Andras Varga, OpenSim
Version: 4.1b4, build: 100421-6ff37b9, edition: Academic Public
See the license for distribution terms and warranty disclaimer
Setting up Tkenv...
Loading NED files from d:\sim\foo\src: 169
Loading NED files from d:\sim\myprog\src: 91
[New Thread 4920.0x1ec]
[New Thread 4920.0x11b4]
[New Thread 4920.0x1508]
[New Thread 4920.0xe00]


Program exited normally.
(gdb) quit

No tags attached.
txt out.txt (5,648) 2010-04-30 13:18
Issue History
2010-04-30 13:02tobiasNew Issue
2010-04-30 13:08rhornigNote Added: 0000263
2010-04-30 13:15rhornigNote Added: 0000264
2010-04-30 13:18tobiasFile Added: out.txt
2010-04-30 13:19tobiasNote Added: 0000265
2010-04-30 14:01rhornigNote Added: 0000266
2010-04-30 16:58rhornigNote Added: 0000267
2010-05-03 11:18tobiasNote Added: 0000268
2010-05-11 14:34rhornigNote Added: 0000298
2010-05-18 15:11rhornigNote Added: 0000301
2010-05-18 15:11rhornigStatusnew => resolved
2010-05-18 15:11rhornigFixed in Version => 4.1rc1
2010-05-18 15:11rhornigResolutionopen => fixed
2010-05-18 15:11rhornigAssigned To => rhornig

2010-04-30 13:08   
I've just checked this in 4.1b4 and the debugger seems to work correctly from the IDE too.
- Installed ometpp 4.1b4
- Opened the aloha project
- Set a breakpoint in the server module's handleMessage
- Run the program in debug mode.

Everything was working correctly.

- Could you please try debugging the ALOHA example too?
Let's see if that is working.
2010-04-30 13:15   
This issue seems to be related to this: [^]
2010-04-30 13:19   
I have added the verbose output from the eclipse console in "out.txt" using the Aloha example, HTH.
2010-04-30 14:01   
The 0xc0000135 error code means: DLL NOT FOUND. i.e. gdb cannot load the dlls required by the program.

Another related issue: [^]
2010-04-30 16:58   
We've figured out what happened. Do you start the omnetpp IDE from the mingw console window or you have created a shortcut on the desktop?

It seems that this gdb version ignores the "set environment" commands so the started program's path does not contain the omnetpproot/bin directory. That's why it cannot find the DLLs and gdb cannot start it.

If this is the case, there are two workarounds:
- start the IDE from mingw console.
- set your global windows PATH to include omnetpp/bin, omnetpp/msys/bin and omnetpp/mingw/bin

We will report this problem to the mingw/gdb team and also to CDT people, but it is outside of our control.
2010-05-03 11:18   
Great, that trick did it! Thank you very much.
2010-05-11 14:34   
Ok. it still causing problems. If a project is using several DLLs (e.g MiXM), gdb cannot set the path correctly. Even specifying the above bin directories do not help... See the following bugs in gcc/mingw and CDT: [^] [^]

At the moment we should either revert to gdb 6.6 or somehow patch the CDT launcher to include the environment correctly.
2010-05-18 15:11   
gdb has been downgraded to version 6.6 which was the last version without the mentioned problem (this version was shipped with OMNET4.0). The downgrade should resolve the debugging issue.