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 :).