octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices


From: Rik
Subject: [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices
Date: Mon, 22 Feb 2021 23:02:01 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.66 Safari/537.36

Follow-up Comment #7, bug #60101 (project octave):

Here is another partial backtrace for a version compiled with "-g -O0" in
which I set a breakpoint in Fsymbfact and then continued after the breakpoint
was hit.


#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007f6b32c05921 in __GI_abort () at abort.c:79
#2  0x00007f6b32c4e967 in __libc_message (action=action@entry=do_abort, 
    fmt=fmt@entry=0x7f6b32d7bb0d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007f6b32c559da in malloc_printerr (str=str@entry=0x7f6b32d7d720
"munmap_chunk(): invalid pointer")
    at malloc.c:5342
#4  0x00007f6b32c5cfbc in munmap_chunk (p=0x7f6afc52ac10) at malloc.c:2846
#5  __GI___libc_free (mem=0x7f6afc52ac20) at malloc.c:3127
#6  0x00007f6b35573e7a in
__gnu_cxx::new_allocator<std::_List_node<octave::symbol_record> >::deallocate
(
    this=0x7f6b0b321cb0, __p=0x7f6afc52ac20) at
/usr/include/c++/7/ext/new_allocator.h:125
#7  0x00007f6b35573334 in
std::allocator_traits<std::allocator<std::_List_node<octave::symbol_record> >
>::deallocate (__a=..., __p=0x7f6afc52ac20, __n=1) at
/usr/include/c++/7/bits/alloc_traits.h:462
#8  0x00007f6b35571bf8 in std::__cxx11::_List_base<octave::symbol_record,
std::allocator<octave::symbol_record> >::_M_put_node (this=0x7f6b0b321cb0,
__p=0x7f6afc52ac20) at /usr/include/c++/7/bits/stl_list.h:387
#9  0x00007f6b3556fb4d in std::__cxx11::_List_base<octave::symbol_record,
std::allocator<octave::symbol_record> >::_M_clear (this=0x7f6b0b321cb0) at
/usr/include/c++/7/bits/list.tcc:80
#10 0x00007f6b35570da9 in std::__cxx11::list<octave::symbol_record,
std::allocator<octave::symbol_record> >::_M_move_assign (this=0x7f6b0b321cb0,
__x=...) at /usr/include/c++/7/bits/stl_list.h:1840
#11 0x00007f6b3556f1b9 in std::__cxx11::list<octave::symbol_record,
std::allocator<octave::symbol_record> >::operator= (this=0x7f6b0b321cb0,
__x=...) at /usr/include/c++/7/bits/stl_list.h:765
#12 0x00007f6b3556e37d in octave::symbol_info_accumulator::append_list
(this=0x7f6b0b321e00, frame=...)
    at libinterp/corefcn/stack-frame.cc:1016
#13 0x00007f6b3556d9b9 in
octave::symbol_info_accumulator::visit_scope_stack_frame (this=0x7f6b0b321e00,

    frame=...) at libinterp/corefcn/stack-frame.cc:912
#14 0x00007f6b3556a21a in octave::scope_stack_frame::accept
(this=0x7f6afc006a90, sfw=...)
    at libinterp/corefcn/stack-frame.cc:2465
#15 0x00007f6b3556503b in octave::stack_frame::all_variables
(this=0x7f6afc006a90)
    at libinterp/corefcn/stack-frame.cc:1153
#16 0x00007f6b350ca9ce in octave::stack_frame::get_symbol_info
(this=0x7f6afc006a90)
    at libinterp/corefcn/stack-frame.h:273
#17 0x00007f6b350c7e32 in octave::call_stack::get_symbol_info
(this=0x7f6afc005960)
    at libinterp/corefcn/call-stack.cc:856
#18 0x00007f6b3500d087 in octave::tree_evaluator::get_symbol_info
(this=0x7f6afc005838)
    at libinterp/parse-tree/pt-eval.cc:4244
#19 0x00007f6b351838ce in octave::event_manager::set_workspace
(this=0x7f6afc005de0)
    at libinterp/corefcn/event-manager.cc:167
#20 0x00007f6b353d602f in octave::base_reader::octave_gets
(this=0x7f6afc43c6d0, prompt="octave:5> ", 
    eof=@0x7f6afc43c6e0: false) at libinterp/corefcn/input.cc:818
#21 0x00007f6b353d6624 in octave::terminal_reader::get_input
(this=0x7f6afc43c6d0, prompt="octave:5> ", 
    eof=@0x7f6b0b3221c3: false) at libinterp/corefcn/input.cc:991
#22 0x00007f6b34fbaf6f in octave::input_reader::get_input
(this=0x7f6afc228560, prompt="octave:5> ", 
    eof=@0x7f6b0b3221c3: false) at libinterp/corefcn/input.h:282
#23 0x00007f6b34fd3c51 in octave::push_parser::run (this=0x7f6afc22f1c0)
    at libinterp/parse-tree/oct-parse.yy:4958


If I try repeatedly I find the backtrace points to different places.  I think
this just means that the original call does overrun memory and it is random
chance which parts get affected.

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?60101>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]