In Pike 7.7 you need to call enter_compiler() before start_new_program() et al, and exit_compiler() when you're done.

I'm getting the following error while running some code that previously worked... nothing is printed about what the error is, and then I get an abort trap. The actual error seems to be coming from non- pike code, probably an objective c exception being thrown, but it's hard to tell for sure, as the code should convert the exception to an error. I can't think of a reason why that wouldn't be working. Is it possible that handle_error is being called when an error hasn't been thrown, but maybe something else bad has happened?

Error in handle_error in master object! Attempting to dump raw error: (may fail) Fatal in exit_on_error!

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