dispatch Segfault

[John W. Eaton]

On 27-Jan-2009, Gregor Beck wrote:

| Bug report for Octave 3.1.51+ configured for x86_64-unknown-linux-gnu
| 
| Description:
| -----------
| 
| make check fails for dispatch.cc
| sometimes with Segmentation fault
| 
| from test/fntests.log:
| 
| >>>>> processing /media/Data2/grb/octave/mercurial/octave/src/DLD-FUNCTIONS/dispatch.cc
|   ***** test # replace base m-file
|  echo_to_file ('function a=dispatch_x(a)', "dispatch_x.m");
|  dispatch('dispatch_x','length','string')
|  assert(dispatch_x(3),3)
|  assert(dispatch_x("a"),1)
|  sleep (2);
|  echo_to_file ('function a=dispatch_x(a),++a;', "dispatch_x.m");
|  rehash();
|  assert(dispatch_x(3),4)
|  assert(dispatch_x("a"),1)
| !!!!! test failed
| `dispatch_x' undefined near line 5 column 9
| 
| Backtrace
| ---------
| 
| Core was generated by `/media/Data2/grb/octave/mercurial/octave/src/octave --no-initial-path --path=/l'.
| Program terminated with signal 11, Segmentation fault.
| [New process 31124]
| #0  0x00007f930a102420 in getcwd () from /lib/libc.so.6
| (gdb) bt
| #0  0x00007f930a102420 in getcwd () from /lib/libc.so.6
| #1  0x00007f930fac7757 in octave_getcwd () at lo-sysdep.cc:65
| #2  0x00007f930fac93c5 in octave_env::do_getcwd (this=0x12f7e40) at oct-env.cc:397
| #3  0x00007f930fac9dc2 in octave_env::getcwd () at oct-env.cc:139
| #4  0x00007f931092f560 in load_path::dir_info::update (this=0x153cdd0) at load-path.cc:62
| #5  0x00007f931092f78d in load_path::do_update (this=0x151e6c0) at load-path.cc:794
| #6  0x00007f9310a753b9 in symbol_table::fcn_info::fcn_info_rep::find (this=0x253a0f0, args=0x23f5530, arg_names=@0x7fff196c11a0, evaluated_args=@0x7fff196c1150, args_evaluated=@0x7fff196c127f) at load-path.h:86
| #7  0x00007f9310a753e5 in symbol_table::fcn_info::fcn_info_rep::find (this=0x253a0f0, args=0x23f5530, arg_names=@0x7fff196c11a0, evaluated_args=@0x7fff196c1150, args_evaluated=@0x7fff196c127f) at symtab.cc:692
| #8  0x00007f9310a753e5 in symbol_table::fcn_info::fcn_info_rep::find (this=0x253a0f0, args=0x23f5530, arg_names=@0x7fff196c11a0, evaluated_args=@0x7fff196c1150, args_evaluated=@0x7fff196c127f) at symtab.cc:692
| #9  0x00007f9310a753e5 in symbol_table::fcn_info::fcn_info_rep::find (this=0x253a0f0, args=0x23f5530, arg_names=@0x7fff196c11a0, evaluated_args=@0x7fff196c1150, args_evaluated=@0x7fff196c127f) at symtab.cc:692
| 
| ...
| 
| #9241 0x00007f9310a753e5 in symbol_table::fcn_info::fcn_info_rep::find (this=0x253a0f0, args=0x23f5530, arg_names=@0x7fff196c11a0, evaluated_args=@0x7fff196c1150, args_evaluated=@0x7fff196c127f) at symtab.cc:692
| #9242 0x00007f9310a753e5 in symbol_table::fcn_info::fcn_info_rep::find (this=0x253a0f0, args=0x23f5530, arg_names=@0x7fff196c11a0, evaluated_args=@0x7fff196c1150, args_evaluated=@0x7fff196c127f) at symtab.cc:692
| 
| ...

I can't reproduce the segfault, but I also see problems with the
dispatch test.

It looks like you are seeing a deep recursion here.  I don't see why a
getcwd call would fail.

See also

  https://www-old.cae.wisc.edu/pipermail/octave-maintainers/2009-January/010300.html

Now that we can use class methods for dispatch, should we continue to
support this older way of dispatching on type?  I'd like to see it go
away.

jwe