Pike 7.7: THIS_COMPILATION.lex

[Bill Welliver]

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.

[Bill Welliver]

Thanks for the tip... I'll give it a try :)

On Fri, 11 Jul 2008, Henrik Grubbström (Lysator) @ Pike (-) developers forum wrote:

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

[Bill Welliver]

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

[Bill Welliver]

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