Allegro.cc - Online Community

Allegro.cc Forums » Programming Questions » GDB crashing

This thread is locked; no one can reply to it. rss feed Print
 1   2 
GDB crashing
raynebc
Member #11,908
May 2010

The project I work on has recently caused GDB to start crashing if I invoke a function that pulls up a file browse dialog window. The program behaves as expected when run outside the debugger, but trace debugging shows the crash occurs when GetOpenFileName() (which is a macro for GetOpenFileNameA() ) is called. GDB has always tended to have unusually long delays when I bring up this file browser in debug mode, but I'm not sure why the crashes only begun happening now.

I'm not seeing that MinGW offers a GDB build newer than what I have had for some time (7.6.1). I can work around this by defining the file I want to load as a command line parameter for my program, as this avoids having to bring up the file browser, but it's a bit annoying. Does anybody have any suggestions for simple workarounds to this kind of problem?

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

raynebc
Member #11,908
May 2010

It wouldn't surprise me. I do have Ubuntu on one of my laptops, but I dislike how it intercepts the ALT key for its stupid menu system so I do my development and testing on Windows. Supposedly this can be remapped (https://askubuntu.com/questions/122209/how-do-i-modify-or-disable-the-huds-use-of-the-alt-key?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa) but I haven't spent much time dealing with it.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

raynebc
Member #11,908
May 2010

Wouldn't that only be usable in the MSYS environment?

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

bamccaig
Member #7,536
July 2006
avatar

There are many desktop environments in Linux so you could always try installing another desktop environment and see if that suits your needs better. Personally, I prefer MATE which is a fork of GNOME 2. Goes back to basics with the kind of GUI you got 10 years ago in XP. I haven't noticed any Alt eatery from it. Honestly, it's a little comical to hear of a developer that uses both environments, but chooses Windows for development. Also Ubuntu is a convenient distro for installing non-free software for media consumption, but it's not necessarily the ideal platform for development. You could always try another Linux distro. Some other popular environments are Debian, Fedora, and Arch. Linux (meaning GNU+Linux+many other free software packages) is supposed to be free. You can make it what you want or need it to be. It's not a walled garden like Windows or OS X.

Back on topic, I wonder if a crashing GDB would be considered a bug by the GDB project. Don't ask me how you're supposed to debug GDB though. :P

Chris Katko
Member #1,881
January 2002
avatar

Definitely file a bug report. You know the exact function that causes it. That should make it easy to replicate and then fix.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

raynebc
Member #11,908
May 2010

The strange thing is that I used this version of MinGW and GDB to develop this particular code base for years. It didn't begin crashing until I added lots of unrelated changes. I also noticed it soon after an OS reboot, so I don't know if Windows/antivirus updates or anything else environmental are involved. The crash still happens if I disable the AV.

I have no expectation that I am causing memory corruption or anything like that, it would likely have been noticed by Coverity, cppcheck or maybe even Memwatch (a set of hooks for memory allocation functions that test for overflows, wild/double memory frees, etc), and I can trigger it at the very beginning of the execution of the program (before nearly any of the program's code is used).

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

raynebc
Member #11,908
May 2010

It's already generally stable and correct with regard to memory handling (no buffer overflows, no wild frees, no memory leaks), this is entirely a GDB issue it seems.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

You also get better error messages from gcc. They have more warnings enabled by default, as well as getting cutting edge versions.

We're lucky anyone has ported gdb to windows at all. I'm using gdb 7.11.1, I can't remember where I got that from either.

That version just started (finally) to get pretty printing enabled and working for STL template classes.

raynebc
Member #11,908
May 2010

Windows 10's April Service Pack overwrote GRUB. Again. Get your shit together, Microsoft. I'll get around to fixing GRUB again when I get around to it, so I can get back in Ubuntu eventually.

Chris Katko
Member #1,881
January 2002
avatar

Mine just restarted my system while I was watching TV, uploading a 32 GB file (14+ hours), and running a second Windows 10 VM. Also terminated a multiple hour slow download.

It closed it all.

It also bricked my laptop, and broke RDP for many work computers.

$ssholes.

Never had ANYTHING like that happen on Linux. They wouldn't DARE reboot without asking you first.

-----sig:
“Programs should be written for people to read, and only incidentally for machines to execute.” - Structure and Interpretation of Computer Programs
"Political Correctness is fascism disguised as manners" --George Carlin

Peter Hull
Member #1,136
March 2001

Just to be clear, are you saying GDB itself crashes or your program crashes when run inside GDB?

You might be able to get the crashing process to write out a minidump (equivalent of coredump on Unix) and use windbg to figure out where it was. (there used to be something called DrMingW which was sporadically useful but I haven't used MingW in years)

raynebc
Member #11,908
May 2010

Windows specifically cites gdb.exe as crashing. It offers to open it in a debugger, but I don't have any other ones on this computer.

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

raynebc
Member #11,908
May 2010

Will that provide useful information to the GDB team if GDB doesn't happen to be built with symbols or something like that?

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

raynebc
Member #11,908
May 2010

I'm not getting much out of it, maybe you could suggest other commands to gather useful information from the crashed GDB process?

Attaching to process 7148
[New Thread 7148.0x62c]
[New Thread 7148.0x203c]
[New Thread 7148.0x2128]
Reading symbols from C:\MinGW\bin\gdb.exe...done.
(gdb) bt
#0  0x77bd000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
#1  0x77c5f306 in ntdll!DbgUiRemoteBreakin ()
   from C:\Windows\SysWOW64\ntdll.dll
#2  0x4f7b0aa7 in ?? ()
#3  0x00000000 in ?? ()
(gdb)

bamccaig
Member #7,536
July 2006
avatar

If you want to go full r***** you could try to compile GDB yourself with debug symbols. But on Windows I can't imagine that's an easy task. I'm not even sure if it would be trivial in Linux.

Without debug symbols I think at best you'll get a bunch of function addresses which won't do much good unless somebody has a mapping for those addresses to actual functions.

That said, the stack trace you did get doesn't look entirely useless. It doesn't mean anything to me, but perhaps it would mean something to the GDB devs (or community). Won't hurt to ask.

raynebc
Member #11,908
May 2010

Given that the regular gdb is on version 8.1, do you suspect they would tell me not to bother them if I can't reproduce on the current release? Should I check with MinGW first?

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

Other options you can try (that may or may not be helpful), are :

>bt full
>bt 1 full
>info thread
>thread apply all bt [N] [full]

Who knows how much you'll get out of it.

I'm trying to update and upgrade to latest msys2 and gdb to see what version they're on.

EDIT
gdb in MSYS2 is on version 8.0.1. I would definitely give it a try. Just because gdb was compiled with msys2 doesn't mean it can't debug regular windows programs. It just needs debugging symbols.

raynebc
Member #11,908
May 2010

Can I get just the GDB.exe from MSYS2? I could only immediately find an installer for MSYS2 and bundled tools, and from a quick glance at MSYS2's website it seems it's MinGW-w64-centric. I'm not immediately sure it would get along with my MinGW installation. In the meantime I'll join the relocated MinGW mailing list and see if they want to look into it. Maybe they could provide builds with debugging symbols.

Here are those GDB outputs from a crashed instance:

#SelectExpand
1(gdb) bt full 2#0 0x77bd000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll 3No symbol table info available. 4#1 0x77c5f306 in ntdll!DbgUiRemoteBreakin () 5 from C:\Windows\SysWOW64\ntdll.dll 6No symbol table info available. 7#2 0x4c6174e9 in ?? () 8No symbol table info available. 9#3 0x00000000 in ?? () 10No symbol table info available. 11(gdb) bt 1 full 12#0 0x77bd000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll 13No symbol table info available. 14(More stack frames follow...) 15(gdb) info thread 16 Id Target Id Frame 17* 3 Thread 8484.0x2278 0x77bd000d in ntdll!DbgBreakPoint () 18 from C:\Windows\SysWOW64\ntdll.dll 19 2 Thread 8484.0x19a4 0x77be018d in ntdll!ZwWaitForMultipleObjects () 20 from C:\Windows\SysWOW64\ntdll.dll 21 1 Thread 8484.0x2310 0x77be018d in ntdll!ZwWaitForMultipleObjects () 22 from C:\Windows\SysWOW64\ntdll.dll 23(gdb)

The "thread apply all bt full" command printed a lot of output:
https://pastebin.com/raw/NVCnBB8f

Edgar Reynaldo
Major Reynaldo
May 2007
avatar

I assume they would be pretty interested in this bit :

Thread 1
...
No symbol table info available.
#13 0x75558f74 in msvcrt!abort () from C:\Windows\syswow64\msvcrt.dll
No symbol table info available.
#14 0x005a2fdc in internal_vproblem (
    problem=0x6c675c <internal_error_problem>,
    file=0x737f36 <__PRETTY_FUNCTION__.20807+1622> "../../gdb-7.6.1/gdb/minsyms.c", line=862,
    fmt=0x7380d0 <__PRETTY_FUNCTION__.20807+2032> "sect_index_data not initialized", ap=0x2c7ebbc "\207ャ\\") at ../../gdb-7.6.1/gdb/utils.c:840
        msg = "Recursive internal problem.\n"
        dejavu = 1
#15 0x005a31ff in internal_verror (
    file=file@entry=0x737f36 <__PRETTY_FUNCTION__.20807+1622> "../../gdb-7.6.1/gdb/minsyms.c", line=line@entry=862,
    fmt=fmt@entry=0x7380d0 <__PRETTY_FUNCTION__.20807+2032> "sect_index_data not initialized", ap=ap@entry=0x2c7ebbc "\207ャ\\")
    at ../../gdb-7.6.1/gdb/utils.c:944
No locals.
#16 0x005a3237 in internal_error (
    file=file@entry=0x737f36 <__PRETTY_FUNCTION__.20807+1622> "../../gdb-7.6.1/gdb/minsyms.c", line=line@entry=862,
    string=0x7380d0 <__PRETTY_FUNCTION__.20807+2032> "sect_index_data not initialized") at ../../gdb-7.6.1/gdb/utils.c:954
        ap = 0x2c7ebbc "\207ャ\\"
#17 0x0052063a in prim_record_minimal_symbol (
    name=name@entry=0x678ad28 "api-ms-win-crt-multibyte-l1-1-0!_mbcasemap",
    address=address@entry=1714189152, ms_type=ms_type@entry=mst_data,
    objfile=0x6a8e4c0) at ../../gdb-7.6.1/gdb/minsyms.c:862
        section = <optimized out>
#18 0x0052a587 in add_pe_forwarded_sym (

 1   2 


Go to: