[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: SEGV in Garbage collection during build

From: Alan Minga
Subject: Re: SEGV in Garbage collection during build
Date: Wed, 20 Oct 2004 13:59:39 -0500
User-agent: Mozilla Thunderbird 0.7.2 (Windows/20040707)

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]