4

Using MinGW GDB version 7.6, get a lot of backtraces like this:

(gdb) bt
#0  0x000000007703d256 in ntdll!RtlEnterCriticalSection ()
   from C:\Windows\SYSTEM32\ntdll.dll
#1  0x0000000000000000 in ?? ()

Which isn't exactly useful.

Why is this? Is there anyway to get anything more useful? It's absolutely painful to try and figure out what a complicated, multi-threaded program was doing when an error happened when this is the backtrace that I get.

Robert Allan Hennigan Leahy
  • 6,478
  • 28
  • 45
  • have you enabled gdb non-stop mode? theres a good multithreaded debugging example with gdb [here](http://blogs.adobe.com/flascc/2012/11/09/debugging-multi-threaded-flascc-applications-with-gdb/) – amdixon Nov 15 '13 at 08:09
  • Is this a 32 or 64 app, and likewise for OS? Also, since the stack includes a call to `ntdll`, it's safe to say that this is part of a system call. Knowing what I know about kernel calls affecting .NET exceptions, I wouldn't be surprised if something similar here was affecting the backtrace. – Jonathon Reinhart Nov 15 '13 at 08:10
  • 64-bit app/64-bit OS. – Robert Allan Hennigan Leahy Nov 15 '13 at 08:15
  • I'm just guessing, but I suspect it's because GDB doesn't deal with Microsoft's PDB symbol format so there's no symbol information for GDB to deal with in Window's system DLLs other than exports. – Michael Burr Nov 17 '13 at 05:20

2 Answers2

2

I run into the same problem using MinGW 64. Using the compiler switches -g3 -Og finally showed all the backtrace nicely.

Heinz Hornung
  • 41
  • 3
1

The reason might be that gdb has the notion of an "current" thread which is chosen IMHO quite randomly.

You can see what threads your program currently is executing by issuing the gdb command info threads. Switch the "current" thread by thread <num>. Try to get a meaningful backtrace again.

Also be sure that

  • your executable is compiled with debug information (-g),
  • that gdb is able to cope with the format used to encode the debug information into your executable. You might want to verify whether gdb can set a breakpoint at `main()' and is behaving reasonable there.
Nicolai Stange
  • 262
  • 1
  • 5