I'm testing a module on a recent 7.7 after using 7.7.34 for quite a while. I've run into a problem with some code that generates a program dynamically using start_new_program(). One of the first things that I do is add a constant using add_string_constant()., That's where the module dumps core. Apparently add_string_constant() and friends look at THIS_COMPILATION.lex and try to add strings based on the filename and such. Since I'm working with a C module, I'm not manipulating that, so I'm not sure how to get around it. Any suggestions?
#0 store_prog_string (str=0x92a1ba10) at /Users/hww3/Downloads/Pike- v7.7-snapshot/src/program.c:6086 #1 0x000bac9a in add_constant (name=0x334560, c=0xbfffe1e8, flags=8) at /Users/hww3/Downloads/Pike-v7.7-snapshot/src/program.c:5179 #2 0x000bb0ef in simple_add_constant (name=0x5512d8 "\002", c=0x5512d8, flags=5575384) at /Users/hww3/Downloads/Pike-v7.7-snapshot/ src/program.c:5261 #3 0x000bb2bb in add_string_constant (name=0x5512d8 "\002", str=0x5512d8 "\002", flags=5575384) at /Users/hww3/Downloads/Pike-v7.7- snapshot/src/program.c:5333
The data in #3 and friends seems bogus, as the values I'm inserting in this example are string constants. Not sure if that's due to the problem that happens later or not.
Bill
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'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!
A gdb backtrace might give some hint about where it goes wrong; otherwise try adding some tracing of error.c:pike_throw().
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().
pike-devel@lists.lysator.liu.se
-
Bill Welliver -
H. William Welliver III
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum