Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 10 Jan 2013 13:01:06 -0600
From:      Kevin Day <toasty@dragondata.com>
To:        hackers@freebsd.org
Subject:   __builtin_frame_address broken with self created stack?
Message-ID:  <4ADFB966-782C-4A4A-883C-0A9CFC0EC7A8@dragondata.com>

next in thread | raw e-mail | index | archive | help

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.=20=


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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ADFB966-782C-4A4A-883C-0A9CFC0EC7A8>