homepage

Hi all,
In working on the LLVM/LLDB project, I've been hitting a bug in the
embedded interpreter that causes a NULL dereference in the Python
readline module. There is a call to the history_get() function with an
assumption that it returns a non-NULL value. This is not guaranteed to
be true of the history_get function, and causes the readline module to
crash when it hits this condition.
I'm attaching a patch to the Python 2.7.6 source code that addresses
this issue. It adds an explicit NULL test of the history_get() return
value before accessing it.
This issue was discovered in top of tree LLDB (LLVM.org debugger project). See here for details:
http://llvm.org/bugs/show_bug.cgi?id=18841 

Cleaned up the proposed patch a bit. Moves HIST_ENTRY* into a tighter block and removes the second call to history_get() since the value is already stashed in the NULL-checked local.

Can we please get a review on this?

Why does _py_get_history_length return a positive value if there's no line available?

I think an answer to Benjamin’s question is necessary to move this forward. The code already checks the index before calling history_get(). How do you manage to get null pointers returned for every history item?
In the LLVM bug thread, I noticed "libedit" a.k.a. Editline mentioned a few times. Are you sure Python is using Gnu Readline, or is it somehow hooking into Editline? Python only really supports Editline on Apple, not Linux (see Issue 13501 for expanding that support).

Closing in favour of Issue 13501, since the report was apparently about using a non-Apple Editline rather than Gnu Readline. However see also Issue 29854, where the same symptom is seen with Gnu Readline, and it will probably get the same fix.