segfault in sysdep/i386/backtrace.h

Marco Trudel
Wed Feb 21 11:41:00 GMT 2007

Marco Trudel wrote:
> Andrew Haley wrote:
>> Marco Trudel writes:
>>  > Marco Trudel wrote:
>>  > > Andrew Haley wrote:
>>  > >> Marco Trudel writes:
>>  > >>  >  >  > The segfault happens on reading scan_bytes[x]. I assume 
>> that  > >> there is no  > "pushl %ebp; movl %esp, %ebp" function 
>> prologue in  > >> certain cases and  > thus we go reading protected 
>> areas below the  > >> function.
>>  > >>
>>  > >> Why don't you have a look, and tell us what is there?
>>  > >  > > Because I don't know how and what these hex values mean (how 
>> to  > > interpret them) when doing the backtrace...
>>  >  > Ok, learnt it...
>>  > The problem is that the code assumes that there is always a "pushl 
>> %ebp;  > movl %esp, %ebp" function prologue. But, from [1]: "Note that 
>> many  > compilers can optimize these standard sequences away when not 
>> needed  > (often called "no stackframe generation")".
>>  >  > So, when turning on maximum optimization in microsoft visual 
>> c++, there  > are no longer "pushl %ebp; movl %esp, %ebp" intros and 
>> thus we run into  > trouble (tried it). I don't know if GCC can do 
>> that too... Can it?
>> It can.
>>  > I checked a couple of dll's (awt.dll, swt.dll, aBluetoothLib.dll) I 
>> had  > around and they all miss the intro in at least a couple of 
>> functions.
>>  >  > So, questions:
>>  > - Is this a sjlj-exception only problem?
>> Yes.
>>  > Can DW EH do that better?
>> Yes.
>>  > - Is there another way to reliably recognize the start of a 
>> function? I  > assume this only affects native libs since Java 
>> compiled apps will  > always have the intro?!
>> Yes.  We tell gcj not to optimize away the frame generation.
>> We either have to write a ton of heuristics to figure this stuff out
>> or fix DWARF / SEH in Windows.
> Well, I think we should go for DWARF. Last I heard from Danny was that 
> it worked already but then was broken again for building gcc. Since 
> then, I never got an answer from him again.
> So, for the mean time we have two options for mingw:
> 1. Tell users to only use dlls with the entry sequences.
> 2. Fix gcj to not rely on them.

Well, actually we have another option. I forgot the most - IMHO - 
obvious and elegant one:
If the entry point is always there in our code but libraries can't be 
trusted; why not just ignore libs?
We can easy differentiate our code from libraries because they start in 
a defined region in the memory image. For Linux this is 0x40000000 and 
for mingw, this is 0x1000000 (one 0 less)*.

I attached a patch that seems to do that for mingw. My application works 
again with it. But I'm not an expert on this topic, so I could be 
completely wrong or don't know cases where it might fail.

Also, jni calls will go through their stub anyway, right? So the trace 
should still be correct because they contain the stub?!
What about cni? How does it work?

* Are these values correct? Are there other operating systems to 
consider? The Linux value is from a computer systems book and the mingw 
one from [1]. It looks suspicious that they start so much earlier on 
mingw than on Linux. But my GDBing backs that up.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: backtrace-patch.txt
URL: <>

More information about the Java mailing list