FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

Knowing who generated the fault isn't enough:  I just gave that as an
example of something that makes this difficult to handle properly.

The real problem is like this.  Say you have some other thread that does
something really bad, generating a SIGSEGV.  It just so happens that your
luck is bad, and at the time that the SIGSEGV was generated, vasprintf() has
installed its sigsegv() function to handle this signal.

Now, this other thread has entered sigsegv().  Even if it can determine
"Gee, I really don't belong here, this handler is really here to service the
thread doing the asprintf()!", what can you do about it at that point?
Maybe we want to dump core at this point.  But maybe there's another SIGSEGV
handler, temporarily replaced by the one in asprintf.c, and if we could only
figure out what that handler was, we could call it to get the correct
behavior.

Unfortunately, only vasprintf() knows what the old handler was.  So, one of
my ideas was to stash the old value into a static variable, so that
sigsegv() could find out what it was, and call into the correct handler.
But that static variable would need to be protected by a mutex, and we can't
do any pthread calls within a signal handler.

No matter what you do, there's no way you can change global state (like a
signal handler) without some cooperation from other threads.  All the
pthreads documentation tells you to just set up your signal handlers and
masks properly before you begin creating threads.  That way, you can unmask
the signal in the appropriate thread where you want the handling to occur.
However, in our case, by the time vasprintf() is in control, it's way too
late to do anything of the sort.

What would be really nice, would be a way to say "Stop scheduling all other
threads for now.  I really need to execute a critical section of code
without other threads getting any time slices."  But there doesn't seem to
be any way to guarantee that within the pthreads framework, without relying
on non-portable and/or optional features.  The best you can do is request to
run with process-scope thread scheduling, as a realtime (SCHED_FIFO) thread,
at the highest priority.  But even if you request all that, it is perfectly
legitimate for the pthreads implementation to ignore your request.

--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu] 
Sent: Thursday, August 29, 2002 10:34 AM
To: TDS Development Group
Subject: [freetds] RE: asprintf vasprintf


> From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
> Sent: August 29, 2002 9:54 AM
> 
> There just doesn't seem to be any way to safely change the
> signal handler on
> the fly in a library function like this, without potentially causing
> undesired behavior in another thread.  In particular, all 
> pthread calls are
> off-limits in signal handlers, which makes it virtually 
> impossible to do anything about this.

It's not necessary (I assert) to know what thread caused the fault, to know
whether your thread caused the fault.  

Can your handler determine where the faulting instruction or memory
reference was, from the sigcontext pointer?  If so, you'd know whether it
resulted from asprintf() or anything else.  

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.



---
You are currently subscribed to freetds as: [Nicholas_Castellano AT acml.com]
To unsubscribe, forward this message to
$subst('Email.Unsub')


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.