Re: New parser and command line functions

[John W. Eaton]

On 03/15/2013 04:14 PM, Rik wrote:
> 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.

Thanks for the info.  I think I see what the problem is now.

Are you settings graphics_toolkit to fltk?  Or doing something else that 
installs a readline event hook callback function?  I see the crash if I 
set graphics_toolkit to fltk, but not otherwise.

Anyway, the the parser and lexer currently keep track of the local 
function scope when parsing by setting the current symbol table scope, 
which is global information.  Then if another parser is started (say for 
an eval, or parsing any other function as could happen when a callback 
function is evaluated for the fist time) the global scope info is reset. 
 If that happens while anther parser is active and in the middle of 
parsing a function, then a crash like you are seeing can happen.  Oops. 
 The fix is to store the scope used for parsing in the parser or lexer 
class.  I'll try to take care of that soon.

jwe