Re: [Bug-readline] [readline patch, gdb-7.3?] Avoid free from a signal handler [Re: [PATCH] Make interrupting tab-completion safe.]

Chet Ramey
2011-06-29T13:54:33Z

On 6/26/11 6:21 PM, Jan Kratochvil wrote:
> GDB reproducer for the readline bug:
> ------------------------------------
>
> On Mon, 13 Jun 2011 19:44:57 +0200, Sterling Augustine wrote:
>> gdb itself isn't big enough to make it easy to reproduce (~24k
>> symbols).
>
> The goal is to do very many memory allocation functions in GDB, no matter
> which ones. I found for example libwebkitgtk.so.debug as good sample data,
> optionally added .gdb_index is OK for faster startup, it should contain C++
> functions for more memory operations (therefore GDB itself is not usable as
> the sample data). Used this GDB .exp file, reproducible in several seconds:
>
> set binfile "/home/jkratoch/t/rh575292-gdbindex.debug"
> gdb_exit
> gdb_start
> gdb_load ${binfile}
> while 1 {
> send_gdb "b \t\t"
> sleep 0.1
> send_gdb "\003"
> gdb_test "" "^b \\^CQuit" "Quit seen"
> }
>
> b ^CQuit
> (gdb) PASS: gdb.base/quit.exp: Quit seen
> b *** glibc detected *** /home/jkratoch/redhat/gdb-clean/gdb/testsuite/../../gdb/gdb: munmap_chunk(): invalid pointer: 0x0000000005b950b0 ***
>
> One can also add stub expensive mallinfo calls into GDB xmalloc/xfree/etc. for
> better reproducibility.
>
>
> The readline bug:
> -----------------
>
> readline now calls memory allocation/free functions from the readline signal
> handler. This is not permitted by POSIX and it does corrupt memory such as
> during SiGINT:
>
> #0 __lll_lock_wait_private () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:100
> #1 in _L_lock_10461 () from /lib64/libc.so.6
> #2 in __libc_malloc (bytes=139919578014176) at malloc.c:3657
> #3 in __libc_message (do_abort=2, fmt=0x7f41909aebe8 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:137
> #4 in malloc_printerr (action=3, str=0x7f41909aec18 "munmap_chunk(): invalid pointer", ptr=<optimized out>) at malloc.c:6283
> #5 in xfree (ptr=0x5b950b0) at utils.c:1303
> #6 in rl_free_undo_list () at undo.c:119
> #7 in rl_free_line_state () at signals.c:503
> #8 in _rl_handle_signal (sig=2) at signals.c:188
> #9 in rl_signal_handler (sig=2) at signals.c:149
> #10 <signal handler called>
> #11 _int_malloc (av=0x7f4190bea1e0, bytes=177) at malloc.c:4727
> #12 in __libc_malloc (bytes=177) at malloc.c:3660
> #13 in reallochook (ptr=<optimized out>, size=128, caller=0xd6f531) at mcheck.c:335
> #14 in d_growable_string_resize (dgs=0x7fff34b0d150, need=122) at ./cp-demangle.c:3247
> #15 in d_growable_string_init (dgs=0x7fff34b0d150, estimate=122) at ./cp-demangle.c:3226
> #16 in cplus_demangle_print (options=3, dc=0x4114fe8, estimate=122, palc=0x7fff34b0d198) at ./cp-demangle.c:3416
> #17 in cp_comp_to_string (result=0x4114fe8, estimated_len=122) at cp-name-parser.y:1965
> #18 in cp_canonicalize_string (string=0x93f4e20 "WebCore::FrameLoader::loadProvisionalItemFromCachedPage(void)") at cp-support.c:139
> [...]
>
> Unfortunately it leaks a bit now and also for example during SIGWINCH readline
> calls xmalloc which cannot be ignored/delayed so easily as xfree.
>
> Please postpone any memory management function only after the signal handler.

If you feel that you need to make this change for the current version of
gdb, go ahead. I will keep going in the direction readline-6.2 began:
using the RL_CHECK_SIGNALS macro to run signal handling code outside the
signal handler and minimizing the use of _rl_interrupt_immediately without
destroying performance.

The big problem is to allow operations that read through the file system
(like completion) to be interrupted without running unsafe functions from
a signal handler. Wrapping completion functions is the current remaining
use of _rl_interrupt_immediately. It does the user no good to keep
setting the "I got SIGINT" flag if he's trying to complete files on a dead
or otherwise unreachable file server.

Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU chet@case.edu http://cnswww.cns.cwru.edu/~chet/