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

> The exception handler is supposed to be initialized
> in
> _cygtls::init_thread which is called from
> initialize_main_tls.
> Why is that not happening?
> cgf

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).

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 ().


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

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