Setting a breakpoint causes the application to crash

[BitFlipper]

If I start debugging an application and then set a breakpoint anywhere from within VS in the source code, the application seems to crash immediately. VS then shows the following page:

“Source Not Available”, “Code not running”, “The current thread is not currently running code or the call stack could not be obtained”.

According to the debugger it is still “running”, however it is unresponsive and a connection I had open to it from another application (client/server application) is immediately closed.

However if I put the breakpoint in the source code before I start debugging it, the breakpoint is hit and I can step through code and set/clear other breakpoints. However as soon as I then run the application again, placing any other breakpoints will once again immediately kill it.

I’m using VGDB 3.1, Windows 7, Visual Studio 2012, Linux target with GDB 7.3-0.6.1.

Any ideas?

[ket]

Hi,

What happens if you press on ‘Break all’ during execution?

[BitFlipper]

@ket wrote:

Hi,

What happens if you press on ‘Break all’ during execution?

In that case VS acts as if I stopped debugging altogether. The application exists and my client application also loses the connection immediately. I turned on GDB logging and saw there were some library issues, see the log output below. I’m not interested in debugging the libraries without debug info so in theory it should not matter. Maybe someone with more experience with this can suggest a way to resolve this. I will try the “zipper” commands as shown below in the meantime.

&"Missing separate debuginfo for /lib64/libm.so.6n"
&"Try: zypper install -C "debuginfo(build-id)=b10c3cae031ba5a87e715c117a83cd3bef83ebd2"n"
&"Missing separate debuginfo for /lib64/librt.so.1n"
&"Try: zypper install -C "debuginfo(build-id)=44612b93c19e6567318299411987b113d2387081"n"
&"Missing separate debuginfo for /lib64/libdl.so.2n"
&"Try: zypper install -C "debuginfo(build-id)=3e4f6bfee9fdf77ca975b77b8c325347d9228bb8"n"
&"Missing separate debuginfo for /lib64/libpthread.so.0n"
&"Try: zypper install -C "debuginfo(build-id)=368b7757bc9f9d7e2e93678c63cb3e5587a9934f"n"
~"[Thread debugging using libthread_db enabled]n"
&"Missing separate debuginfo for /lib64/libc.so.6n"
&"Try: zypper install -C "debuginfo(build-id)=72e7b043935a2bd0b80d325f7f166a132cf37140"n"
~"Stopped due to shared library eventn"
*stopped,thread-id="1",stopped-threads="all",core="0"
-break-list
^done,BreakpointTable={nr_rows="0",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[]}
info shared
&"info sharedn"
~"From                To                  Syms Read   Shared Object Libraryn"
~"0x00007ffff7ddeb00  0x00007ffff7df6514  Yes         /lib64/ld-linux-x86-64.so.2n"
~"0x00007ffff7b69580  0x00007ffff7ba5a58  Yes         /lib64/libm.so.6n"
~"0x00007ffff795e2e0  0x00007ffff7961e38  Yes         /lib64/librt.so.1n"
~"0x00007ffff7758df0  0x00007ffff7759948  Yes         /lib64/libdl.so.2n"
~"0x00007ffff75403f0  0x00007ffff754c358  Yes         /lib64/libpthread.so.0n"
~"0x00007ffff71e58c0  0x00007ffff72e8ef8  Yes         /lib64/libc.so.6n"
^done
-exec-continue
^running
*running,thread-id="1"
=thread-created,id="2",group-id="i1"
~"[New Thread 0x7ffff6e85700 (LWP 21692)]n"
*running,thread-id="all"
=thread-created,id="3",group-id="i1"
~"[New Thread 0x7ffff67ba700 (LWP 21693)]n"
*running,thread-id="all"
~"[Thread 0x7ffff67ba700 (LWP 21693) exited]n"
=thread-exited,id="3",group-id="i1"
~"[Thread 0x7ffff6e85700 (LWP 21692) exited]n"
=thread-exited,id="2",group-id="i1"
=thread-exited,id="1",group-id="i1"
=thread-group-exited,id="i1"
*stopped,reason="signal-received",signal-name="SIGPWR",signal-meaning="Power fail/restart",reason="signal-received",signal-name="SIGXCPU",signal-meaning="CPU time limit exceeded",reason="signal-received",signal-name="SIGPWR",signal-meaning="Power fail/restart",reason="signal-received",signal-name="SIGXCPU",signal-meaning="CPU time limit exceeded",reason="signal-received",signal-name="SIGPWR",signal-meaning="Power fail/restart",reason="signal-received",signal-name="SIGXCPU",signal-meaning="CPU time limit exceeded",reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",reason="exited-signalled",signal-name="SIGINT",signal-meaning="Interrupt"
-gdb-exit
^exit

[BitFlipper]

OK here is some more info that may be relevant…

I am using 3 systems:

1. Windows dev system
2. Linux build system
3. Linux debug system.

The source code is synced between the Windows and Linux build system, but not the Linux debug system. Since this “almost” works, does the 3rd system really need the source code as well? The debug system does not have space to store all the source code so it could be a problem if that is a requirement.

Also, how does path mapping need to be set up in the above scenario?

[ket]

Hi,

The deployment machine does not need the source code. The library symbol issues are probably also not related. Based on your log the following line makes VisualGDB think that the debugged program has exited:

reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",reason="exited-signalled"

Try running the gdb from command line. While the program is running try Ctrl+C, does the gdb stop normally or the program exits?

[BitFlipper]

OK I believe I found the cause of this issue. I was getting a lot of SIG exceptions while debugging the application so previously I added these GDB startup commands:

handle SIGPWR nostop pass
handle SIGXCPU nostop pass
handle SIG35 nostop pass
handle SIGSEGV nostop pass
handle SIGINT nostop pass

It seems at least one of those were causing VisualGDB to stop functioning properly. I removed them all and now I can place breakpoints without the application crashing, however debugging is almost impossible since I get tons of SIGPWR and SIGXCPU exceptions thrown continuosly.

But this then brings me to the question of how to get rid of or suppress these exceptions? If I can add them to the VS exception list and then ignore them that way it would help, but I’m not sure which category to add it to. Any ideas?

EDIT: Just found this that describes how debugging Mono (I’m using Mono to P/Invoke into native code) will confuse GDB, and which signals to ignore. So I’ll add…

handle SIGXCPU SIG33 SIG35 SIGPWR nostop noprint

…and see if that solves the non-stop barrage of exceptions.

EDIT EDIT: Once I added the above GDB startup command it now works properly, so problem solved!

[ket]

Hi,

Thanks for writing your solution here.
Our suggestion would have also advised to stop blocking the SIGINT signal as that is used to break at breakpoints.

[Author]

Posts