From: Alan Minga <aminga@cray.com>
Subject: Re: SEGV in Garbage collection during build
Date: Wed, 20 Oct 2004 13:59:39 -0500 [thread overview]
Message-ID: <4176B59B.70901@cray.com> (raw)
In-Reply-To: <jwvis95ecdt.fsf-monnier+gnu.emacs.help@gnu.org>
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.
parent reply other threads:[~2004-10-20 18:59 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <jwvis95ecdt.fsf-monnier+gnu.emacs.help@gnu.org>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4176B59B.70901@cray.com \
--to=aminga@cray.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).