On Sep 10, 2009, at 7:00 PM, Luke Daley wrote:
On 10/09/2009, at 11:55 PM, Adam R. Maxwell wrote:
ISTR the crash I saw on Snow Leopard looked like
it was calling
malloc (via strdup in mode.c) before the system's malloc zone was
set up. Is that still the case?
TBH, it was very difficult to determine exactly what was going on. I
was operating under the assumption that the problem was due to
something in our read() implementation calling something that in turn
invoked read() causing a recursion. Your explanation makes more sense.
I'll test this and let you know.
That was just my guess based on the stack trace I saw, and a glance at
the code confirmed that mode_contains calls strdup. If my guess is
correct, that particular issue could likely worked around by using
vm_allocate instead of strdup; I never got around to trying it myself,
though. I have yet to look at the Darwin source to see why Apple is
calling arc4random when creating the scalable zone now...
Also, for my
own curiosity, is it a problem that your read override
doesn't appear to be async-signal safe?
Absolutely no idea.
How would I make it async-signal safe
Well, my understanding is that you'd be limited to functions listed in
the man page for sigaction(2). So strdup/getenv/etc would be off
limits. Not much fun.
and why would I do this?
My guess is that it would matter if code using the library relies on
calling read() from a signal handler. Signal handling is outside my
area of expertise, so I was hoping someone else would have an answer :).