Opened 13 years ago
Closed 13 years ago
#26 closed defect (fixed)
jongjmp() causes XCPT_INVALID_UNWIND_TARGET
| Reported by: | dmik | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | Swing Core |
| Component: | general | Version: | |
| Severity: | Keywords: | ||
| Cc: |
Description
This happens now in ZeroToaster? if you attempt to send a message via SMTP.
Change History (8)
comment:1 Changed 13 years ago by
comment:3 Changed 13 years ago by
What happens there is that longjmp() attempts to unwind the OS/2 exception chain (up to the target exception handler that was active while setjmp() was called) but setjmp has actualy captured the Win32 exception (because the FS register normally points to the Win32 TIB while running in Odin). Therefore, DosUnwindException?() never reaches the target exception handler (as it's missing from the OS/2 exception chain) and throws XCPT_INVALID_UNWIND_TARGET when gets to the end of chain.
comment:4 Changed 13 years ago by
So it's now clear why I didn't use setjmp()/longjmp()...
One of the possible solutions is to install an exception handler to the OS/2 chain as well from try(). This way, longjmp will not pass us by: it will either call this OS/2 exception handler if its target is somewhere above (i.e. setjmp() for that longjmp() was called outside the try block) or simply happily jump somewhere in to the try block (if setjmp() was called from within it).
I will create a testcase for that.
comment:5 Changed 13 years ago by
So, this turned out to be an Odin32 problem and it was fixed in r 21474 there. See also http://svn.netlabs.org/odin32/ticket/15.
comment:6 Changed 13 years ago by
Silvan, here are new DLLs for you, jvm.dll and kernel32.dll -- ftp://ftp.dmik.org/tmp/silvan/jjj.zip. That should be enough for the fix. If not, I will provide a full build of Java and Odin32 tomorrow.
Okay, this was actually quite obvious (but took some time to prove in the debugger due to some problems I had with compiling in my VM): longjmp is performed from within the try SEH block whose functionality we emulate in Odin32. It is known that this emulation does not support longjmp (among other things such as goto, return etc) because it doesn't access to compiler internals.
I will have to find out how to solve that. Probably, I will have to use setjmp()/longjmp() myself instead of my custom machinery in ASM. I already thought of that but for some reason I declined this approach back then.