[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/
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices on Windows, anonymous, 2021/02/22
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices on Windows, Rik, 2021/02/22
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices on Windows, anonymous, 2021/02/22
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices on Windows, anonymous, 2021/02/22
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices on Windows, Rik, 2021/02/22
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices on Windows, Dmitri A. Sergatskov, 2021/02/22
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices on Windows, Dmitri A. Sergatskov, 2021/02/22
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices, Rik, 2021/02/22
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices,
Rik <=
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices, Rik, 2021/02/22
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices, Rik, 2021/02/23
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices, Rik, 2021/02/23
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices, John W. Eaton, 2021/02/23
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices, Rik, 2021/02/23
- [Octave-bug-tracker] [bug #60101] symbfact crashes for dense matrices, Rik, 2021/02/24