home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.unix.programmer:3947 comp.sys.sun.misc:3357 comp.unix.questions:9464 comp.unix.wizards:3331
- Path: sparky!uunet!cs.utexas.edu!ut-emx!tivoli!shasta!bjv
- From: bjv@shasta.tivoli.com (Brian Vetter)
- Newsgroups: comp.unix.programmer,comp.sys.sun.misc,comp.unix.questions,comp.unix.wizards
- Subject: register windows and setjmp/longjmp
- Message-ID: <2203@tivoli.UUCP>
- Date: 27 Jul 92 23:01:31 GMT
- Sender: news@tivoli.UUCP
- Followup-To: comp.unix.programmer
- Organization: TIVOLI Systems
- Lines: 31
-
- I am working on a program that creates its own lightweight threads (must manage
- the stacks). To detect stack overflow, I am using the mprotect() system
- call to create a guard page at the end of the stack. Instead of just dumping
- core when the stack overflows, I want to exit the failed thread (the others
- get to keep running).
-
- My idea is to use setjmp() at the beginning of each thread to provide a "place"
- to come back, and to call longjmp() from the bus error handler. To do this,
- I have to have a separate signal stack (using sigstack() and sigvec()).
-
- The guard page works (I get my bus error), but I can't unwind the stack
- using longjmp(). I'm doing this on a Sun4 (ELC), and I suspect that there
- is some register window weirdness going on.
-
- The function calling setjmp gets control after the longjmp but it gets a
- bus error as soon as it returns to its caller. The $i7 and $fp registers
- are foobar when the function calling setjmp() gets control. I tried the
- #pragma unknown_control_flow for my function but it still doesn't get
- the correct $i7 and $fp. (If I set them to their correct values by hand
- in the debugger, everything works ok).
-
- After disassembling the setjmp/longjmp code in the library, I'm wondering
- how they ever work with long stack depths with the register windows.
-
- Does anyone know what I'm doing incorrectly? Or am I faced with a
- bug in SunOS (the rev. is 4.1.1)?
-
- Thanks in advance for any help,
-
- Brian Vetter
- bjv@tivoli.com
-