bugGNU Octave - Bugs: bug #54656, Crash with signal 11 (segfault)

 
 

bug #54656: Crash with signal 11 (segfault)

Submitter:  Olaf Bousche <olaf789>
Submitted:  Thu 13 Sep 2018 01:10:59 PM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Duplicate Assigned to:  None
Originator Name:  Olaf789 Open/Closed:  * Closed
Release:  * 4.4.1 Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 13 Sep 2018 09:08:28 PM UTC, comment #10: 

First of all thanks everyone for confirming that I was not crazy. I did not expect this to be picked so fast or I would have responded earlier.

I'll stick with the CLI version for crashing programs with clear statements. I hope it gets fixed in the next release.

Olaf Bousche <olaf789>
Thu 13 Sep 2018 07:36:15 PM UTC, comment #9: 

With that, I think this is probably identical to bug #54431. Either that one or this one can be closed as duplicate, but all test cases should be looked at when fixing to make sure it's the same thing. The other bug had to do with user-defined objects, so I thought maybe there is an extra wrinkle with the workspace view having to eval a user-defined disp function to get the string representation of the object.

Mike Miller <mtmiller>
Group Member
Thu 13 Sep 2018 07:32:28 PM UTC, comment #8: 

Thanks. With the data file I can confirm that the script crashes in 4.4.1 but does not crash in 5, so I believe it is the 'clear' commands that are triggering it just like the other bug report.

See bug #54443 for the report about 'clear' causing a workspace view refresh which has been fixed on the default branch, which avoids this crash.

Mike Miller <mtmiller>
Group Member
Thu 13 Sep 2018 07:31:20 PM UTC, comment #7: 

I tested with 4.4.1.  Yes, it seems related to clearing symbols while a script is executing.  I can trigger the crash with this script:


a = ones (10000000, 1);
b = sort (a);
clear a;
b = [];
a = ones (1048576, 1);
b = sort (a);


Doesn't crash with the dev version, but you are right that it doesn't mean that the issue is really fixed.  Probably we are just avoiding it.  I'm guessing the real problem is that the GUI might access the contents of a symbol_scope object while it is being modified.  So we may need some locking, or a copy-on-write mechanism for this use case(?), or we need to avoid  passing symbol scope objects directly to the interpreter and only pass summary info about them.

John W. Eaton <jwe>
Group administrator
Thu 13 Sep 2018 07:17:59 PM UTC, comment #6: 

Trying to attach the file again.  I didn't notice any messages about size limits.  It's 680k.


(file #45001)

John W. Eaton <jwe>
Group administrator
Thu 13 Sep 2018 07:11:08 PM UTC, comment #5: 

Also the Currency2.txt file is still not attached to this bug report, was it over the attachment file size limit?

Mike Miller <mtmiller>
Group Member
Thu 13 Sep 2018 07:09:35 PM UTC, comment #4: 

This looks very similar to the crash reported in bug #54431. The bug there looks like a simultaneous access to the symbol table while a script is running and the workspace view is being updated.

jwe - did you test with 4.4.1 or 5? Because a recent change on the default branch made it so that the workspace view is not updated when a script calls the 'clear' command. That might be what is triggering the crash in this script. It would be useful to see if the script crashes in 4.4.1 but not in 5 because of that.

But that doesn't mean the underlying bug is fixed. As I posted on bug #54431, the crash can still be triggered by entering debug mode and rapidly stepping through the script by holding down Enter, which does cause a workspace view refresh on every prompt.

Mike Miller <mtmiller>
Group Member
Thu 13 Sep 2018 02:06:27 PM UTC, comment #3: 

I can confirm the crash.  After attaching gdb to the octave-gui process, it stops with


Thread 1 "octave-gui" received signal SIGSEGV, Segmentation fault.
std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (__str=<error reading variable: Cannot access memory at address 0x7f82b063c92010>, this=0x7fffef508a30)
    at /usr/include/c++/8/ext/new_allocator.h:86
86              ~new_allocator() _GLIBCXX_USE_NOEXCEPT { }


Interesting bits from "thread apply all bt":


Thread 13 (Thread 0x7f82d97fd700 (LWP 25653)):
---Type <return> to continue, or q <return> to quit---
#0  clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:78
#1  0x00007f830955eca2 in create_thread (pd=pd@entry=0x7f82c0ffc700, attr=attr@entry=0x7f82d97f3b60, stopped_start=stopped_start@entry=0x7f82d97f391e, stackaddr=stackaddr@entry=0x7f82c0ff4b80,
    thread_ran=thread_ran@entry=0x7f82d97f391f) at ../sysdeps/unix/sysv/linux/createthread.c:100
#2  0x00007f83095606f3 in __pthread_create_2_1 (newthread=<optimized out>, attr=<optimized out>, start_routine=<optimized out>, arg=<optimized out>) at pthread_create.c:797
#3  0x00007f8306a6294a in fftw_spawn_loop () from /usr/lib/x86_64-linux-gnu/libfftw3_threads.so.3
#4  0x00007f8306a62c26 in ?? () from /usr/lib/x86_64-linux-gnu/libfftw3_threads.so.3
#5  0x00007f83068c6eb7 in ?? () from /usr/lib/x86_64-linux-gnu/libfftw3.so.3
#6  0x00007f830a10a2c6 in octave::fftw::fft(double const*, std::complex<double>*, unsigned long, unsigned long, long, long) () at /home/jwe/src/octave-stable/liboctave/numeric/oct-fftw.cc:867
#7  0x00007f8309e6205d in NDArray::fourier(int) const () at /home/jwe/src/octave-stable/liboctave/array/dNDArray.cc:122
#8  0x00007f830b3e8f85 in do_fft(octave_value_list const&, char const*, int) () at /home/jwe/src/octave-stable/liboctave/array/dim-vector.h:159
#9  0x00007f830b3e9819 in Ffft(octave_value_list const&, int) () at /home/jwe/src/octave-stable/libinterp/corefcn/fft.cc:209
#10 0x00007f830b12cc4e in octave_builtin::call(octave::tree_evaluator&, int, octave_value_list const&) () at /home/jwe/src/octave-stable/libinterp/octave-value/ov-builtin.cc:65
#11 0x00007f830b2b0bcc in octave::tree_evaluator::visit_index_expression(octave::tree_index_expression&) () at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:1381
#12 0x00007f830b16b03e in octave::tree_evaluator::evaluate (this=0x7f82b0000ea0, expr=0x7f82b061f3b0, nargout=<optimized out>) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.h:300
#13 0x00007f830b2af372 in octave::tree_evaluator::visit_simple_assignment(octave::tree_simple_assignment&) () at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:2224
#14 0x00007f830b16b03e in octave::tree_evaluator::evaluate (this=0x7f82b0000ea0, expr=0x7f82b061f7b0, nargout=<optimized out>) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.h:300
#15 0x00007f830b2ad22c in octave::tree_evaluator::visit_statement(octave::tree_statement&) () at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:2337
#16 0x00007f830b2a3cd0 in octave::tree_statement::accept (tw=..., this=0x7f82b061f7f0) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-stmt.h:115
#17 octave::tree_evaluator::visit_statement_list (this=0x7f82b0000ea0, lst=...) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:2406
#18 0x00007f830b2ac1f9 in octave::tree_statement_list::accept (tw=..., this=0x7f82b061d460) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-stmt.h:190
#19 octave::tree_evaluator::visit_simple_for_command(octave::tree_simple_for_command&) () at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:882
#20 0x00007f830b2ad160 in octave::tree_evaluator::visit_statement(octave::tree_statement&) () at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:2315
#21 0x00007f830b2a3cd0 in octave::tree_statement::accept (tw=..., this=0x7f82b0620460) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-stmt.h:115
#22 octave::tree_evaluator::visit_statement_list (this=0x7f82b0000ea0, lst=...) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:2406
#23 0x00007f830b200244 in octave::tree_statement_list::accept (tw=..., this=<optimized out>) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-stmt.h:190
#24 octave_user_script::call(octave::tree_evaluator&, int, octave_value_list const&) () at /home/jwe/src/octave-stable/libinterp/octave-value/ov-usr-fcn.cc:215
#25 0x00007f830b2a66b1 in octave::tree_evaluator::visit_identifier(octave::tree_identifier&) () at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:1128
#26 0x00007f830b16b03e in octave::tree_evaluator::evaluate (this=0x7f82b0000ea0, expr=0x7f82b0600bd0, nargout=<optimized out>) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.h:300
#27 0x00007f830b2ad22c in octave::tree_evaluator::visit_statement(octave::tree_statement&) () at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:2337
---Type <return> to continue, or q <return> to quit---
#28 0x00007f830b2a3cd0 in octave::tree_statement::accept (tw=..., this=0x7f82b02fc3d0) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-stmt.h:115
#29 octave::tree_evaluator::visit_statement_list (this=this@entry=0x7f82b0000ea0, lst=...) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-eval.cc:2406
#30 0x00007f830b573dce in octave::tree_statement_list::accept (tw=..., this=<optimized out>) at /home/jwe/src/octave-stable/libinterp/parse-tree/pt-stmt.h:190
#31 octave::interpreter::main_loop() () at /home/jwe/src/octave-stable/libinterp/corefcn/interpreter.cc:995
#32 0x00007f830b5797ca in octave::interpreter::execute() () at /home/jwe/src/octave-stable/libinterp/corefcn/interpreter.cc:717
#33 0x00007f830bbc2eeb in octave::octave_interpreter::execute() () at /home/jwe/src/octave-stable/libgui/src/main-window.cc:128
#34 0x00007f8308215072 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#35 0x00007f8308b9f4a1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#36 0x00007f8308ba6ae0 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#37 0x00007f83081eb579 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#38 0x00007f83081ee56b in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#39 0x00007f830823dc03 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#40 0x00007f83020f4287 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#41 0x00007f83020f44c0 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#42 0x00007f83020f454c in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#43 0x00007f830823d223 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#44 0x00007f83081ea24b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#45 0x00007f8308039176 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#46 0x00007f8308042d47 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#47 0x00007f830955ff2a in start_thread (arg=0x7f82d97fd700) at pthread_create.c:463
#48 0x00007f830948fedf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95


and the thread where the crash happens:


Thread 1 (Thread 0x7f82fac05b80 (LWP 25621)):
#0  std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string (__str=<error reading variable: Cannot access memory at address 0x7f82b063c92010>, this=0x7fffef508a30)
    at /usr/include/c++/8/ext/new_allocator.h:86
#1  octave::symbol_record::symbol_record_rep::name[abi:cxx11]() const (this=0x7f82b063c92000) at /home/jwe/src/octave-stable/libinterp/corefcn/symrec.h:540
#2  octave::symbol_record::name[abi:cxx11]() const (this=0x55a9b4412e1f) at /home/jwe/src/octave-stable/libinterp/corefcn/symrec.h:576
#3  octave::workspace_model::update_table() () at /home/jwe/src/octave-stable/libgui/src/workspace-model.cc:291
#4  0x00007f8308215072 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x00007f8308b9f4a1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#6  0x00007f8308ba6ae0 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x00007f83081eb579 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x00007f83081ee56b in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007f830823dc03 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007f83020f4287 in g_main_context_dispatch () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#11 0x00007f83020f44c0 in ?? () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007f83020f454c in g_main_context_iteration () from /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007f830823d223 in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#14 0x00007f82f8127e51 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#15 0x00007f83081ea24b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007f83081f23c2 in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007f830bbd25e4 in octave::gui_application::execute() () at /home/jwe/src/octave-stable/libgui/src/octave-gui.cc:202
#18 0x000055a9b3254389 in main () at /home/jwe/src/octave-stable/src/main-gui.cc:104
#19 0x00007f83093bab17 in __libc_start_main (main=0x55a9b3254210 <main>, argc=9, argv=0x7fffef509988, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffef509978) at ../csu/libc-start.c:310
#20 0x000055a9b325464a in _start () at /home/jwe/src/octave-stable/src/main-gui.cc:105


So, it looks like a threading problem with accessing the symbol table when the GUI tries to update the data displayed in the workspace widget.

John W. Eaton <jwe>
Group administrator
Thu 13 Sep 2018 02:01:42 PM UTC, comment #2: 

I'm attaching the Currentcy2.txt data file, extracted from the file http://roland65.free.fr/benchmarks/benchmarks-0.2.tar.gz

John W. Eaton <jwe>
Group administrator
Thu 13 Sep 2018 01:48:50 PM UTC, comment #1: 

Hi,

You did not include "Currency2.txt" so I am unable to run the script.

Pantxo Diribarne <pantxo>
Group Member
Thu 13 Sep 2018 01:10:59 PM UTC, original submission:  

I have the following weird problem

When I run the file I have added below (ncrunch.m) the gui version octave crashes under Windows 10. The gui version I build under Linux Mint Mate Tara also crashes. The CLI versions do not crash.

When I stop the code after every test the code crashes when I stop (add a return) after the FFT test. But the code also crashes when I comment out the FFT section.

I am at a loss here. I do remember something from the olden (windows 95) days though in code I was working with. If fortran code contains output (warning, error, etc) statements to stdout or null this can crash gui's but not CLI applications. At this moment I am too inexperienced with the octave code and build environment to hunt for something like that. The strange thing is that it happens both under Linux and Windows.

The other possibility is a hardware error. I have only one system here. Can someone please try this on another computer?

P.S.

The ncrunch.m file is a slightly modified version I took from http://roland65.free.fr/benchmarks/. The original shows the same problem. Under Matlab, there is no crash.

Olaf Bousche <olaf789>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #45001:  Currency2.txt added by jwe (679KiB - text/plain)
file #44999:  ncrunch.m added by olaf789 (4KiB - text/x-objcsrc)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by olaf789 (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-09-19 mtmiller Carbon-CopyRemoved 80942 -
    2018-09-17 mtmiller StatusConfirmed Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #54431
    2018-09-13 jwe Attached File- Added Currency2.txt, #45001
    2018-09-13 jwe StatusNone Confirmed
    2018-09-13 olaf789 Attached File- Added ncrunch.m, #44999

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code