SEGV in Garbage collection during build

SEGV in Garbage collection during build

[Alan Minga]

All,

I am porting emacs 21.3 to a cray X1 system and I'm having some 
difficulties in building the code.

The build proceeds OK with only a few warning messages about type

such as

CC-180 cc: WARNING File = frame.c, Line = 1875
   The indicated argument is incompatible with the corresponding formal 
parameter.

                             STRING_BYTES (XSTRING (f->name))))
                             ^

And

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.

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.

Attempst to print the Lisp variables result in the following error.  I'm 
not sure if that's due to an additional bug in print or if that's just 
because the stack is so corrupted.

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;

So any suggestions for getting to the bottom of this SEGV?


------------
Alan Minga, Ph.D.
Sr. Presales Analyst
Cray Inc.

Breakpoint 1 at 0x1123364: file /ptmp/aminga/emacs-21.3/src/emacs.c, 
line 387.
#0  0x12635ac in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4366
#1  0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#2  0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#3  0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#4  0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#5  0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#6  0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#7  0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#8  0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#9  0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#10 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#11 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#12 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#13 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#14 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#15 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#16 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#17 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#18 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#19 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#20 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
#21 0x1263e28 in mark_object () at /ptmp/aminga/emacs-21.3/src/alloc.c:4628
...
#31747 0x1263e28 in mark_object () at 
/ptmp/aminga/emacs-21.3/src/alloc.c:4628
#31748 0x1263e28 in mark_object () at 
/ptmp/aminga/emacs-21.3/src/alloc.c:4628
#31749 0x1264d98 in mark_object () at 
/ptmp/aminga/emacs-21.3/src/alloc.c:4616
#31750 0x1261430 in Fgarbage_collect () at 
/ptmp/aminga/emacs-21.3/src/alloc.c:4097
#31751 0x12bdb58 in Feval () at /ptmp/aminga/emacs-21.3/src/eval.c:1912
#31752 0x131a9cc in readevalloop () at 
/ptmp/aminga/emacs-21.3/src/lread.c:1259
#31753 0x1317568 in Fload () at /ptmp/aminga/emacs-21.3/src/lread.c:832
#31754 0x12be32c in Feval () at /ptmp/aminga/emacs-21.3/src/eval.c:2027
#31755 0x131a9cc in readevalloop () at 
/ptmp/aminga/emacs-21.3/src/lread.c:1259
#31756 0x1317568 in Fload () at /ptmp/aminga/emacs-21.3/src/lread.c:832
#31757 0x12be32c in Feval () at /ptmp/aminga/emacs-21.3/src/eval.c:2027
#31758 0x1130214 in top_level_2 () at 
/ptmp/aminga/emacs-21.3/src/keyboard.c:1254
#31759 0x12b8e4c in internal_condition_case () at 
/ptmp/aminga/emacs-21.3/src/eval.c:1267
#31760 0x1130404 in top_level_1 () at 
/ptmp/aminga/emacs-21.3/src/keyboard.c:1262
#31761 0x12b7834 in internal_catch () at 
/ptmp/aminga/emacs-21.3/src/eval.c:1030
#31762 0x112fe3c in command_loop () at 
/ptmp/aminga/emacs-21.3/src/keyboard.c:1228
#31763 0x112e57c in recursive_edit_1 () at 
/ptmp/aminga/emacs-21.3/src/keyboard.c:950
#31764 0x112ec28 in Frecursive_edit () at 
/ptmp/aminga/emacs-21.3/src/keyboard.c:1006
#31765 0x1129a2c in main () at /ptmp/aminga/emacs-21.3/src/emacs.c:1535
~

Re: SEGV in Garbage collection during build

[Stefan Monnier]

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

> 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?

> 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 :-)

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.


        Stefan

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.