Mac OSX running Carbon crash with today's CVS

Mac OSX running Carbon crash with today's CVS

[Gabriel Foster]

Greetings,

	I'm gettting a random but fairly consistent crash on Mac OSX, built 
from today's CVS.  I'm using the Carbon UI.  Any ideas on a fix would 
be appreciated.  Here is the stack trace:

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x000c48b4 in Fgarbage_collect () at alloc.c:4304
4304          XUNMARK (tail->var[i]);
(gdb) where
#0  0x000c48b4 in Fgarbage_collect () at alloc.c:4304
#1  0x00076540 in read_char (commandflag=1, nmaps=2, maps=0xbfffebd0, 
prev_event=275715796, used_mouse_menu=0xbfffecd4) at keyboard.c:2712
#2  0x0007e45c in read_key_sequence (keybuf=0xbfffeda0, 
bufsize=2373924, prompt=275715796, dont_downcase_last=2384204, 
can_return_switch_frame=1, fix_current_buffer=2371724) at 
keyboard.c:8583
#3  0x00073d5c in command_loop_1 () at keyboard.c:1502
#4  0x000d9cd4 in internal_condition_case (bfun=0x73918 
<command_loop_1>, handlers=275762388, hfun=0x732c8 <cmd_error>) at 
eval.c:1333
#5  0x000736f8 in command_loop_2 () at keyboard.c:1290
#6  0x000d9744 in internal_catch (tag=6348816, func=0x736b8 
<command_loop_2>, arg=275715796) at eval.c:1094
#7  0x00073650 in command_loop () at keyboard.c:1269
#8  0x00073064 in recursive_edit_1 () at keyboard.c:985
#9  0x000731ec in Frecursive_edit () at keyboard.c:1041
#10 0x00071cc0 in main (argc=0, argv=0xbffffa44) at emacs.c:1659
#11 0x00003ae8 in _start (argc=50, argv=0x0, envp=0x2405b4) at 
/SourceCache/Csu/Csu-45/crt.c:267
#12 0x00003968 in start ()
(gdb) list
4299
4300    #if (GC_MARK_STACK == GC_USE_GCPROS_AS_BEFORE \
4301         || GC_MARK_STACK == GC_USE_GCPROS_CHECK_ZOMBIES)
4302      for (tail = gcprolist; tail; tail = tail->next)
4303        for (i = 0; i < tail->nvars; i++)
4304          XUNMARK (tail->var[i]);
4305    #endif
4306
4307      unmark_byte_stack ();
4308      for (backlist = backtrace_list; backlist; backlist = 
backlist->next)
(gdb) print tail
$1 = (struct gcpro *) 0xbfffde90
(gdb) print tail->nvars
$2 = 1168308
(gdb) print i
$3 = 7289
(gdb)

Mac OS 10.2.5

emacs --version
GNU Emacs 21.3.50.2
Copyright (C) 2002 Free Software Foundation, Inc.

Re: Mac OSX running Carbon crash with today's CVS

[Eli Zaretskii]

> Date: Mon, 21 Apr 2003 15:21:40 -0700
> From: Gabriel Foster <gabriel@apple.com>
> 
> 	I'm gettting a random but fairly consistent crash on Mac OSX, built 
> from today's CVS.

Are all of them in the same place in the code, i.e. during garbage
collection?

> (gdb) list
> 4299
> 4300    #if (GC_MARK_STACK == GC_USE_GCPROS_AS_BEFORE \
> 4301         || GC_MARK_STACK == GC_USE_GCPROS_CHECK_ZOMBIES)
> 4302      for (tail = gcprolist; tail; tail = tail->next)
> 4303        for (i = 0; i < tail->nvars; i++)
> 4304          XUNMARK (tail->var[i]);
> 4305    #endif
> 4306
> 4307      unmark_byte_stack ();
> 4308      for (backlist = backtrace_list; backlist; backlist = 
> backlist->next)
> (gdb) print tail
> $1 = (struct gcpro *) 0xbfffde90
> (gdb) print tail->nvars
> $2 = 1168308
> (gdb) print i
> $3 = 7289
> (gdb)

How about

  (gdb) print tail->var[i]

Also, please try to describe what are you doing in Emacs when these
crashes happen.

Thanks.

Re: Mac OSX running Carbon crash with today's CVS

[Gabriel Foster]

On Tuesday, April 22, 2003, at 01:05 AM, Eli Zaretskii wrote:

>> Date: Mon, 21 Apr 2003 15:21:40 -0700
>> From: Gabriel Foster <gabriel@apple.com>
>>
>> 	I'm gettting a random but fairly consistent crash on Mac OSX, built
>> from today's CVS.
>
> Are all of them in the same place in the code, i.e. during garbage
> collection?
>
>> (gdb) list
>> 4299
>> 4300    #if (GC_MARK_STACK == GC_USE_GCPROS_AS_BEFORE \
>> 4301         || GC_MARK_STACK == GC_USE_GCPROS_CHECK_ZOMBIES)
>> 4302      for (tail = gcprolist; tail; tail = tail->next)
>> 4303        for (i = 0; i < tail->nvars; i++)
>> 4304          XUNMARK (tail->var[i]);
>> 4305    #endif
>> 4306
>> 4307      unmark_byte_stack ();
>> 4308      for (backlist = backtrace_list; backlist; backlist =
>> backlist->next)
>> (gdb) print tail
>> $1 = (struct gcpro *) 0xbfffde90
>> (gdb) print tail->nvars
>> $2 = 1168308
>> (gdb) print i
>> $3 = 7289
>> (gdb)
>
> How about
>
>   (gdb) print tail->var[i]
>
> Also, please try to describe what are you doing in Emacs when these
> crashes happen.
>

In the most recent case, I had just hit the enter key.

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x000c4630 in Fgarbage_collect () at alloc.c:4197
4197          if (!XMARKBIT (tail->var[i]))
(gdb) print i
$1 = 0
(gdb) print tail
$2 = (struct gcpro *) 0xbfffde20
(gdb) print *tail->var[i]
Cannot access memory at address 0x1
(gdb) print tail->var[i]
Cannot access memory at address 0x1
(gdb) print tail->var
$3 = (volatile int *) 0x1
(gdb) where
#0  0x000c4630 in Fgarbage_collect () at alloc.c:4197
#1  0x0010c60c in Fbyte_code (bytestr=275966772, vector=130, 
maxdepth=-1073757728) at bytecode.c:744
#2  0x000dca34 in funcall_lambda (fun=1108651152, nargs=3, 
arg_vector=0xbfffc404) at eval.c:2910
#3  0x000dc4f8 in Ffuncall (nargs=1381796708, args=0xbfffc400) at 
eval.c:2780
#4  0x0010c558 in Fbyte_code (bytestr=274992596, vector=3, 
maxdepth=-1073757184) at bytecode.c:709
#5  0x000dca34 in funcall_lambda (fun=1108648928, nargs=3, 
arg_vector=0xbfffc624) at eval.c:2910
#6  0x000dc4f8 in Ffuncall (nargs=1381796708, args=0xbfffc620) at 
eval.c:2780
#7  0x0010c558 in Fbyte_code (bytestr=274992596, vector=3, 
maxdepth=-1073756640) at bytecode.c:709
#8  0x000dca34 in funcall_lambda (fun=1080299968, nargs=2, 
arg_vector=0xbfffc978) at eval.c:2910
#9  0x000dc4f8 in Ffuncall (nargs=1381796708, args=0xbfffc974) at 
eval.c:2780
#10 0x000dbac8 in run_hook_with_args (nargs=3, args=0xbfffc974, 
cond=to_completion) at eval.c:2393
#11 0x000dc3a8 in Ffuncall (nargs=1381796708, args=0xbfffc970) at 
eval.c:2726
#12 0x0010c558 in Fbyte_code (bytestr=276103540, vector=3, 
maxdepth=-1073755792) at bytecode.c:709
#13 0x000dca34 in funcall_lambda (fun=1101781200, nargs=2, 
arg_vector=0xbfffcb94) at eval.c:2910
#14 0x000dc4f8 in Ffuncall (nargs=1381796708, args=0xbfffcb90) at 
eval.c:2780
#15 0x0010c558 in Fbyte_code (bytestr=303377588, vector=2, 
maxdepth=-1073755248) at bytecode.c:709
#16 0x000dca34 in funcall_lambda (fun=1101780992, nargs=1, 
arg_vector=0xbfffd2a4) at eval.c:2910
#17 0x000dc4f8 in Ffuncall (nargs=1381796708, args=0xbfffd2a0) at 
eval.c:2780
#18 0x000d9fb4 in internal_condition_case_2 (bfun=0xdc0d8 <Ffuncall>, 
nargs=2, args=0xbfffd2a0, handlers=275715844, hfun=0x16bf8 
<safe_eval_handler>) at eval.c:1418
#19 0x00016de4 in safe_call (nargs=2, args=0xbfffd2a0) at xdisp.c:1789
#20 0x00016e34 in safe_call1 (fn=1381796708, arg=275715796) at 
xdisp.c:1809
#21 0x000184f8 in handle_fontified_prop (it=0x525c8b64) at xdisp.c:2711
#22 0x00017f24 in handle_stop (it=0xbfffd560) at xdisp.c:2472
#23 0x0001c4ec in next_element_from_buffer (it=0x157608) at xdisp.c:5274
#24 0x0001b82c in get_next_display_element (it=0xbfffd560) at 
xdisp.c:4626
#25 0x0002cd50 in display_line (it=0xbfffd560) at xdisp.c:14242
#26 0x000291e4 in try_window (window=1381796708, pos={charpos = 2710, 
bytepos = 2710}) at xdisp.c:11981
#27 0x00028408 in redisplay_window (window=1101750720, 
just_this_one_p=1) at xdisp.c:11639
#28 0x000253cc in redisplay_window_1 (window=1381796708) at 
xdisp.c:10409
#29 0x000d9e40 in internal_condition_case_1 (bfun=0x25390 
<redisplay_window_1>, arg=1101750720, handlers=1349614436, hfun=0x25300 
<redisplay_window_error>) at eval.c:1374
#30 0x00024a14 in redisplay_internal (preserve_echo_area=1381796708) at 
xdisp.c:10035
#31 0x00075f00 in read_char (commandflag=1, nmaps=2, maps=0xbfffebd0, 
prev_event=275715796, used_mouse_menu=0xbfffecd4) at keyboard.c:2473
#32 0x0007e45c in read_key_sequence (keybuf=0xbfffeda0, 
bufsize=2373924, prompt=275715796, dont_downcase_last=2384204, 
can_return_switch_frame=1, fix_current_buffer=2371724) at 
keyboard.c:8583
#33 0x00073d5c in command_loop_1 () at keyboard.c:1502
#34 0x000d9cd4 in internal_condition_case (bfun=0x73918 
<command_loop_1>, handlers=275762388, hfun=0x732c8 <cmd_error>) at 
eval.c:1333
#35 0x000736f8 in command_loop_2 () at keyboard.c:1290
#36 0x000d9744 in internal_catch (tag=1381796708, func=0x736b8 
<command_loop_2>, arg=275715796) at eval.c:1094
#37 0x00073650 in command_loop () at keyboard.c:1269
#38 0x00073064 in recursive_edit_1 () at keyboard.c:985
#39 0x000731ec in Frecursive_edit () at keyboard.c:1041
#40 0x00071cc0 in main (argc=0, argv=0xbffffa44) at emacs.c:1659
#41 0x00003ae8 in _start (argc=50, argv=0x0, envp=0x2405b4) at 
/SourceCache/Csu/Csu-45/crt.c:267
#42 0x00003968 in start ()



> Thanks.

Re: Mac OSX running Carbon crash with today's CVS

[Eli Zaretskii]

> Date: Tue, 22 Apr 2003 07:39:25 -0700
> From: Gabriel Foster <gabriel@apple.com>
> 
> In the most recent case, I had just hit the enter key.

Can you cause the same crash if you type "M-x garbage-collect RET"
right after starting Emacs?

> (gdb) print tail
> $2 = (struct gcpro *) 0xbfffde20
> (gdb) print *tail->var[i]
> Cannot access memory at address 0x1
> (gdb) print tail->var[i]
> Cannot access memory at address 0x1
> (gdb) print tail->var
> $3 = (volatile int *) 0x1

This is the problem, then: either tail->var or tail->nvars is garbled
(I'm guessing it's the latter).

Does anyone have a clue why this could happen on a Mac?

If no one comes up with a better idea, one way of attacking this bug
would be to put a hardware-assisted watchpoint on the nvars member,
like this:

   (gdb) watch ((struct gcpro *)0xbfffde20)->nvars

and when the watchpoint fires, look for the code that puts the
preposterously large value into nvars.  (If nvars changes its value
to something reasonable, like zero or 1, just type "cont" to let the
program resume its run.)

Before you do the above, it is highly recommended to find a simple
procedure that would predictably cause such a crash, and with the
same value of `tail', the GCPRO structure that is garbled.  Then use
that address instead of 0xbfffde20 above.

(I'm assuming that GDB on Mac OSX supports hardware-assisted
watchpoints, btw.)

Re: Mac OSX running Carbon crash with today's CVS

[Andrew Choi]

Eli Zaretskii <eliz@elta.co.il> writes:

> > Date: Tue, 22 Apr 2003 07:39:25 -0700
> > From: Gabriel Foster <gabriel@apple.com>
> > 
> > In the most recent case, I had just hit the enter key.

It may help to know what you were doing /before/ you hit the enter key.

> Can you cause the same crash if you type "M-x garbage-collect RET"
> right after starting Emacs?
> 
> > (gdb) print tail
> > $2 = (struct gcpro *) 0xbfffde20
> > (gdb) print *tail->var[i]
> > Cannot access memory at address 0x1
> > (gdb) print tail->var[i]
> > Cannot access memory at address 0x1
> > (gdb) print tail->var
> > $3 = (volatile int *) 0x1
> 
> This is the problem, then: either tail->var or tail->nvars is garbled
> (I'm guessing it's the latter).
> 
> Does anyone have a clue why this could happen on a Mac?  [...]

No, except that I've been running the CVS version on April 21 for two
days now without any problems.  I also haven't got any crashes from
previous versions.