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

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

[Octave-bug-tracker] [bug #52146] CTRL+C and cursor up results in segfau


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #52146] CTRL+C and cursor up results in segfault
Date: Sat, 30 Sep 2017 16:15:55 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

Follow-up Comment #3, bug #52146 (project octave):

I've put some fprintf()'s near all the add_history() and remove_history()
functions.  I don't see any of those function calls associated with cntrl-C. 
Given that using_history() is called at startup, I don't see what other
influence on readline Octave would have.

I don't think that BLAS/OpenBLAS influences this, given no functions from that
library are run in this example.  The fail example in
https://savannah.gnu.org/bugs/?47400 runs some code that uses the BLAS library
prior to the cntrl-C problem.

Point taken though about the multi-thread environment.  I'm thinking of ways
that might manifest.  There is now an Octave signal handler intermediate,
which if I understand correctly catches the signal, does some GUI related
stuff (if such a function is defined), then rethrows the signal, which
presumably gets passed on to library readline.  Perhaps something has been
overlooked in the proper way of rethrowing a signal.

Another thought is that although there is no mandatory initialization for
libreadline, there is an initialization routine:

https://tiswww.case.edu/php/chet/readline/readline.html#SEC39


Function: int rl_initialize (void)
    Initialize or re-initialize Readline's internal state. It's not strictly
necessary to call this; readline() calls it before reading any input. 


That's interesting in the sense that typing up-arrow is not "reading any
input".  Is readline library internally calling rl_initialize() in such a
scenario?

Ah, but the crash is not consistent, but intermittent.  That's typical of
multi-threaded race conditions.  Is there some conceivable way in which
rl_initialization() is run in the GUI thread (where the program launch and
library install occurred), while the up-arrow action is run in the worker
thread (where Octave core was moved to and is using readline)?  If so, that
could be a race between rl_initialization() completing and up-arrow accessing
the history list (which is bogus because without the .octave_hist nothing is
put into the history list).

I wonder if we were to force rl_initialization() at the start of the program
(I don't currently see it happening at startup) that could solve the problem. 
Could you try the attached patch?  If it fixes the issue, we could have JWE
find a better location for the rl_initialize() call.

(file #42021)
    _______________________________________________________

Additional Item Attachment:

File name: octave-readline_initializeation-djs2017sep30.patch Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52146>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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