Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 21 Jun 2001 11:54:23 -0500
From:      Alfred Perlstein <bright@sneakerz.org>
To:        Louis-Philippe Gagnon <louisphilippe@macadamian.com>
Cc:        freebsd-hackers@FreeBSD.ORG
Subject:   Re: pthread/longjmp/signal problem
Message-ID:  <20010621115423.U4543@sneakerz.org>
In-Reply-To: <0db001c0fa62$2b567800$2964a8c0@macadamian.com>; from louisphilippe@macadamian.com on Thu, Jun 21, 2001 at 10:55:10AM -0400
References:  <0db001c0fa62$2b567800$2964a8c0@macadamian.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Louis-Philippe Gagnon <louisphilippe@macadamian.com> [010621 09:56] wrote:
> No reactions the first time, let's try again.
> 
> I've encountered a problem in the interaction betwen signals, longjmp and
> pthreads; I'm hoping someone can help me make sense of it.
> 
> I've been trying to implement a IsBadReadPtr-style function in FreeBSD by
> using signal handlers and longjmp/setjmp. It seemed to work as expected,
> until I started using the -pthread option to gcc (thus linking against
> libc_r). Now the function only works on the first call; subsequent calls
> hang on the segmentation fault.
> 
> Here's an example of the kind of code that causes problems :

[snip]

ERRORS
     If the contents of the env are corrupted, or correspond to an environment
     that has already returned, the longjmp() routine calls the routine
     longjmperror(3).  If longjmperror() returns the program is aborted (see
     abort(3)).  The default version of longjmperror() prints the message
     ``longjmp botch'' to standard error and returns.  User programs wishing
     to exit more gracefully should write their own versions of
     longjmperror().

> So the questions are :
> -Am I doing something obviously wrong?

I think so, I think you must reinit the 'env' like so:

reset:
 if(sigsetjmp(env,1)) {
  fprintf(stderr,"longjmp successful\n");
  goto reset;
 }



> -Is this a bug?

I think so, even with reinitializing the env structure it still hangs
for me as well:

before sigsegv
write(2,0x3fbff308,15)                           = 15 (0xf)
sigprocmask(0x3,0x280fb338,0x0)                  = 0 (0x0)
sigaltstack(0x28116d00,0x0)                      = 0 (0x0)
in handler
write(2,0x3fbfef98,11)                           = 11 (0xb)
sigprocmask(0x3,0x804997c,0x0)                   = 0 (0x0)
longjmp successful
write(2,0x3fbff308,19)                           = 19 (0x13)
sigprocmask(0x1,0x0,0x804997c)                   = 0 (0x0)
before sigsegv
write(2,0x3fbff308,15)                           = 15 (0xf)
sigreturn(0x8057e7c)                             = 0 (0x0)
sigreturn(0x8057e7c)                             = 0 (0x0)
sigreturn(0x8057e7c)                             = 0 (0x0)
sigreturn(0x8057e7c)                             = 0 (0x0)


> -Is this a known bug with a known workaround?

Not that I know of, I'll take a peek at the threading libraries, but
I'm not promising anything.

-Alfred

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010621115423.U4543>