I initially thought that the backtrace was misleading or erroneous. After going back through, it appears that the problem is here:
my c code calls SAFE_APPLY_MASTER("low_cast_to_program" ...), which in turn calls mega_apply() which calls check_c_stack(), which is a macro. And that's where things fail. check_c_stack() calls low_error(), but it doesn't look like the error passed is valid.
So, it looks like there's at least something of a problem in the code that calls low_error(), and maybe something else that someone can help me tune a little better.
Now, I'm not sure why i'm out of c stack; there doesn't appear to be a whole lot on it; I've noticed that if I call the method that's at the heart of this problem [ABAddressBook sharedAddressBook] before (say, in the module initialization code), then subsequent calls through the wrapper seem to work, so it seems like the initial sharedAddressBook message does a bunch of set up that uses stack space temporarily, and that subsequent calls don't.
The question is, then, how do I deal with this? I can't affect the stack used internally by a vendor provided function, and I can't do a preemptive call, as it's heavy and not always used. Is there a way to make the check less strict? What are the implications of doing that?
Anyone else have any thoughts?
A gdb backtrace might give some hint about where it goes wrong; otherwise try adding some tracing of error.c:pike_throw().