Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!olivea!decwrl!pa.dec.com!mogul
From: mogul@wrl.dec.com (Jeffrey Mogul)
Newsgroups: comp.unix.ultrix
Subject: Re: sigblock causes setjmp longjmp botch on Ultrix 4.1
Message-ID: <1991Jan16.212028.1895@pa.dec.com>
Date: 16 Jan 91 21:20:28 GMT
References: <1991Jan14.050321.22222@watcgl.waterloo.edu>
Sender: news@pa.dec.com (News)
Organization: DEC Western Research
Lines: 32

In article <1991Jan14.050321.22222@watcgl.waterloo.edu> idallen@watpix.waterloo.edu (Ian! D. Allen [CGL]) writes:
>/* This program causes a longjmp botch and core dump on
> * ULTRIX V4.1 (Rev. 52) on a DS5400.
> * Why?
> */
>#include <setjmp.h>
>main()
>{
>	static jmp_buf jbuf;
>
>	sigblock(1<<31);
>	setjmp(jbuf);
>}

Thanks for pointing this out.  It looks like you've found a bug
in the 4.x version of the setjmp library routine.  If you
compile this program on a 3.1 system, it works fine on both
3.1 and 4.x.  If you compile it on a 4.x system, it core dumps
on both 3.1 and 4.x.

I think you could work around this by extracting the code for
setjmp.o from libc.a on a 3.x system, then linking your program
with that object module ... BUT I AM NOT SURE!

Alternatively, if you can figure out how to patch your program
binary, look for the "bltz" instruction in the setjmp routine,
and replace it with a no-op.  (THIS MIGHT NOT WORK EITHER!)
Sorry, I don't know how to patch object code.

I've filed a bug report on this with the Ultrix group.

-Jeff