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.