From: SourceForge.net <no...@so...> - 2008-03-26 13:37:28
|
Bugs item #1500271, was opened at 2006-06-04 01:38 Message generated for change (Comment added) made by keithmarshall You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1500271&group_id=2435 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: gdb Group: 64 bit feature request Status: Open Resolution: Remind Priority: 1 Private: No Submitted By: Matthew (mattbro) Assigned to: Nobody/Anonymous (nobody) Summary: gdb crashes in windows xp 64 Initial Comment: gdb.exe crashes immediately upon launch on my amd 64, windows xp machine. There are others who have reported the same issue. I found out while using bloodshed's dev C++ IDE. Debugging is not possible in windows xp 64. Now all of the other mingw compiler tools are being run in 32 bit emulation mode without much trouble. Moreover the old MS Visual C++ debugger will run in xp 64, and that also is a 32 bit program. The crash occurs no matter what project or file I load, as soon as I try to run the debugger. I also have an amd x2 3800 which is a dual core processor. I'm not sure if that is a related issue. The version's of gdb I've tried are 6.3-1 and an earlier one 5.2? I think. ---------------------------------------------------------------------- >Comment By: Keith Marshall (keithmarshall) Date: 2008-03-26 13:36 Message: Logged In: YES user_id=823908 Originator: NO > When is there going to be an updated version of this available > as a Cygwin RELEASE package? I neither know, nor care. It is completely irrelevant here; this tracker is for MinGW, and has nothing whatsoever to do with Cygwin. You need to ask this on a list/forum associated with Cygwin. > The current cygwin package is from 2006-07-06. So what? That is irrelevant to us. > I tested and validated GDB with latest package (candidate) of MINGW > - it works fine now. That's good to know, but which version do you mean, exactly? ---------------------------------------------------------------------- Comment By: garvek (garvek) Date: 2008-03-26 12:04 Message: Logged In: YES user_id=1569036 Originator: NO I tested and validated GDB with latest package (candidate) of MINGW - it works fine now. I don't know for Cygwin but perhaps you could also try with candidate versions of GDB. ---------------------------------------------------------------------- Comment By: garvek (garvek) Date: 2008-03-26 12:04 Message: Logged In: YES user_id=1569036 Originator: NO I tested and validated GDB with latest package (candidate) of MINGW - it works fine now. I don't know for Cygwin but perhaps you could also try with candidate versions of GDB. ---------------------------------------------------------------------- Comment By: Eric Dietz (oldneuro) Date: 2008-03-25 23:34 Message: Logged In: YES user_id=711304 Originator: NO When is there going to be an updated version of this available as a Cygwin RELEASE package? The current cygwin package is from 2006-07-06. ---------------------------------------------------------------------- Comment By: Marc Weustink (weus) Date: 2007-10-09 19:31 Message: Logged In: YES user_id=735939 Originator: NO Yes this patch is obsoleted by 'win32-nat.c' revision 1.137 The patched routine is deleted in that revision. From a quick glance at the new code it looks correct to me now. ---------------------------------------------------------------------- Comment By: Greg Chicares (chicares) Date: 2007-10-09 00:11 Message: Logged In: YES user_id=231935 Originator: NO [weus's patch in patch tracker item 1764083] Is this patch obsoleted by 'win32-nat.c' revision 1.137 of Sep 4 01:12:18 2007 UTC? See cgf's comment at the end of this message: http://cygwin.com/ml/cygwin/2007-10/msg00180.html ---------------------------------------------------------------------- Comment By: Marc Weustink (weus) Date: 2007-07-30 23:15 Message: Logged In: YES user_id=735939 Originator: NO patch uploaded under tracker iD=1764083 ---------------------------------------------------------------------- Comment By: Marc Weustink (weus) Date: 2007-07-30 22:42 Message: Logged In: YES user_id=735939 Originator: NO I had a similar problem and the cause of the crash is an indirect result of the psapi_get_dll_name function returning "NOT_AN_IMAGE" instead of "". Since a "name" is provided, the handle_load_dll function continues to register the loaded dll, which results in a call to solib_symbols_add. Here the AV gets uncovered, since the calls to bfd_openr() fail, so abfd stays NULL. At the end abfd gets closed without checking for NULL. the same counnts for the cygwin part before it. I've created a patch which solves this issue. (I'll attach it if I can findout how) ---------------------------------------------------------------------- Comment By: Oliver Stoeneberg (kidkat) Date: 2007-06-23 19:21 Message: Logged In: YES user_id=591019 Originator: NO I ran gdb in windbg and it already had an exception on start-up and when I tried to run the program (in this case it was MAME), it reported Error: dll starting at 0x77d41000 not found. As you can see from the information out of windbg about gdb below, there is nothing mapped at that addresses, that is an image/DLL. If you run it in the Dependecy Walker you will see, it tries to open a DLL with the name "NOT_AN_IMAGE": Loaded "NOT_AN_IMAGE" at address 0x7D4C0000. Cannot hook module. Unloaded "NOT_AN_IMAGE" at address 0x7D4C0000. The crash happens when it tries to get functions from psapi.dll: LoadLibraryA("psapi.dll") returned 0x76B70000. GetProcAddress(0x76B70000 [PSAPI.DLL], "EnumProcessModules") called from "GDB.EXE" at address 0x00455A11 and returned 0x76B71A8A. GetProcAddress(0x76B70000 [PSAPI.DLL], "GetModuleInformation") called from "GDB.EXE" at address 0x00455A26 and returned 0x76B71D97. GetProcAddress(0x76B70000 [PSAPI.DLL], "GetModuleFileNameExA") called from "GDB.EXE" at address 0x00455A3B and returned 0x76B71C4A. Second chance exception 0xC0000005 (Access Violation) occurred in "GDB.EXE" at address 0x004089FD. Exited "GDB.EXE" (process 0xA58) with code 128 (0x80). Maybe I got time to compile it in the next days and find the reason of the crash and an Access Violation, that is reproducible should not be that hard to be found. I also think that it is right, that the application is loading the 64-bit DLLs, because at the begging it loads some 32-bit DLLs, that appear to be the wrapper in the 32-bit emulation mode (I have no idea how it works). Here the info from windbg: Microsoft (R) Windows Debugger Version 6.7.0005.0 Copyright (c) Microsoft Corporation. All rights reserved. CommandLine: C:\mingw\bin\gdb.exe mamep4d Starting directory: d:\mame Symbol search path is: C:\WINDOWS\Symbols Executable search path is: ModLoad: 00000000`00400000 00000000`005d6000 image00000000`00400000 ModLoad: 00000000`77ec0000 00000000`77ff9000 ntdll.dll ModLoad: 00000000`6b000000 00000000`6b046000 C:\WINDOWS\system32\wow64.dll ModLoad: 00000000`6b280000 00000000`6b2ca000 C:\WINDOWS\system32\wow64win.dll ModLoad: 00000000`78b80000 00000000`78b89000 C:\WINDOWS\system32\wow64cpu.dll (770.260): Break instruction exception - code 80000003 (first chance) ntdll!DbgBreakPoint: 00000000`77ef2aa0 cc int 3 0:000> g ModLoad: 00000000`77d40000 00000000`77eb3000 NOT_AN_IMAGE ModLoad: 00000000`7d4c0000 00000000`7d5f0000 NOT_AN_IMAGE ModLoad: 00000000`7d600000 00000000`7d6f0000 C:\WINDOWS\SysWOW64\ntdll32.dll ModLoad: 00000000`77d40000 00000000`77eb3000 NOT_AN_IMAGE ModLoad: 00000000`77c20000 00000000`77d2c000 NOT_AN_IMAGE ModLoad: 00000000`7d4c0000 00000000`7d5f0000 C:\WINDOWS\syswow64\kernel32.dll ModLoad: 00000000`00890000 00000000`0092b000 C:\WINDOWS\syswow64\ADVAPI32.DLL ModLoad: 00000000`7da20000 00000000`7db00000 C:\WINDOWS\syswow64\RPCRT4.dll ModLoad: 00000000`7d8d0000 00000000`7d920000 C:\WINDOWS\syswow64\Secur32.dll ModLoad: 00000000`77ba0000 00000000`77bfa000 C:\WINDOWS\syswow64\msvcrt.dll ModLoad: 00000000`7d930000 00000000`7da00000 C:\WINDOWS\syswow64\USER32.dll ModLoad: 00000000`7d800000 00000000`7d890000 C:\WINDOWS\syswow64\GDI32.dll (770.260): WOW64 breakpoint - code 4000001f (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\WINDOWS\SysWOW64\ntdll32.dll - ntdll32!DbgBreakPoint: 00000000`7d61002d cc int 3 0:000:x86> g ModLoad: 00000000`76b70000 00000000`76b7b000 C:\WINDOWS\SysWOW64\psapi.dll (770.260): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. *** ERROR: Module load completed but symbols could not be loaded for image00000000`00400000 image00000000_00400000+0x124e23: 00000000`00524e23 ff948884000000 call dword ptr [eax+ecx*4+84h] ds:002b:00000000`3c14f3a4=???????? ---------------------------------------------------------------------- Comment By: Oliver Stoeneberg (kidkat) Date: 2007-06-23 13:22 Message: Logged In: YES user_id=591019 Originator: NO I am also having this problem and I consider it a pretty serious issue. gdb is the first program I ran into having problems running on x64. ---------------------------------------------------------------------- Comment By: C_B (cmb99) Date: 2006-10-19 14:29 Message: Logged In: YES user_id=1623965 No, but then Dependency Walker reports no more errors. Between the point I have loaded gdb in Walker and after I have typed run on an executable, I see: LoadLibraryA("psapi.dll") called from "GDB.EXE" at address 0x00475ECD. Loaded "PSAPI.DLL" at address 0x76B70000. Successfully hooked module. DllMain(0x76B70000, DLL_PROCESS_ATTACH, 0x00000000) in "PSAPI.DLL" called. DllMain(0x76B70000, DLL_PROCESS_ATTACH, 0x00000000) in "PSAPI.DLL" returned 131073 (0x20001). LoadLibraryA("psapi.dll") returned 0x76B70000. GetProcAddress(0x76B70000 [PSAPI.DLL], "EnumProcessModules") called from "GDB.EXE" at address 0x00475EEE and returned 0x76B71A8A. GetProcAddress(0x76B70000 [PSAPI.DLL], "GetModuleInformation") called from "GDB.EXE" at address 0x00475F03 and returned 0x76B71D97. GetProcAddress(0x76B70000 [PSAPI.DLL], "GetModuleFileNameExA") called from "GDB.EXE" at address 0x00475F18 and returned 0x76B71C4A. Second chance exception 0xC0000005 (Access Violation) occurred in "GDB.EXE" at address 0x00459628. Exited "GDB.EXE" (process 0xA70) with code 128 (0x80). Entrypoint reached. All implicit modules have been loaded. ---------------------------------------------------------------------- Comment By: Lieven de Cock (killerbot) Date: 2006-10-19 08:04 Message: Logged In: YES user_id=602705 were you able to get it working with copying that dll around ?? If so, can you tell the exact steps to perform ? ---------------------------------------------------------------------- Comment By: C_B (cmb99) Date: 2006-10-18 17:16 Message: Logged In: YES user_id=1623965 I think the dll in question is devmgr.dll. On x64 the version is shown as an Amd64 build in Dependency Wlaker, as opposed to x86. Maybe it got put in the System32 folder by mistake instead of the SysWOW64 ---------------------------------------------------------------------- Comment By: C_B (cmb99) Date: 2006-10-18 14:51 Message: Logged In: YES user_id=1623965 I think the dll in question is devmgr.dll. On x64 the version is shown as an Amd64 build in Dependency Wlaker, as opposed to x86. Maybe it got put in the System32 folder by mistake instead of the SysWOW64 ---------------------------------------------------------------------- Comment By: garvek (garvek) Date: 2006-08-05 14:50 Message: Logged In: YES user_id=1569036 I tried yesterday to build gdb with vc++ in order to debug it (or at least have some traces) but the makefile provided with mingw gdb source looks like unix one (I guess that they use MSYS to build). I also tried to find out what the address of the DLL points to, but it seems outside (perhaps there is also an issue with the way win x64 reads the PE). Currently (without symbol info) the only info I have is that gdb crashes after an access violation, soon after trying to get an entry point to the "missing" DLL. ---------------------------------------------------------------------- Comment By: Lieven de Cock (killerbot) Date: 2006-08-05 14:15 Message: Logged In: YES user_id=602705 I am having the same poblem. I use GDB through the IDE Code::Blocks (www.codeblocks.org). I am one of the developers of that project. I also have the crash, and it claims it can find a dll ?? I can not provide you with a 64-bit machine, but if you can provide me with a debug build to can write out som stack traces I oculd be able to provide feedback. In the worst case I am willing to build MinGW-GDB myself, but only when it is very straight forward ;-) When I boot my 64-bit machine in linux (Suse 10.1 64-bit) then GDB works, si it seems it's not a fundamental GDB problem. kind regards, Lieven PS : MinGW-GDB 6.2 ---------------------------------------------------------------------- Comment By: garvek (garvek) Date: 2006-08-05 01:04 Message: Logged In: YES user_id=1569036 In my opinion this is not a 64 bit feature request. Actually the fact thats MS 32 bits debugger is able to work show that we don't need x64 API to debug x32 programs. Currently this issues prevent ANY gdb user on a x64 machine to debug, this includes most C++ popular IDEs but also other languages (eg pascal), which work on x32 code for the moment. ---------------------------------------------------------------------- Comment By: Earnie Boyd (earnie) Date: 2006-06-06 10:55 Message: Logged In: YES user_id=15438 I've noted this as a 64bit feature request. Unless you're willing to debug the debugger or purchase for someone who has time a 64bit environment similar to yours resolving this issue will not happen. If you're willing to give away a 64bit PC I'll find someone with the time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=102435&aid=1500271&group_id=2435 |