Re: GC crashes

[David Kastrup]

Chong Yidong <address@hidden> writes:

> The latest bt sent by F.D.F., on closer look, is just plain bizarre:
>
>   #0  initialize_cut_buffers (display=0x8, window=16843009) at xselect.c:2316
>       data = (unsigned char *) 0x820c124 "\213\367\017\b\001"
>
>   #1  0x080ff866 in Fx_rotate_cut_buffers_internal (n=8) at xselect.c:2470
>       window = 73
>       props = {0, 0, 0, 0, 136364324, 138120105, 3220375768, 135779857}
>       display = (Display *) 0x8748060
>       sf = (struct frame *) 0x856d418
>   
> The relevant line of code in Fx_rotate_cut_buffers_internal is
>
>   initialize_cut_buffers (display, window);
>
> and the code in initialize_cut_buffers is
>
>   static void
>   initialize_cut_buffers (display, window)
>        Display *display;
>        Window window;
>   {
>     unsigned char *data = (unsigned char *) "";
>
> The values display=0x8, window=16843009 seen in the backtrace probably
> mean those haven't been initialized yet.  In any case, there's no
> reason for "" to map to 0x820c124 "\213\367\017\b\001".
>
> I don't see any reason for the above code to fail unless it's a
> compiler or OS bug.  Ideas welcome.

from etc/DEBUG:

    ** When you are trying to analyze failed assertions, it will be
    essential to compile Emacs either completely without optimizations or
    at least (when using GCC) with the -fno-crossjumping option.  Failure
    to do so may make the compiler recycle the same abort call for all
    assertions in a given function, rendering the stack backtrace useless
    for identifying the specific failed assertion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum