Re: SEGV in Garbage collection during build

[Alan Minga]

Stefan Monnier wrote:
> Please take this to gnu.emacs.bug rather than gnu.emacs.help.
> You'll hopefully get more info over there.

Hopefully I've moved the reply to g.e.b

> > CC-513 cc: WARNING File = frame.c, Line = 2118
> >   A value of type "unsigned char *" cannot be assigned to an entity of type
> >           "char *".
>
>
> >                       color_name = XSTRING (value)->data;
>
>
> > But I don't believe these are significant.
>
>
> I don't know about the "indicated argument is incompatible with the
> corresponding formal parameter", but the char-vs-unsigned-char should be
> harmless (tho pesky abnd surprisingly difficult to fix).
>
>
> > The problem occurs in the build when Emacs tries to load lisp.  This problem
> > is reproducable by running
>
>
> > ./temacs -batch
>
>
> > There is a failure in mark_object after it is recutsivly called about for
> > the 31,000th time.  It makes stack tracing a bit difficult.
>
>
> How far through the dump process is it when it crashes?
> Is that the first garbage collection?

It is the first garbage collection.  It doesn't seen to be confined to a 
particular part of lisp either.

> > So any suggestions for getting to the bottom of this SEGV?
>
>
> I suggest you take a look at the files in emacs/src/m/* and emacs/src/s/*.
> If you can find there a machine or OS that you expect to be somewhat similar
> to the X1, it might contain useful hints.  See also emacs/etc/PROBLEMS.
>
> Also, could it be that the SEGV is just a stack overflow (i.e. the stack
> limit is too low)?  Seems unlikely on a Cray, tho :-)

We can adjust the stack size at run time on the X1 and that seems to 
make no difference in the point of failure.  Is the Lisp array 
terminated in any peculular way so that it's not picking up the end of 
the array.

> Your binary dos not seem to contain debugging info (at least your backtrae
> shows no info about arguments, which is a pretty good sign that the debug
> info is missing), so you should rebuild with debug info.

It may be an old backtrace from a stripped executable.  I'll rebuild and 
try again.

Alan.