Apparent malloc from signal handler

[Brian Bloniarz]

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

#1  0x00007f2289120cb1 in _L_lock_10627 () at malloc.c:5209
#2  0x00007f228911ea37 in __GI___libc_malloc (bytes=139786308626208) at 
malloc.c:2921
#3  0x00007f2287b180cb in _nc_set_buffer () from 
/lib/x86_64-linux-gnu/libtinfo.so.5
#4  0x00007f2287b16e6d in reset_prog_mode () from 
/lib/x86_64-linux-gnu/libtinfo.so.5
#5  0x00007f2287d4b1d5 in doupdate () from 
/lib/x86_64-linux-gnu/libncursesw.so.5
#6  0x00007f2287d41ee5 in ?? () from /lib/x86_64-linux-gnu/libncursesw.so.5
#7  <signal handler called>

I think the callchain that's involved is:
SIGTSTP->tstp()->doupdate()->reset_prog_mode()->NC_BUFFERED()->_nc_set_buffer()->typeMalloc()

More details: I'm running ncurses version 5.9-4 from Ubuntu 12.04. The symptom 
is a
deadlock in ipython -- it looks like ipython uses readline and ncurses, and I 
think both
are incorrectly doing memory allocation from signal context. 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