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"