Opened 10 years ago

Closed 10 years ago

#26 closed defect (fixed)


Reported by: dmik Owned by:
Priority: major Milestone: Swing Core
Component: general Version:
Severity: Keywords:


This happens now in ZeroToaster? if you attempt to send a message via SMTP.

Change History (8)

comment:1 Changed 10 years ago by dmik

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.

comment:2 Changed 10 years ago by dmik

God, crappy trac markup, who will save us...

comment:3 Changed 10 years ago by dmik

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 10 years ago by dmik

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 10 years ago by dmik

So, this turned out to be an Odin32 problem and it was fixed in r 21474 there. See also

comment:6 Changed 10 years ago by dmik

Silvan, here are new DLLs for you, jvm.dll and kernel32.dll -- That should be enough for the fix. If not, I will provide a full build of Java and Odin32 tomorrow.

comment:7 Changed 10 years ago by Silvan Scherrer

Dmitry the crash is fixed.

comment:8 Changed 10 years ago by dmik

Resolution: fixed
Status: newclosed


Note: See TracTickets for help on using tickets.