Re: New parser and command line functions

[Rik]

On 03/15/2013 11:13 AM, John W. Eaton wrote:
> On 03/15/2013 12:10 PM, Rik wrote:
>
>> I thought it might be something like that so I have tried various versions
>> of Bison (2.4.1, 2.5.0, 2.6.5, 2.7.0) but I always get the same segfault.
>> Octave has been compiled with both -O2 which might re-order things, but
>> also '-g -O0' which shouldn't.  Michael and I are using different versions
>> of gcc.  I'm quite a ways back on 4.4.3 and he is up on 4.7 something.
>
> OK, could you either set a breakpoint in the push_fcn_symtab rule in
> oct-parse.yy or use the attached patch to find out if this rule is
> executed, or what the variable values are such that the scope is not
> allocated properly?  Or, that it is allocated properly but it is somehow
> lost between that allocation and the point later where it is needed?
>
> jwe
>
>
With revision 16319:54c4b4b58a24 and the patch applied,

octave:1> function nada
allocated scope 50 for function
lexer.reading_script_file 0
parser.curr_fcn_depth 1
parser.parsing_subfunctions 0
parser.primary_fcn_scope 50
> endfunction
@: interpfcn/symtab.h:2039: static void
symbol_table::set_curr_fcn(octave_user_function*, int): Assertion `scope !=
xtop_scope && scope != xglobal_scope' failed.
panic: Aborted -- stopping myself...
attempting to save variables to 'octave-workspace'...
save to 'octave-workspace' complete
Abort

Using gdb, the values at symtab.h:2039 are
scope: 1
xtop_scope: 1
xglobal_scope: 0

When I have an m-file, nada.m, which contains the blank function I get

allocated scope 50 for function
lexer.reading_script_file 0
parser.curr_fcn_depth 1
parser.parsing_subfunctions 0
parser.primary_fcn_scope 50

And inside gdb the values at symtab.h:2039 are
scope: 50
xtop_scope: 1
xglobal_scope: 0

This works.

The scope is getting allocated according to the print statement but it
doesn't seem to make it all the way down.

Okay, I should have thought of this much sooner.  If I run with -f, i.e.,
no initialization files then everything works correctly.  I have eval
statements in my octaverc and this seems to be a problem both for m-files
and on the command line.

This causes a segfault
eval ('y = sin (1);')
function nada
endfunction

But

function nada
endfunction

does not.

I would guess that eval isn't completely cleaning up after itself.

--Rik