D. Allen [CGL]" <idallen@watpix.waterloo.edu> (01/14/91)
/* 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);
}
--
-IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu
[129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada
mogul@wrl.dec.com (Jeffrey Mogul) (01/17/91)
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
D. Allen [CGL]) (01/19/91)
In article <1991Jan16.212028.1895@pa.dec.com> mogul@wrl.dec.com (Jeffrey Mogul) writes: >I've filed a bug report on this with the Ultrix group. Yes! Someone who read news and submitted an Ultrix bug report! Yes yes yes, oh yes! Want a dozen more? -- -IAN! (Ian! D. Allen) idallen@watcgl.uwaterloo.ca idallen@watcgl.waterloo.edu [129.97.128.64] Computer Graphics Lab/University of Waterloo/Ontario/Canada