This is the mail archive of the
mailing list for the Cygwin project.
RE: Bug in dlopen() (or following) code in Cygwin1.dll v 1.5.19-4
- From: Norton Allen <allen at huarp dot harvard dot edu>
- To: cygwin list <cygwin at cygwin dot com>
- Date: Thu, 16 Mar 2006 14:03:38 -0500
- Subject: RE: Bug in dlopen() (or following) code in Cygwin1.dll v 1.5.19-4
Ah, got it--it behaves like exception handling, but it
doesn't *look* like exception handling. Seems like a
good place to add some comments! ;-) (Offer to submit
a patch, but seeing as I had to ask, I doubt I'm the
right person to do so.) Thanks for clearing this up
On 16 March 2006, Dave Korn wrote:
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
Whoa! This looks like voodoo action-at-a-distance.
Exception handling does that :) See also setjmp/longjmp.
doesn't even get passed the pointer to know whether or not it's
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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html