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: Bug in dlopen() (or following) code in Cygwin1.dll v 1.5.19-4


On 16 March 2006 15:48, Norton Allen wrote:


>>> * thread.cc (verifyable_object_isvalid): check for
>>> NULL object or reference
>> 
>> The "efault.faulted()" two lines above your change is supposed to catch
>> NULL dereferences.
> 
> Whoa! This looks like voodoo action-at-a-distance. 

  Exception handling does that :)  See also setjmp/longjmp.

> efault.faulted()
> doesn't even get passed the pointer to know whether or not it's
> NULL. 

  errno doesn't get passed any pointers, but it still often ends up returning
'EINVAL' when the pointer you pass to a routine is null....

> Although efault.faulted() is supposed to catch the NULL dereferences,

  Nope, the exception handling is supposed to catch the NULL deref, and set an
error code which is then returned by efault.faulted.

  Take a /look/ at the source for myfault::faulted in cygtls.h, it calls out
to _cygtls::setup_fault, which calls _sjfault, which appears to be a q'n'd
hacked-up version of setjmp in a context where it's going to get called back
by an SEH handler.  So IIUIC, calling 'efault.faulted' will catch any
exception that happens from the point of the call until the point where the
efault object goes out of scope and gets destructed and will cause execution
to jump back to the if... clause.




    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


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