I'm working on a project that uses State Threads (ports/devel/st). For the 
unaware, it's a kinda neat library that implements totally userland threads 
with setjmp/longjmp, manually creating stacks and moving the stack pointer 
around.

It works well, except for one problem, attempting to get a backtrace of 
threads. Under linux, the state threads library uses execinfo to get a 
backtrace. FreeBSD has libexecinfo in ports which basically is just a wrapper 
around __builtin_frame_address and __builtin_return_address.

This also mostly works. Except occasionally __builtin_frame_address will 
segfault when executing in the context of a created stack. I'm kinda lost how 
to debug this, because gdb seems entirely confused as to what happened when the 
segfault is received, I'm guessing because this is a builtin. It works 99% of 
the time, but under certain (somewhat deterministic circumstances) 
__builtin_frame_address breaks.

I realize this is breaking a whole lot of assumptions by mallocing some memory, 
declaring it to be the new stack by using some assembly to move the SP 
register. But, I'm having trouble figuring out what's actually going wrong here.

When it does work, libexecinfo's backtrace() function keeps stepping back one 
frame at a time until it hits NULL. When it doesn't work, when it reaches the 
frame that should have a NULL frame after it, it segfaults. Breaking into gdb 
while using the stack that would kill backtrace() and executing "bt" works okay 
- gdb is able to read that frame anyway.

Another datapoint is that this worked fine in FreeBSD 3.0, but that's a pretty 
large set of changes to try to narrow down what's different now. 

Anyone have any idea where to even start with this? I'm having trouble finding 
anything that documents how frames work now, and what I'm possibly not doing 
when creating a new stack by hand.

_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"

Reply via email to