This is the mail archive of the cygwin-patches 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: Patch for silent crash with Cygwin1.dll v 1.5.19-4


On Thu, Apr 13, 2006 at 05:48:22AM -0700, Gary Zablackis wrote:
>> The exception handler is supposed to be initialized
>> in
>> _cygtls::init_thread which is called from
>> initialize_main_tls.
>> Why is that not happening?
>
>It does happen.  However, later on when the program calls dlopen ()
>(which will happen, e.g., when a python program imports a dll),
>LoadLibrary () gets called.  LoadLibrary () then installs its own
>exception handler.  The MS exception handler does NOT pass control back
>to the Cygwin exception handler (it is not obligated to).

You haven't proved that the cygwin exception handler is actually
installed at the time when you are reporting problems.  Repeating
that "it does happen" is not a proof.

>What is causing our problem is that when LoadLibrary () loads a dll,
>the following sequence of events occurs (NOTE: I have left out some of
>the intervening calls in the following sequence):
>  _cygwin_dll_entry@12 () calls dll_dllcrt0 ()
>                    which calls dll::init()
>                    which calls per_module::run_ctors
>()
>                    which calls pthread::once ()
>                    which calls pthread_key_create ()
>                    which calls 
>                         verifyably_object_isvalid ()
>                    which has the code:
>                     myfault efault;
>                     if (efault.faulted ())
>                       return INVALID_OBJECT;
>                    ...
>                     if ((*object)->magic != magic)
>                      return INVALID_OBJECT;
>                     return VALID_OBJECT;
>
>This last bit generates an exception which gets handled by the MS
>exception handler which decides the error must be fatal to the loading
>of the dll and sends us back to dlopen ().

There *really* is no reason to repeat this.  It has been explained many
times.  One thing missing from the above, however, is something which
shows that the cygwin exception handler is actually installed at the
point when this all occurs.

cgf


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