This is the mail archive of the cygwin 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]
Other format: [Raw text]

Re: dlopen() bug (new testcase)

On Thu, Mar 30, 2006 at 01:35:54AM +0200, Bernhard Loos wrote:
>> -----Urspr?ngliche Nachricht-----
>> Von: Christopher Faylor
>> Gesendet: Wed, 29 Mar 2006 18:15:34 -0500 
>>On Thu, Mar 30, 2006 at 01:10:56AM +0200, Bernhard Loos wrote:
>>>I looked at the problem again this week, but unfortunately I'm unable
>>>to debug anything happening after the first SIGSEGV.  I inserted a view
>>>OutputDebugString()-calls and got those results:
>>>00:00:00.703: LoadLibraryA("H:\cygwin\test\CrashTest\CrashTest.dll") called from "CYGWIN1.DLL" at address 0x6100FE42 by thread 1.
>>>00:00:00.718: Loaded "CRASHTEST.DLL" at address 0x003F0000 by thread 1.  Successfully hooked module.
>>>00:00:00.718: DllMain(0x003F0000, DLL_PROCESS_ATTACH, 0x00000000) in "CRASHTEST.DLL" called by thread 1.
>>>00:00:00.718: myfault::faulted
>>>00:00:00.718: setup_fault
>>>00:00:00.718: First chance exception 0xC0000005 (Access Violation) occurred in "CYGWIN1.DLL" at address 0x610B2DE2 by thread 1.
>>>00:00:00.718: Unloaded "CRASHTEST.DLL" at address 0x003F0000 by thread 1.
>>>00:00:00.718: LoadLibraryA("H:\cygwin\test\CrashTest\CrashTest.dll") returned NULL by thread 1. Error: Unzulssiger Zugriff auf einen Speicherbereich (998).
>>>00:00:00.781: First chance exception 0xC0000005 (Access Violation) occurred at address 0x003F101A by thread 1.
>>>00:00:00.781: return_from_fault
>>>00:00:00.781: First chance exception 0xC0000005 (Access Violation) occurred at address 0x40000060 by thread 1.
>>>00:00:00.781: First chance exception 0xC0000029 (Unknown) occurred in "NTDLL.DLL" at address 0x7C95EB28 by thread 1.
>>>It looks, like Windows unloads the DLL after the first exception even before the myfault-exception handler is able to catch it.
>>>So return_from_fault() tries to longjmp to code wich isn't present any more an the second exception occurs.
>>>To fix this problem, I would suggest to use the IsBadReadPtr()-function instead of the myfault-exception handler to check the pointer in 
>>>I could write a patch, if nobody has any objections.
>>Sorry, no.  We *just* got rid of IsBadReadPtr's.
>Just out of interest, what's the problem with IsBadReadPtr?

You'll have to read the archives.  Eric Blake has talked about this very

>>FWIW, I doubt that Windows is really ignoring an exception handler.
>The exception handler is called, but at least the return_from_fault is
>called after the DLL gets unloaded, as you can see above.

I don't see that in your output.  However, If that was the case, you
should be able to set a breakpoint in the exception handler to verify
it without resorting to contortions like adding OutputDebugString.


Unsubscribe info:
Problem reports:

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