This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: More on mingw32, make, sleep, _sleep, __sleep, and Sleep


vischne@ibm.net writes:
> My apologies about the problems with mingw32.  If you have your
> mingmake.bat set your environment variables exactly right (following the
> README), ming make will actually generate make.bat files from cygwin
> ./configured Makefiles, and, in rare instances, will actually make GNU
> makefiles without using bash or sh (but don't use a makefile that changes
> directories while compiling).

Exactly. However, if you replace all your "cd subdir; $(MAKE)" with
"$(MAKE) -C subdir", then at least it works with .bat files. 

> 
> Command name abbreviations are allowed if unambiguous.
> (gdb) run
> run
> Starting program: D:\mingw32\src\slrn\src/slrn.exe
> bff30000:C:\WINDOWS\SYSTEM\GDI32.DLL
> bff60000:C:\WINDOWS\SYSTEM\USER32.DLL
> bfed0000:C:\WINDOWS\SYSTEM\ADVAPI32.DLL
> 7e2e0000:C:\WINDOWS\SYSTEM\WSOCK32.DLL
> bff70000:C:\WINDOWS\SYSTEM\KERNEL32.DLL
> 7fd50000:C:\WINDOWS\SYSTEM\CRTDLL.DLL
> 
> [failed reading symbols from DLL]
> "C:\WINDOWS\SYSTEM\COMCTL32.DLL": error reading line numbers
> 
> 7eb40000:C:\WINDOWS\SYSTEM\SHELL32.DLL
> 
> [failed reading symbols from DLL]
> "C:\WINDOWS\SYSTEM\SHLWAPI.DLL": error reading line numbers
> 
> 61000000:C:\WINDOWS\SYSTEM\URL.DLL
> slrn 0.9.4.3 (Dec  1 1997 14:06:42)
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x438c51 in _image_base__ ()
> (gdb)
> 

This unfortunately doesn't tell me anything at all as to where it died and
why. The gdb _image_base problem is well known; whenever you try to step
over a function that is exported by one of the Win32 DLLs, gdb for some
reason gets into _image_base instead and you have use "finish" to get out
of it. From the looks of it, it might dying in a call to a routine
exported by URL.DLL, but that's just wild guess.

In this case, my suggestion is to move up one frame ("up") and then
examine your code. I'm assuming that you've built everything with
debugging on, so it will give you a better idea what's going on. At the
very least, you'll see the parameters the to routine that's dying and
maybe the Win32 API docs will tell you why it's dying.

Mumit
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]