Re: allocate_string_data memory corruption

[Stefan Monnier <monnier@iro.umontreal.ca>]

>     Maybe eassert(!handling_signal) should be added to allocate_string
>     (and maybe it will catch the current bug).

> It seems worth a try.

There's actually one candidate:

#1  0x081dd84a in die (msg=0x8319288 "assertion failed: !handling_signal", 
    file=0x8318980 "alloc.c", line=2744) at alloc.c:6210
#2  0x081e0f25 in Fcons (car=141994859, cdr=140190650) at alloc.c:2744
#3  0x08130686 in x_catch_errors (dpy=0x8808db8) at xterm.c:7462
#4  0x0813bb08 in x_real_positions (f=0x88c2518, xptr=0x47, yptr=0x47)
    at xfns.c:580
#5  0x08133d09 in handle_one_xevent (dpyinfo=0x8814cf0, eventp=0xbfffdbfc, 
    finish=0xbfffdc88, hold_quit=0xbfffecbc) at xterm.c:5871
#6  0x081376bb in XTread_socket (sd=0, expected=1, hold_quit=0xbfffecbc)
    at xterm.c:6981
#7  0x08174b69 in read_avail_input (expected=1) at keyboard.c:6703
#8  0x08174d2a in handle_async_input () at keyboard.c:6855

if you look at x_catch_errors, you'll see that it allocates one lisp_cons cell,
one lisp_string and one lisp_misc.  Whether it's the cause of the bugs we
see, I don't know, but since it's run from the signal handler, it can be
executed at potentially any time.


        Stefan