Re: allocate_string_data memory corruption

[Chong Yidong]

Stefan Monnier <address@hidden> writes:

> Most likely the thing that's happening is that check_sblock takes a "long"
> time during which there's a higher probability for a signal to arrive and
> the bug itself is that one of the signal handlers does some string
> allocation (or some other manipulation of those data structures).
>
> I'd try something like
>
>     eassert (!in_allocate_string_data);
>     in_allocate_string_data = 1;
>     ...
>     check_sblock();
>     ...
>     in_allocate_string_data = 0;

OK, I'll follow this up.

> BTW, it's possible that -DSYNC_INPUT fixes the bug.

Curiously, if you turn on the GC debugging checks at the top of
lisp.h, compiling with -DSYNC_INPUT fails:

./temacs --batch --load loadup bootstrap
*** glibc detected *** double free or corruption (out): 0x0839a500 ***
make[2]: *** [bootstrap-emacs] Aborted
make[2]: Leaving directory `/home/cyd/tmp/emacs/src'
make[1]: *** [bootstrap-build] Error 2
make[1]: Leaving directory `/home/cyd/tmp/emacs'
make: *** [bootstrap] Error 2

(gdb) r -batch
Starting program: /home/cyd/tmp/emacs/src/temacs -batch
*** glibc detected *** double free or corruption (out): 0x0839a520 ***

Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7bba9b1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7bbc2c9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7bee6ea in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
#4  0xb7bf4f54 in malloc_trim () from /lib/tls/i686/cmov/libc.so.6
#5  0xb7bf52ca in free () from /lib/tls/i686/cmov/libc.so.6
#6  0x0813df9e in init_buffer () at buffer.c:5174
#7  0x0811779e in main (argc=2, argv=0xbfc70214) at emacs.c:1526