Re: [MinGW] RFA: Make Stack Traces Work for Interpreted Code on Windows

[Bryce McKinlay <mckinlay at redhat dot com>]

Hi Ranjit,

Ranjit Mathew wrote:
>   When run under the interpreter, an exception-throwing programme
> crashes the interpreter on Windows since JvRunMain() does not
> occur in the call stack and we once again roam the wilderness of
> arbitrary EBP values.
>
> The fix was to change fallback_backtrace() in
> "sysdep/i386/backtrace.h" to stop on _Jv_RunMain() instead since
> this does occur in both interpreted and natively-executed call
> stacks. (Since this function is overloaded, I needed to use an
> interim variable with the appropriate cast to tell the compiler
> which of these function variants to pick up.)
>   

Only the main thread will have JvRunMain on the stack - you probably 
also need to look for the thread-start routine to handle other threads.

Note that even then there are some situations (invocation API) where 
neither _Jv_RunMain or _Jv_ThreadStart will be on the stack.
> fallback_backtrace() also does not correctly handle unwinding
> through interpreted code. The fix was as simple as copying the
> relevant bits of code from _Jv_StackTrace::Unwind_TraceFn() and
> adjusting it a little bit.
>   

This part of the patch is a bit awkward - duplicating the 
interpreter-specific code is fragile and will make maintenance more 
difficult. Couldn't we instead have fallback_backtrace call the real 
UnwindTraceFn? I believe _Unwind_context is an opaque type, so it should 
be possible to have fallback_backtrace pass its own data there.
> (I note that under the interpreter we do
> not get line numbers for the innermost call frame, even on Linux.
> I haven't investigated this issue yet.)
>   
Hmm. There shouldn't be any problems here (on Linux) - do you have a 
test case?

Bryce