Re: getcontext() -> Bus error?
Re: getcontext() -> Bus error?
- Subject: Re: getcontext() -> Bus error?
- From: Terry Lambert <email@hidden>
- Date: Mon, 25 Feb 2008 14:25:32 -0800
On Feb 23, 2008, at 5:16 PM, Kevin Van Vechten wrote:
On Feb 23, 2008, at 11:23 AM, Duckki Oe wrote:
I was experiencing difficulties with getcontext/makecontext last
night.
(you know.. getting SIGBUS, seg fault)
And I've figured out that Darwin's ucontext_t is not like that of
linux's.
ucontext_t on Darwin (I'm using Mac OS X 10.5.2.) does not contain
the mcontext_t,
which stores machine dependent context. And let users allocate the
mcontext_t buffer
and point it in uc_mcontext member of ucontext_t. Or it just
assumes mcontext_t buffer
follows the ucontext_t variable. You may need to look into the
actual ucontext_t structure in
/usr/include/sys/ucontext.h.
It's better to allocate ucontext_t using malloc with the length of
sizeof(ucontext_t) +
sizeof(*((mcontext_t)0)). Note that mcontext_t is just a pointer.
Now it should work fine.
This is not documented on the man pages.
On the other hand, Linux's ucontext_t CONTAINS the whole structure
of mcontext_t and
you don't have to care about additional buffer.
This was the issue I originally replied to on this thread. The
ucontext_t only includes mcontext_t when _XOPEN_SOURCE is defined
prior to including the header files (see /usr/include/sys/_structs.h).
We generally do not want people poking around in the mcontext, and we
treat it as an opaque array of bytes. It only has real meaning when
the header file has the explicit type information in scope.
So if you are writing a threads package, or you are writing a
debugger, it's meaningful; otherwise it's No User Serviceable Parts
Inside.
The primary use for it is for the use of the third argument to the
SA_SIGINFO, the utility of which is limited to context chaining, the
stack pointer, and the stack in use at the time the signal handler
fires:
<http://www.opengroup.org/onlinepubs/009695399/basedefs/
ucontext.h.html>
In this mode, you get an mcontext that happens to be laid out on the
signal stack. For i386, there are two possible implementation of the
constext, depending on whether your applciation is 32 or 64 bit, and
for each of these there is a conforming namespace (where the element
names begin with __ to take them out of the implementation namespace),
and a non-conforming (which exists solely for source backward
compatibility until we can get people to fully update their code tot
he conforming implementation). On PPC, the situation is more
complicated, and there are a number of other layouts for the signal
stack, due to binary compatibility issues, as well as the same
namespace juggling.
The mcontext itself is not intended for use except by the kernel, and
by applications that specifically need to implement dumping of process
state, such as debuggers; in fact, this is strictly specified by POSIX
to place the contents of the mcontext outside the namespace:
<http://www.opengroup.org/onlinepubs/009695399/functions/getcontext.html
>
"Conforming applications should not modify or access the uc_mcontext
member of ucontext_t.
A conforming application cannot assume that context includes any
process-wide static data,
possibly including errno. Users manipulating contexts should take
care to handle these
explicitly when required."
Also, as has been previously noted, the getcontext/setcontext//
makecontext/swapcontext implementation exists solely because it was
deprecated by not removed from the UNIX03 standard, and so we had to
support it. Expect it to disappear at some point, as soon as we no
longer need it to pass conformance testing.
So basically, you are playing with something that's probably going to
bite down on you pretty hard, unless you read the kernel and libc
sources, and then are very, very careful in using it (avoiding it
entirely, if at all possible). Even then, you are likely not going to
get explicit register window flushes, etc., unless you go out of your
way to put the assembly barriers in yourself.
-- Terry
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden