Re: GC crashes

[Richard M. Stallman]

    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"

That is the first line of the function--before the initialization of
`data'.  So it is not an anomaly that it contains garbage.

The real question is, why did the SIGBUS happen there?

That calls for looking at the code at the assembler level.
Which instruction got the signal, and what data was it looking at?

    The values display=0x8, window=16843009 seen in the backtrace probably
    mean those haven't been initialized yet.

I would expect the backtrace to show the args from the argument slots,
as opposed to the variable values.  The args are set up in the stack
by the caller, before the called function is entered.  So this
is rather strange.

Examining at the assembler level ought to reveal what
is happening.

One possibility is stack overflow.  That often manifests as a SIGBUS
during entry to a function.  The backtrace shows there is no infinite
recursion, but perhaps alloca calls ate up lots of stack space.

To see if this has occurred, you look at the value of $sp.