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: "Dave Korn" <dave dot korn at artimi dot com>
- To: "'cygwin list'" <cygwin at cygwin dot com>
- Date: Thu, 16 Mar 2006 16:19:14 -0000
- Subject: 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.
> 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.
Can't think of a witty .sigline today....
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html