New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ipython history causes segfault on embedded powerpc #8087
Comments
|
I noticed this does not occur when no start of a string is entered, only when entering the start of a search string. |
|
The up/down arrow keys for history search are handled by readline - I suspect IPython's settings are revealing a bug in there. You can override IPython's defaults for readline by setting other actions for those keys in |
|
Dear Thomas, On 19-03-15 17:54, Thomas Kluyver wrote:
I have set InteractiveShell.readline_parse_and_bind=[] and the problem Best regards, Tjeerd Atomic, Molecular and Laser Physics Group Lab: tel: ++31 20 5987535 LaserLab, Vrije Universiteit |
|
The readline guidelines for bug reporting are here: http://cnswww.cns.cwru.edu/php/chet/readline/rltop.html#Bugs The relevant option that we're setting for the up arrow is : If I'm correct that this is a readline bug, then it should be possible to trigger the same bug in bash or any other shell using readline by putting that line in your Thanks! |
I notice that ipython segfaults on the following conditions:
The following snapshots apply:
ipython
WARNING: IPython History requires SQLite, your history will not be saved
Python 2.7.9 (default, Mar 17 2015, 11:45:11)
It crashes in this case nothing with "rela" is found in the history:
In [17]: relapython[1380]: unhandled signal 11 at 00000000 nip b6b10940 lr b6b10934 code 30001
Segmentation fault
System is MPC8313E, powerpc
Buildroot, uclibc, linux 3.18, busybox shell
Since the history works when commands are present and there is a match found. Also on startup when pressing the "up" key ipython segfaults. It looks to me that somehow a pointer is not set up correctly when SQLite is not present (which on an embedded system can be the case due to space restrictions).
The problem for me is that I can not exclude yet that something in the cross compiler stuff might be the cause, although the rest of the system seems to be working fine and stable.
The text was updated successfully, but these errors were encountered: