This is the mail archive of the
mailing list for the Java project.
Re: Natively compiled SWT segfaults under Windows
Ranjit Mathew wrote:
Perhaps you mean MSVC when you say "a standard Win32 toolchain" (or
the version that comes with the Platform SDK).
Yes, I used Visual C++ Express Edition and the Platform SDK, as they
to download. It seemed simpler to start with the toolchain targeted by SWT
In any case, this compiler should have some option of retaining the
frame pointer (using the EBP register) in the emitted code.
Actually, yes. I found this in the documentation of cl.exe (the
Microsoft compiler front-end):
"If your code requires EBP-based addressing, you can specify the /Oy–
I then disassembled versions of the SWT DLL to see the impact of this flag.
ff 74 24 0c push dword [esp+0xc]
ff 15 08 72 03 10 call [0x10037208]
c2 0c 00 ret 0xc
55 push ebp
8b ec mov ebp,esp
ff 75 10 push dword [ebp+0x10]
ff 15 08 82 03 10 call [0x10038208]
5d pop ebp
c2 0c 00 ret 0xc
Some methods begin with 55 8b ec without this flag, but all do when using it
(excepted _JNI_OnLoad@8, interestingly).
If you need to unwind through a function in a DLL and get the stack
trace, you need to compile the DLL with frame pointers enabled. (Even
then the current code is quite kludgy - it assumes that the initial
part of a function prologue is a sequence of "PUSH ebp; MOV ebp, esp"
instructions which might not be true for other compilers or even GCC
under "different" circumstances.)
Considering the disassembled code above, this hypothesis looks rather
Finally, Olivier please note that I do not know if this indeed is the
problem troubling you. It could well be that the current GCJ/Win32
backtrace code has a bug that you are hitting.
Sadly, you're probably right: using the SWT DLL including proper
frame pointer retaining led to exactly the same crash.
So there's either a problem with my GCJ build or with the backtrace
code, I suppose. Back to step one )-: