Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
From: James Bielman <jamesjb@ja...> - 2006-01-13 15:59:55
I think the reason backtracing across sigtrap handlers on Win32 is
broken is due to incorrect initialization of *CONTROL-STACK-END* and
the corresponding fields of the initial 'thread' structure:
IIUC, we don't switch stacks on Win32 when calling into Lisp, but the
'thread' structure and *CONTROL-STACK-START*/*CONTROL-STACK-END*
variables are initialized as though we were (in 'create_thread_struct').
Later on, 'arch_os_thread_init' modifies only the 'control_stack_end'
field of the 'thread' structure with the address of the current SEH
handler (not the stack end AFAICT), but doesn't update the Lisp
When backtracing, due to the bogus value of *CONTROL-STACK-END*, some
of the runtime function return addresses look like they are on the
control stack, and this stops the backtracing (see X86-CALL-CONTEXT
Honestly, I'm not sure how this is working at all, but all my attempts
to fix it so far result in crashes pretty early in warm-init (and the
MinGW gdb is not very helpful in figuring out where).