seg fault using octave with RH 6.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

seg fault using octave with RH 6.0

Timothy H. Keitt
Hi,

Anyone know what is going on with the back trace below?
I keep getting seg fault when I load one of my compiled
.oct file into octave.  Its odd because it only happens
with one routine and not any others.  (This particular
routine uses both set<> and map<,> from the STL.)  My
guess is that memory is getting corrupted somewhere.
The same code ran fine on RH 5.2.

Tim

#0  chunk_free (ar_ptr=0x405e1580, p=0x812f230) at malloc.c:2958
#1  0x40551505 in __libc_free (mem=0x812f238) at malloc.c:2932
#2  0x404e7f6e in __builtin_delete (ptr=0x812f238)
#3  0x401ab2df in Array<double>::ArrayRep::~ArrayRep (this=0x812f238,
    __in_chrg=3) at Array.h:76
#4  0x401ab31e in Array<double>::~Array (this=0x80cab98, __in_chrg=2)
    at Array.cc:67
#5  0x8081e92 in Array2<double>::~Array2 (this=0x80cab98, __in_chrg=2)
    at ../liboctave/Array2.h:97
#6  0x8081e76 in MArray2<double>::~MArray2 (this=0x80cab98, __in_chrg=2)
    at ../liboctave/MArray2.h:115
#7  0x8081a3a in Matrix::~Matrix (this=0x80cab98, __in_chrg=2) at oct-obj.h:137
#8  0x400ea8ce in octave_matrix::~octave_matrix (this=0x80cab90, __in_chrg=3)
    at ov-re-mat.h:72
#9  0x400f2aec in octave_value::~octave_value (this=0x80bbff4, __in_chrg=2)
    at ov.cc:367
#10 0x400b5ed4 in tree_constant::~tree_constant (this=0x80bbfe0, __in_chrg=3)
    at pt-const.h:148
#11 0x400cfb29 in symbol_record::define (this=0x80d0e60, t=0x80bc060)
    at symtab.cc:434
#12 0x400bc0ee in tree_identifier::assign (this=0x812dda0, rhs=@0xbffff8a8)
    at pt-fvc.cc:146
#13 0x400dcdb9 in octave_variable_reference::assign (this=0xbffff8a0,
    rhs=@0xbffff8a8) at variables.cc:139
#14 0x400b8f42 in tree_simple_assignment_expression::eval (this=0xbffff8e0,
    print=false) at pt-exp.cc:761
#15 0x400e1030 in bind_ans (val=@0x80eff64, print=0) at variables.cc:1542
#16 0x400bca8d in tree_identifier::eval (this=0x812f280, print=false,
    nargout=0, args=@0xbffffa10) at pt-fvc.cc:378
#17 0x400bcf76 in tree_indirect_ref::eval (this=0x812f5b0, print=false,
    nargout=1, args=@0xbffffa10) at pt-fvc.cc:472
#18 0x400c39af in tree_index_expression::eval (this=0x812f590, print=false)
    at pt-mvr.cc:142
#19 0x400c190b in tree_statement_list::eval (this=0x812f5f8, print=true)
    at pt-misc.cc:137
#20 0x400d76c1 in main_loop () at toplev.cc:285
#21 0x80582ee in main (argc=1, argv=0xbffffb44) at octave.cc:624
#22 0x40510cb3 in __libc_start_main (main=0x80579f4 <main>, argc=1,
    argv=0xbffffb44, init=0x80553b0 <_init>, fini=0x8081f30 <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffb3c)
    at ../sysdeps/generic/libc-start.c:78

--
Timothy H. Keitt
National Center for Ecological Analysis and Synthesis
735 State Street, Suite 300, Santa Barbara, CA 93101
Phone: 805-892-2519, FAX: 805-892-2510
http://www.nceas.ucsb.edu/~keitt/




Reply | Threaded
Open this post in threaded view
|

seg fault using octave with RH 6.0

John W. Eaton-6
On 12-May-1999, Timothy H. Keitt <[hidden email]> wrote:

| Anyone know what is going on with the back trace below?
| I keep getting seg fault when I load one of my compiled
| .oct file into octave.  Its odd because it only happens
| with one routine and not any others.  (This particular
| routine uses both set<> and map<,> from the STL.)  My
| guess is that memory is getting corrupted somewhere.
| The same code ran fine on RH 5.2.

That is almost always the problem when a crash happens inside malloc.

If you have enough memory available on your system, you might be able
to get a better clue by linking Octave with the Electric Fence library
and running your example again under gdb.  That is more likely to
catch the actual location of the problem.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: seg fault using octave with RH 6.0

Martin v. Loewis
In reply to this post by Timothy H. Keitt
> Anyone know what is going on with the back trace below?

That's easy: The memory management is messed up (or you are in the
process of messing it up right now). That means: Either you are
deleting an object that has already been deleted, or some earlier
delete made that error, or somebody was overwriting memory through a
bogus pointer.

You might be able to track this down via malloc debugging, please read
the libc info on mcheck(3) and mtrace(3).

Hope this helps,
Martin

P.S. I know nothing about Octave or its loadable modules.