bugGNU Octave - Bugs: bug #51886, Ctrl-C crash is back

 
 

bug #51886: Ctrl-C crash is back

Submitter:  Lars Kindermann <larskindermann>
Submitted:  Tue 29 Aug 2017 02:58:20 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 19 Apr 2018 07:56:18 PM UTC, comment #10: 

Tried multithreaded with OpenBlas libs and got no problem while holding down Ctrl-C for 5 minutes. Doing so did trigger the crash reliably on my system at the time I submitted this bug. So it works for me now.

Lars Kindermann <larskindermann>
Thu 19 Apr 2018 04:53:19 PM UTC, comment #9: 

Since signal handling was completely rewritten in January 2018, is this bug now resolved?

Mike Miller <mtmiller>
Group Member
Thu 31 Aug 2017 11:21:31 AM UTC, comment #8: 

An infinite loop of interrupt signals is definitely not done intentionally.

John W. Eaton <jwe>
Group administrator
Thu 31 Aug 2017 09:10:55 AM UTC, comment #7: 

Of course there is another obvious scenario:
Because SIGINT is re-sent to the gui itself this leads to an infinite loop. But why is SIGINT sent back to the gui when using the multithreaded libs?

Lars Kindermann <larskindermann>
Thu 31 Aug 2017 09:02:50 AM UTC, comment #6: 

Uninstalling OpenBLAS solved the problem indeed.

However, I checked the SIGINT handling again and found:

Without OpenBlas exactly two SIGINTs are sent to QTthred after Ctrl-C

With OpenBlas infinitely many are sent to QTthread and lt-octave-gui. That sounds pretty insane.

If the problem is due to Octave, I can imagine two scenarios:

The SIGINTs are sent in a loop or callback to the apropriate threads after a Ctrl-C is caught, but the code does not remember that it has been done already and continues to do forever. That might be easy to fix.

Or the many SIGINTS are by design because it is difficult to stop all the multipe threads. But even then it might be possible to limit the number and/or rate do avoid crashes.

Maybe this way the Ctrl-C problem with multithreaded BLAS / ATLAS libs can be solved. Sorry, I'm not very literate in C/C++ but if you point me to the relevant piece of code I can try to have a look.

Lars Kindermann <larskindermann>
Wed 30 Aug 2017 10:45:24 PM UTC, comment #5: 

I am able to reproduce a crash with Ctrl-C if I install OpenBLAS on my system.  If this is the problem you are seeing, then I think this is a duplicate of bug #47400.

If you are using OpenBLAS or ATLAS and they are set up to use multiple threads, can you try uninstalling these libraries and using the reference BLAS instead?  If that avoids the problem, then I think we can close this as a duplicate.

If you want to continue debugging, then another thing to try is to enable core files if the are not already enabled on your system ("ulimit -c unlimited" in bash) and then run Octave as usual, cause it to crash, then examine the core file with gdb.  You'll probably need to tell gdb to look at the octave-gui and the generated core file.  This might be easiest with an installed copy of Octave instead of trying to run things in the build directory.

John W. Eaton <jwe>
Group administrator
Tue 29 Aug 2017 09:57:09 PM UTC, comment #4: 

Playing with gdb revealed some strange behaviour, maybe you can make sense of it:

After attaching gdb to the gui process, setting
(gdb) handle SIGINT pass nostop
(gdb) finish
and pressing a few times enter until all threads are back to normal, the gui can be used again.

After pressing Ctrl-C once in the octave command window gdb shows that the threads lt-octave-gui and QThread receive SIGINTs repeatedly forever - until I enter some command in the gui,
e.g. a=1. Then the SIGINT storm stops until the next Ctrl-C.
No crash happens when gdb is attached this way.

Shouldn't send Ctrl-C not only a single SIGINT to each thread?
Maybe this continuous series of signals will eventually crash one of the threads if it cannot handle them in time.

This could explain the variyng and intermittend behaviour on different systems and why it is not happening under gdb: gdb catches SIGINT first before it sends it to the program with a slower pace... 


Lars Kindermann <larskindermann>
Tue 29 Aug 2017 06:25:34 PM UTC, comment #3: 

I also sometimes see this after pressing Ctrl+C in the GUI console. (self compiled hg id 58435a400d4e on Ubuntu 16.04).

I managed to take a SCREENSHOT while Octave was crashing, I'll attach in in case it helps.


Hartmut <hardy>
Tue 29 Aug 2017 05:54:42 PM UTC, comment #2: 

I see it in octave gui but not 100% reproducible.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Tue 29 Aug 2017 03:52:48 PM UTC, comment #1: 

I can't reproduce on my Debian system.

The approach I would use is to attach to the octave-gui process with gdb, then tell gdb to pass SIGINT to the octave process:


(gdb) handle SIGINT pass


Then let the octave process continue and type Ctrl-C at the prompt.  Not sure whether this will work, but it's worth a try to find out where it is crashing.

John W. Eaton <jwe>
Group administrator
Tue 29 Aug 2017 02:58:20 PM UTC, original submission:  

Current dev again crashes on a single Ctrl-C, 100% reproducible, right after startup. (Ubuntu 16.04)

Any idea how to capture the error messages within the command window before it disappears?

Lars Kindermann <larskindermann>

 

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

Attach Files:
   
   
Comment:
   

Attached Files

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by hardy (Updated the item)
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by larskindermann (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 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-04-19 mtmiller StatusWorks For Me Fixed
        Open/ClosedOpen Closed
    2018-04-19 mtmiller StatusNone Works For Me
    2017-08-29 hardy Attached File- Added Screenshot_after_CTRL+C.png, #41693

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code