[Bug-readline] Malloc from signal handler in readline

[Brian Bloniarz]

Hi, I think I've stumbled on a bug involving memory allocation from signal 
context
in readline 6.2. In GDB, I see this traceback:

#8  __lll_lock_wait_private () at 
../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:91
#9  0x00007f2289120cb1 in _L_lock_10627 () at malloc.c:5209
#10 0x00007f228911ea37 in __GI___libc_malloc (bytes=139786308626208) at 
malloc.c:2921
#11 0x00007f22861c9619 in xmalloc () from /lib/x86_64-linux-gnu/libreadline.so.6
#12 0x00007f22861cd612 in sh_set_lines_and_columns () from 
/lib/x86_64-linux-gnu/libreadline.so.6
#13 0x00007f22861c5b5d in _rl_get_screen_size () from 
/lib/x86_64-linux-gnu/libreadline.so.6
#14 0x00007f22861c5d6f in rl_resize_terminal () from 
/lib/x86_64-linux-gnu/libreadline.so.6
#15 0x00007f22861c23c2 in ?? () from /lib/x86_64-linux-gnu/libreadline.so.6
#16 <signal handler called>

The rl_resize_terminal() call happens because of a SIGWINCH signal (see 
rl_sigwinch_handler).

I saw there was some discussion involving fixing signal-handler-safety bugs
(http://lists.gnu.org/archive/html/bug-readline/2011-06/msg00003.html),
but I didn't see this particular case being discussed. It's causing deadlocks 
for me, within
ipython. It looks like ipython uses readline and ncurses both, and it looks 
like both have
the same bug. I'm running readline 6.2-8 from Ubuntu 12.04. I don't have any 
reliable way to
reproduce the issue but I've seen it several times.

Please let me know if I can help at all diagnosing or fixing this.

Thanks & kind regards,
Brian Bloniarz