seg-fault of octave on MacOSX

[Jean-François Mertens]

On 05 Dec 2007, at 22:43, John W. Eaton wrote:

> On  5-Dec-2007, Jean-François Mertens wrote:
>
> | So this seems really a compiler problem (and specific to the Mac-
> | Intel back-end?),
> | that we have to solve for ourselves _ if we can just hope for your
> | guidance
> | in reducing this to an example not involving octave ..
>
> I have no idea what I can do to help you.  As I've mentioned before, I
> don't have a Mac OS X system, so I can't debug this problem.

The problem occurs at the last command, "end_unwind_protect" , of the
first test in ov_fcn_handle.cc (line 683).

Under gdb, this gives the following backtrace:

  ...
 > end_unwind_protect

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x756f6d79
0x756f6d79 in ?? ()
(gdb) bt
#0  0x756f6d79 in ?? ()
#1  0x1176fd10 in std::basic_filebuf<char, std::char_traits<char>  
 >::_M_terminate_output (this=0x12ec40b0) at /sw/.bld/ 
gcc42-4.2.2-1000/darwin_objdir/i686-apple-darwin8/libstdc++-v3/ 
include/bits/fstream.tcc:765
#2  0x010e1f59 in save_vars (os=@0xbfff7fa8, pattern=@0x12ec3fa8,  
fmt=LS_BINARY, save_as_floats=-1073775180) at load-save.cc:1122
#3  0x010e7e96 in save_vars (argv=@0xbfff7fb0, argv_idx=-1073774976,  
argc=6, os=@0xbfff7fb0, fmt=LS_BINARY, save_as_floats=0,  
write_header_info=1) at load-save.cc:1321
#4  0x010e8f68 in Fsave (args=@0x12ec3ee8) at /usr/include/c++/4.0.0/ 
fstream:647
#5  0x012a919d in octave_builtin::do_multi_index_op (this=0x1345eec0,  
nargout=0, args=@0x12ec3ee8) at ov-builtin.cc:104
#6  0x012a8b29 in octave_builtin::subsref (this=0x1345eec0,  
type=@0x12b94cc4, idx=@0xbfff8678, nargout=0) at ov-builtin.cc:54
#7  0x01297ae5 in octave_value::subsref (this=0xbfff8688,  
type=@0x12b94cc4, idx=@0xbfff8678, nargout=0) at ov.cc:783
#8  0x013c1681 in tree_index_expression::rvalue (this=0x12b94ca0,  
nargout=0) at pt-idx.cc:352
#9  0x013dd2ba in tree_statement::eval (this=0x12e1cdd0, silent=0,  
nargout=0, in_function_body=false) at pt-stmt.cc:133
#10 0x013dd6e6 in tree_statement_list::eval (this=0x12e3df70,  
silent=false, nargout=0) at pt-stmt.cc:190
#11 0x013b9054 in tree_unwind_protect_command::eval (this=0x12ec3e30)  
at pt-except.cc:240
#12 0x013dd1c7 in tree_statement::eval (this=0x12bda420, silent=0,  
nargout=0, in_function_body=false) at pt-stmt.cc:102
#13 0x013dd6e6 in tree_statement_list::eval (this=0x12ec3e60,  
silent=false, nargout=0) at pt-stmt.cc:190
#14 0x012056b9 in main_loop () at toplev.cc:225
#15 0x01193631 in octave_main (argc=5, argv=0xbfff8c60, embedded=0)  
at octave.cc:801
#16 0x00001fd0 in main (argc=5, argv=0xbfff8c60) at main.c:35
#17 0x0000193e in _start ()
#18 0x00001865 in start ()

Suggestion on how to narrow this test sequence (20 lines currently)  
further down ?
Or do you see some fortran routine that might have been called during  
the test sequence ?


> Since the problem seems to be caused by mixing compiler versions, my
> advice would be "don't do that".

Wouldn't make us find the problem...

JF