FreeTDS Development Group

[Bernd Jendrissek <berndj AT prism.co.za>]

On Thu, Aug 29, 2002 at 11:03:23AM -0400, Castellano, Nicholas wrote:
> 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.

I don't understand why all this talk about SIGSEGV handlers.  From man 2
sigaction:

       According to POSIX, the behaviour of a  process  is  unde­
       fined after it ignores a SIGFPE, SIGILL, or SIGSEGV signal
       that was not generated by the kill() or the raise()  func­
       tions.  Integer division by zero has undefined result.  On
       some architectures  it  will  generate  a  SIGFPE  signal.
       (Also  dividing the most negative integer by -1 may gener­
       ate SIGFPE.)  Ignoring this signal might lead to  an  end­
       less loop.

Anything depending on handling SIGSEGV will be platform-dependent anyway.

-- 
berndfoobar AT users.sourceforge.net is probably better to bookmark than any
employer-specific email address I may have appearing in the headers.
  Vanity page: http://www.tsct.co.za/~berndj/