More info on sporadic OS/X crash

More info on sporadic OS/X crash

[John Wiegley]

I've been running Emacs built with -g, waiting for the frequent OS/X
Carbon crash to appear.  Now I have much more info, though I still
don't know what it means:

The crash occurs here:

  0x9158ccd0 <SetupOffscreenGDevice+208>: lwz     r4,0(r4)

because $r4 is -1.  This value comes from:

  0x9158ccc4 <SetupOffscreenGDevice+196>: lwz     r4,24(r3)

because r3 points to a structure (at 0xbfffd314; argument?),
containing a pointer at byte offset 24 that points to the value -1.
Here is the structure:

  0xbfffd314:  0xba1bb000  0xffff8940  0xffea0000  0x020d0245
  0xbfffd324:  0x00040010  0x20030890 *0x007e63a4* 0xffea0000
  0xbfffd334:  0x00000020  0x00000053  0x00053300  0x006e5db8
  0xbfffd344:  0x01f10001  0x01fe0244  0x01f10001  0x01fe0244
  0xbfffd354:  0x01f10001  0x01fe0244  0x00000000  0xbfffd3c0
  0xbfffd364:  0x01010000  0x00f9f46d  0x927d14fc  0x031d98b0

And the pointer:

(gdb) x/1 0x7e63a4
0x7e63a4:  0xffffffff

----------------------------------------------------------------------
This is the backtrace leading to the crash.  Note that the arguments
to DrawText (macterm.c:764) look just fine:

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x9158ccd4 in SetupOffscreenGDevice ()
(gdb) bt
#0  0x9158ccd4 in SetupOffscreenGDevice ()
#1  0x91587990 in PortToNQDPixMap ()
#2  0x91587990 in PortToNQDPixMap ()
#3  0x915755d4 in StdText ()
#4  0x00206608 in mac_draw_string_common (display=0x0, w=0x25c9e20, gc=0x3139970, x=1, y=507, buf=0xbfffd620 "-:** #emacs@saberhagen.OPN 3:33PM 1.04 (ERC Abbrev)--Bot", '-' <repeats 27 times>, "R", nchars=83, mode=1, bytes_per_char=1) at macterm.c:764
#5  0x00206678 in XDrawString (display=0x0, w=0x25c9e20, gc=0x3139970, x=1, y=507, buf=0xbfffd620 "-:** #emacs@saberhagen.OPN 3:33PM 1.04 (ERC Abbrev)--Bot", '-' <repeats 27 times>, "R", nchars=83) at macterm.c:779
#6  0x00208e20 in x_draw_glyph_string_foreground (s=0xbfffd6e0) at macterm.c:2087
#7  0x0020b718 in x_draw_glyph_string (s=0xbfffd6e0) at macterm.c:3070
#8  0x0005585c in draw_glyphs (w=0x25e88c0, x=582, row=0x4e3804c, area=TEXT_AREA, start=0, end=83, hl=DRAW_NORMAL_TEXT, overlaps_p=0) at xdisp.c:17978
#9  0x00058fa0 in x_write_glyphs (start=0x4f80400, len=83) at xdisp.c:18979
#10 0x000110d0 in update_text_area (w=0x25e88c0, vpos=51) at dispnew.c:4288
#11 0x00011a68 in update_window_line (w=0x25e88c0, vpos=51, mouse_face_overwritten_p=0xbfffda54) at dispnew.c:4512
#12 0x00010a88 in update_window (w=0x25e88c0, force_p=0) at dispnew.c:4110
#13 0x000101f8 in update_window_tree (w=0x25e88c0, force_p=0) at dispnew.c:3897
#14 0x0000fffc in update_frame (f=0x31c07a0, force_p=0, inhibit_hairy_id_p=0) at dispnew.c:3829
#15 0x0003e69c in redisplay_internal (preserve_echo_area=0) at xdisp.c:10132
#16 0x0003c0f8 in redisplay () at xdisp.c:9337

----------------------------------------------------------------------
And lastly, the disassembly for SetupOffscreenGDevice.  I can't find
documentation on this function anywhere, so I have no idea what the
bad pointer means.

Dump of assembler code for function SetupOffscreenGDevice:
0x9158cc00 <SetupOffscreenGDevice+0>:   mflr    r0
0x9158cc04 <SetupOffscreenGDevice+4>:   bcl-    20,4*cr7+so,0x9158cc08 <SetupOffscreenGDevice+8>
0x9158cc08 <SetupOffscreenGDevice+8>:   stmw    r29,-12(r1)
0x9158cc0c <SetupOffscreenGDevice+12>:  mflr    r31
0x9158cc10 <SetupOffscreenGDevice+16>:  addis   r29,r31,4093
0x9158cc14 <SetupOffscreenGDevice+20>:  stw     r0,8(r1)
0x9158cc18 <SetupOffscreenGDevice+24>:  addi    r10,r29,29020
0x9158cc1c <SetupOffscreenGDevice+28>:  stwu    r1,-80(r1)
0x9158cc20 <SetupOffscreenGDevice+32>:  lwz     r2,0(r10)
0x9158cc24 <SetupOffscreenGDevice+36>:  addi    r11,r3,8
0x9158cc28 <SetupOffscreenGDevice+40>:  lwz     r0,0(r3)
0x9158cc2c <SetupOffscreenGDevice+44>:  lwz     r2,0(r2)
0x9158cc30 <SetupOffscreenGDevice+48>:  lwz     r2,22(r2)
0x9158cc34 <SetupOffscreenGDevice+52>:  lwz     r30,0(r2)
0x9158cc38 <SetupOffscreenGDevice+56>:  li      r2,-32768
0x9158cc3c <SetupOffscreenGDevice+60>:  stw     r0,0(r30)
0x9158cc40 <SetupOffscreenGDevice+64>:  addi    r9,r30,6
0x9158cc44 <SetupOffscreenGDevice+68>:  lhz     r0,6(r3)
0x9158cc48 <SetupOffscreenGDevice+72>:  or      r0,r0,r2
0x9158cc4c <SetupOffscreenGDevice+76>:  lis     r2,72
0x9158cc50 <SetupOffscreenGDevice+80>:  sth     r0,4(r30)
0x9158cc54 <SetupOffscreenGDevice+84>:  lswi    r7,r11,8
0x9158cc58 <SetupOffscreenGDevice+88>:  stswi   r7,r9,8
0x9158cc5c <SetupOffscreenGDevice+92>:  li      r9,0
0x9158cc60 <SetupOffscreenGDevice+96>:  lhz     r0,16(r3)
0x9158cc64 <SetupOffscreenGDevice+100>: stw     r2,26(r30)
0x9158cc68 <SetupOffscreenGDevice+104>: sth     r0,14(r30)
0x9158cc6c <SetupOffscreenGDevice+108>: li      r0,0
0x9158cc70 <SetupOffscreenGDevice+112>: sth     r0,16(r30)
0x9158cc74 <SetupOffscreenGDevice+116>: stw     r9,18(r30)
0x9158cc78 <SetupOffscreenGDevice+120>: stw     r2,22(r30)
0x9158cc7c <SetupOffscreenGDevice+124>: lhz     r0,18(r3)
0x9158cc80 <SetupOffscreenGDevice+128>: sth     r0,30(r30)
0x9158cc84 <SetupOffscreenGDevice+132>: lbz     r0,20(r3)
0x9158cc88 <SetupOffscreenGDevice+136>: extsb   r0,r0
0x9158cc8c <SetupOffscreenGDevice+140>: sth     r0,32(r30)
0x9158cc90 <SetupOffscreenGDevice+144>: lbz     r0,21(r3)
0x9158cc94 <SetupOffscreenGDevice+148>: extsb   r0,r0
0x9158cc98 <SetupOffscreenGDevice+152>: sth     r0,34(r30)
0x9158cc9c <SetupOffscreenGDevice+156>: lbz     r0,22(r3)
0x9158cca0 <SetupOffscreenGDevice+160>: stw     r9,46(r30)
0x9158cca4 <SetupOffscreenGDevice+164>: extsb   r0,r0
0x9158cca8 <SetupOffscreenGDevice+168>: stw     r9,38(r30)
0x9158ccac <SetupOffscreenGDevice+172>: sth     r0,36(r30)
0x9158ccb0 <SetupOffscreenGDevice+176>: lwz     r2,0(r10)
0x9158ccb4 <SetupOffscreenGDevice+180>: lwz     r2,0(r2)
0x9158ccb8 <SetupOffscreenGDevice+184>: addi    r2,r2,34
0x9158ccbc <SetupOffscreenGDevice+188>: lswi    r8,r11,8
0x9158ccc0 <SetupOffscreenGDevice+192>: stswi   r8,r2,8
0x9158ccc4 <SetupOffscreenGDevice+196>: lwz     r4,24(r3)
0x9158ccc8 <SetupOffscreenGDevice+200>: cmpwi   cr7,r4,0
0x9158cccc <SetupOffscreenGDevice+204>: beq-    cr7,0x9158ccf0 <SetupOffscreenGDevice+240>
0x9158ccd0 <SetupOffscreenGDevice+208>: lwz     r4,0(r4)
0x9158ccd4 <SetupOffscreenGDevice+212>: lha     r0,6(r4)  ; r4 = -1

Re: More info on sporadic OS/X crash

[John Wiegley]

John Wiegley <johnw@gnu.org> writes:

> I've been running Emacs built with -g, waiting for the frequent OS/X
> Carbon crash to appear.  Now I have much more info, though I still
> don't know what it means:
>
> The crash occurs here:
>
>   0x9158ccd0 <SetupOffscreenGDevice+208>: lwz     r4,0(r4)
>
> because $r4 is -1.  This value comes from:
>
>   0x9158ccc4 <SetupOffscreenGDevice+196>: lwz     r4,24(r3)

The crash does not happen if I run in a single frame.  So, my
environment has these features:

 - I have two frames open.

 - These two frames use different fonts.  One uses the default startup
   font, the other has been configured using the Lisp code below.

 - The crash seems to occur at unpredictable times while repainting
   the frame using the default font.

I am setting the font in my other frame using:

(defun big-font ()
  (interactive)
  (create-fontset-from-fontset-spec
   "-apple-courier-medium-r-normal--18-*-*-*-*-*-fontset-courier18,
ascii:-apple-courier-medium-r-normal--18-180-75-75-m-180-mac-roman,
latin-iso8859-1:-apple-courier-medium-r-normal--18-180-75-75-m-180-mac-roman")

  (set-frame-font "fontset-courier18")
  (setq-default line-spacing 1))

Does this ring any bells yet?

John

Re: More info on sporadic OS/X crash

[YAMAMOTO Mitsuharu]

>>>>> On Fri, 23 Apr 2004 04:41:46 -0700, John Wiegley <johnw@gnu.org> said:

> The crash does not happen if I run in a single frame.  So, my
> environment has these features:

>  - I have two frames open.

>  - These two frames use different fonts.  One uses the default
> startup font, the other has been configured using the Lisp code
> below.

>  - The crash seems to occur at unpredictable times while repainting
> the frame using the default font.

> Does this ring any bells yet?

Could you please try the patch I posted in the following message and
see similar crash still occurs?
http://mail.gnu.org/archive/html/emacs-devel/2004-04/msg00783.html
(Sorry about copy&paste.)

The reason why I'm saying about event handling is that the current CVS
code discards window events in the queue when C-g occurs.  I suspect
this behavior makes some internal structures go into inconsistent
states.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: More info on sporadic OS/X crash

[Steven Tamm]

The patch seemed to make sense to be, except for the FD_CLR (i.e. the 
bug in select from 10.1)
I forgot to ask, have you tried that patch on 10.2 or just 10.3?  And 
with the non-carbon build?

I haven't run into the crash yet, and fairly sure the FD_CLR thing is 
needed on 10.1.  Maybe something should be added to configure.in?

Can anyone out there with a 10.2 system try and build with the patch?

Thanks,
-Steven

On Apr 23, 2004, at 6:15 PM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Fri, 23 Apr 2004 04:41:46 -0700, John Wiegley <johnw@gnu.org> 
>>>>>> said:
>
>> The crash does not happen if I run in a single frame.  So, my
>> environment has these features:
>
>>  - I have two frames open.
>
>>  - These two frames use different fonts.  One uses the default
>> startup font, the other has been configured using the Lisp code
>> below.
>
>>  - The crash seems to occur at unpredictable times while repainting
>> the frame using the default font.
>
>> Does this ring any bells yet?
>
> Could you please try the patch I posted in the following message and
> see similar crash still occurs?
> http://mail.gnu.org/archive/html/emacs-devel/2004-04/msg00783.html
> (Sorry about copy&paste.)
>
> The reason why I'm saying about event handling is that the current CVS
> code discards window events in the queue when C-g occurs.  I suspect
> this behavior makes some internal structures go into inconsistent
> states.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: More info on sporadic OS/X crash

[YAMAMOTO Mitsuharu]

>>>>> On Sun, 25 Apr 2004 10:49:07 -0700, Steven Tamm <steventamm@mac.com> said:

> The patch seemed to make sense to be, except for the FD_CLR
> (i.e. the bug in select from 10.1) I forgot to ask, have you tried
> that patch on 10.2 or just 10.3?

I just tried the patch on both 10.1.5 and 10.2.8, but I could not find
any problems by a few tests on subprocesses.  If you have a specific
example, maybe I can test it.

> And with the non-carbon build?

For the X11 build, fd 0 is excluded from input_wait_mask with
add_keyboard_wait_descriptor in x_term_init.  For the Carbon build, fd
0 is never consulted in sys_select (in mac.c with the patch), but the
window event queue is consulted instead.

A comment in mac.c says:

   When Emacs is started from the Finder, SELECT always immediately
   returns as if input is present when file descriptor 0 is polled for
   input.  Strangely, when Emacs is run as a GUI application from the
   command line, it blocks in the same situation.  This `wrapper' of
   the system call SELECT corrects this discrepancy.

According to the output of lsof, fd 0 is bound to /dev/null for the
former case, whereas it is bound to the tty from which Emacs is
invoked for the latter case.  That would explain the above phenomena.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: More info on sporadic OS/X crash

[Steven Tamm]

The reason for all of the polling nonsense in the first place is to 
deal with runaway processes.
For example, compile this program and run it using (shell-command) or 
M-!
#include <stdio.h>
int main(int argc, char** argv) {
   while (1)
     ;
}
If C-g interrupts it, then it still works.  With carbon emacs as it is 
now, this works.

The other example would be to setup an infinite loop *inside* emacs; 
i.e. not as a subprocesses.  The simplest being:
(while t t)
Right now, with Carbon Emacs, this causes the beachball of death and 
C-g does nothing.  This is why the "mac_check_for_quit_char" is 
peppered throughout the code; but in this instance it doesn't work.  Of 
course if you send a SIGINT to the process it works...  And (while t 
(eval t)), a more realistic example, C-g does work.

I filed a bug with Apple a year and a half ago asking if an application 
could setup a key that causes a signal, but I can't seem to find the 
resolution for it.

-Steven

On Apr 26, 2004, at 6:15 AM, YAMAMOTO Mitsuharu wrote:

>>>>>> On Sun, 25 Apr 2004 10:49:07 -0700, Steven Tamm 
>>>>>> <steventamm@mac.com> said:
>
>> The patch seemed to make sense to be, except for the FD_CLR
>> (i.e. the bug in select from 10.1) I forgot to ask, have you tried
>> that patch on 10.2 or just 10.3?
>
> I just tried the patch on both 10.1.5 and 10.2.8, but I could not find
> any problems by a few tests on subprocesses.  If you have a specific
> example, maybe I can test it.
>
>> And with the non-carbon build?
>
> For the X11 build, fd 0 is excluded from input_wait_mask with
> add_keyboard_wait_descriptor in x_term_init.  For the Carbon build, fd
> 0 is never consulted in sys_select (in mac.c with the patch), but the
> window event queue is consulted instead.
>
> A comment in mac.c says:
>
>    When Emacs is started from the Finder, SELECT always immediately
>    returns as if input is present when file descriptor 0 is polled for
>    input.  Strangely, when Emacs is run as a GUI application from the
>    command line, it blocks in the same situation.  This `wrapper' of
>    the system call SELECT corrects this discrepancy.
>
> According to the output of lsof, fd 0 is bound to /dev/null for the
> former case, whereas it is bound to the tty from which Emacs is
> invoked for the latter case.  That would explain the above phenomena.
>
> 				     YAMAMOTO Mitsuharu
> 				mituharu@math.s.chiba-u.ac.jp

Re: More info on sporadic OS/X crash

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 26 Apr 2004 09:27:52 -0700, Steven Tamm <steventamm@mac.com> said:

> The reason for all of the polling nonsense in the first place is to 
> deal with runaway processes.
> For example, compile this program and run it using (shell-command) or 
> M-!
> #include <stdio.h>
> int main(int argc, char** argv) {
>    while (1)
>      ;
> }
> If C-g interrupts it, then it still works.  With carbon emacs as it is 
> now, this works.

> The other example would be to setup an infinite loop *inside* emacs; 
> i.e. not as a subprocesses.  The simplest being:
> (while t t)
> Right now, with Carbon Emacs, this causes the beachball of death and 
> C-g does nothing.  This is why the "mac_check_for_quit_char" is 
> peppered throughout the code; but in this instance it doesn't work.  Of 
> course if you send a SIGINT to the process it works...  And (while t 
> (eval t)), a more realistic example, C-g does work.

All the examples you mentioned above can be interrupted with the
patched version (also on 10.1).  That's not surprising because I just
imitated the way of event handling in Solaris (a system without SIGIO)
where the event queue is periodically (every 2 seconds by default)
polled using the alarm timer.  Not only C-g but also window events
such as window movement are processed at this timing, so one can move
the window during a command loop or waiting for a synchronous process,
although it is sluggish.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: More info on sporadic OS/X crash

[Piet van Oostrum]

>>>>> Steven Tamm <steventamm@mac.com> (ST) wrote:

ST> The patch seemed to make sense to be, except for the FD_CLR (i.e. the bug
ST> in select from 10.1)
ST> I forgot to ask, have you tried that patch on 10.2 or just 10.3?  And with
ST> the non-carbon build?

I now run with this patch and I only had one crash in a couple of days.
But this was a crash in the garbage collector, quite different from what I
used to have.

However now I have occasional hangs in select(), always when using gnus.
It could be a server that is not responding, but I am not sure. I attach a
stack trace below. The hang doesn't get broken with C-g (the well-known
problem), but sometimes it helps to Ctrl-Z gdb (I am running emacs from
gdb), and/or hitting Ctrl-C in the gdb terminal window. Continuing then
resumes normal life but it can take quite some time.

Program received signal SIGTSTP, Stopped (user).
0x9000b308 in select ()
(gdb) bt
#0  0x9000b308 in select ()
#1  0x0012eeac in sys_select (n=126, rfds=0x38e7e4, wfds=0x0, efds=0x0, timeout=0xbfffcb60) at mac.c:2787
#2  0x00119948 in wait_reading_process_input (time_limit=1, microsecs=0, read_kbd=3506604, do_display=0) at process.c:4311
#3  0x00118afc in Faccept_process_output (process=3729380, timeout=3506604, timeout_msecs=146922928) at process.c:3772
#4  0x000e3700 in Ffuncall (nargs=4, args=0xbfffcb60) at eval.c:2730
#5  0x00112344 in Fbyte_code (bytestr=146922928, vector=3729380, maxdepth=-1073755296) at bytecode.c:689
#6  0x000e3d14 in funcall_lambda (fun=-1073755296, nargs=126, arg_vector=0x38903c) at eval.c:2910
#7  0x000e3834 in Ffuncall (nargs=4, args=0xbfffcb60) at eval.c:2780
#8  0x00112344 in Fbyte_code (bytestr=146922928, vector=3729380, maxdepth=-1073755296) at bytecode.c:689
#9  0x000e2a00 in Feval (form=146922928) at eval.c:2084
#10 0x000e1404 in Fcondition_case (args=146922928) at eval.c:1280
#11 0x00112b70 in Fbyte_code (bytestr=595650096, vector=143, maxdepth=-1073752192) at bytecode.c:870
#12 0x000e3d14 in funcall_lambda (fun=-1073752192, nargs=3, arg_vector=0x3519e0) at eval.c:2910
#13 0x000e3834 in Ffuncall (nargs=4, args=0xbfffd780) at eval.c:2780
#14 0x00112344 in Fbyte_code (bytestr=595650096, vector=143, maxdepth=-1073752192) at bytecode.c:689
#15 0x000e3d14 in funcall_lambda (fun=-1073752192, nargs=3, arg_vector=0x3519e0) at eval.c:2910
#16 0x000e3834 in Ffuncall (nargs=4, args=0xbfffd780) at eval.c:2780
#17 0x00112344 in Fbyte_code (bytestr=595650096, vector=143, maxdepth=-1073752192) at bytecode.c:689
#18 0x000e3d14 in funcall_lambda (fun=-1073752192, nargs=3, arg_vector=0x3519e0) at eval.c:2910
#19 0x000e3834 in Ffuncall (nargs=4, args=0xbfffd780) at eval.c:2780
#20 0x00112344 in Fbyte_code (bytestr=595650096, vector=143, maxdepth=-1073752192) at bytecode.c:689
#21 0x000e3d14 in funcall_lambda (fun=-1073752192, nargs=3, arg_vector=0x3519e0) at eval.c:2910
#22 0x000e3834 in Ffuncall (nargs=4, args=0xbfffd780) at eval.c:2780
#23 0x00112344 in Fbyte_code (bytestr=595650096, vector=143, maxdepth=-1073752192) at bytecode.c:689
#24 0x000e3d14 in funcall_lambda (fun=-1073752192, nargs=3, arg_vector=0x3519e0) at eval.c:2910
#25 0x000e3834 in Ffuncall (nargs=4, args=0xbfffd780) at eval.c:2780
#26 0x00112344 in Fbyte_code (bytestr=595650096, vector=143, maxdepth=-1073752192) at bytecode.c:689
#27 0x000e3d14 in funcall_lambda (fun=-1073752192, nargs=3, arg_vector=0x3519e0) at eval.c:2910
#28 0x000e3834 in Ffuncall (nargs=4, args=0xbfffd780) at eval.c:2780
#29 0x00112344 in Fbyte_code (bytestr=595650096, vector=143, maxdepth=-1073752192) at bytecode.c:689
#30 0x000e3d14 in funcall_lambda (fun=-1073752192, nargs=3, arg_vector=0x3519e0) at eval.c:2910
#31 0x000e3834 in Ffuncall (nargs=4, args=0xbfffd780) at eval.c:2780
#32 0x00112344 in Fbyte_code (bytestr=595650096, vector=143, maxdepth=-1073752192) at bytecode.c:689
#33 0x000e3d14 in funcall_lambda (fun=-1073752192, nargs=3, arg_vector=0x3519e0) at eval.c:2910
#34 0x000e3834 in Ffuncall (nargs=4, args=0xbfffd780) at eval.c:2780
#35 0x00112344 in Fbyte_code (bytestr=595650096, vector=143, maxdepth=-1073752192) at bytecode.c:689
#36 0x000e3d14 in funcall_lambda (fun=-1073752192, nargs=3, arg_vector=0x3519e0) at eval.c:2910
#37 0x000e3834 in Ffuncall (nargs=4, args=0xbfffd780) at eval.c:2780
#38 0x000df460 in Fcall_interactively (function=145261712, record_flag=0, keys=3480032) at callint.c:862
#39 0x000887d8 in Fcommand_execute (cmd=689382640, record_flag=145261720, keys=4, special=0) at keyboard.c:9670
#40 0x0007d434 in command_loop_1 () at keyboard.c:1727
#41 0x000e1568 in internal_condition_case (bfun=0x7c33c <command_loop_1>, handlers=595637288, hfun=0x7bd3c <cmd_error>) at eval.c:1333
#42 0x0007c164 in command_loop_2 () at keyboard.c:1264
#43 0x000e0fd0 in internal_catch (tag=4, func=0x7c124 <command_loop_2>, arg=595592192) at eval.c:1094
#44 0x0007c0bc in command_loop () at keyboard.c:1243
#45 0x0007bad8 in recursive_edit_1 () at keyboard.c:959
#46 0x0007bc60 in Frecursive_edit () at keyboard.c:1015
#47 0x0007a788 in main (argc=-1073752208, argv=0x8a88490) at emacs.c:1692
(gdb) Quit
(gdb) cont
Continuing.

-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: More info on sporadic OS/X crash

[Eli Zaretskii]

> From: Piet van Oostrum <piet@cs.uu.nl>
> Date: 27 Apr 2004 17:24:36 +0200
> 
> However now I have occasional hangs in select(), always when using gnus.
> It could be a server that is not responding, but I am not sure. I attach a
> stack trace below. The hang doesn't get broken with C-g (the well-known
> problem), but sometimes it helps to Ctrl-Z gdb (I am running emacs from
> gdb), and/or hitting Ctrl-C in the gdb terminal window. Continuing then
> resumes normal life but it can take quite some time.
> 
> Program received signal SIGTSTP, Stopped (user).
> 0x9000b308 in select ()
> (gdb) bt
> #0  0x9000b308 in select ()
> #1  0x0012eeac in sys_select (n=126, rfds=0x38e7e4, wfds=0x0, efds=0x0, timeout=0xbfffcb60) at mac.c:2787
> #2  0x00119948 in wait_reading_process_input (time_limit=1, microsecs=0, read_kbd=3506604, do_display=0) at process.c:4311

What is the contents of the struct pointed to by `timeout' in frame #1
above?  Can you tell what GDB prints if you type

	print *timeout

in that frame?

If the contents of that struct are reasonable (i.e. 1 second), is it
possible that Emacs loops infinitely in sys_select, and if so, why?

Re: More info on sporadic OS/X crash

[Piet van Oostrum]

>>>>> Eli Zaretskii <eliz@gnu.org> (EZ) wrote:

>> From: Piet van Oostrum <piet@cs.uu.nl>
>> Date: 27 Apr 2004 17:24:36 +0200
>> 
>> However now I have occasional hangs in select(), always when using gnus.
>> It could be a server that is not responding, but I am not sure. I attach a
>> stack trace below. The hang doesn't get broken with C-g (the well-known
>> problem), but sometimes it helps to Ctrl-Z gdb (I am running emacs from
>> gdb), and/or hitting Ctrl-C in the gdb terminal window. Continuing then
>> resumes normal life but it can take quite some time.
>> 
>> Program received signal SIGTSTP, Stopped (user).
>> 0x9000b308 in select ()
>> (gdb) bt
>> #0  0x9000b308 in select ()
>> #1  0x0012eeac in sys_select (n=126, rfds=0x38e7e4, wfds=0x0, efds=0x0, timeout=0xbfffcb60) at mac.c:2787
>> #2  0x00119948 in wait_reading_process_input (time_limit=1, microsecs=0, read_kbd=3506604, do_display=0) at process.c:4311

EZ> What is the contents of the struct pointed to by `timeout' in frame #1
EZ> above?  Can you tell what GDB prints if you type

EZ> 	print *timeout

EZ> in that frame?

EZ> If the contents of that struct are reasonable (i.e. 1 second), is it
EZ> possible that Emacs loops infinitely in sys_select, and if so, why?

(gdb) frame 1
#1  0x0012eeac in sys_select (n=126, rfds=0x38e7e4, wfds=0x0, efds=0x0, timeout=0xbfffc770) at mac.c:2787
2787        return select(n, rfds, wfds, efds, timeout);    
(gdb) print *timeout
$3 = {
  tv_sec = 0, 
  tv_usec = 999996
}

So this looks normal.
Next time it hangs I will step through the code to see what happens.
I can't get it to hang again now.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: More info on sporadic OS/X crash

[Eli Zaretskii]

> From: "Piet van Oostrum" <piet@cs.uu.nl>
> Date: Wed, 28 Apr 2004 13:14:59 +0200
> 
> (gdb) frame 1
> #1  0x0012eeac in sys_select (n=126, rfds=0x38e7e4, wfds=0x0, efds=0x0, timeout=0xbfffc770) at mac.c:2787
> 2787        return select(n, rfds, wfds, efds, timeout);    
> (gdb) print *timeout
> $3 = {
>   tv_sec = 0, 
>   tv_usec = 999996
> }
> 
> So this looks normal.

Well, yes and no: how come it's 999996 microseconds instead of a full
second?  That is, why don't you see this instead?

 $3 = {
   tv_sec = 1, 
   tv_usec = 0
 }

This higher frame in the backtrace:

> #2  0x00119948 in wait_reading_process_input (time_limit=1, microsecs=0, read_kbd=3506604, do_display=0) at process.c:4311

seems to imply that wait_reading_process_input was called to wait for
1 second and 0 microseconds, so where from did the small inaccuracy
creep in?

Re: More info on sporadic OS/X crash

[Piet van Oostrum]

>>>>> "Eli Zaretskii" <eliz@gnu.org> (EZ) wrote:

>> From: "Piet van Oostrum" <piet@cs.uu.nl>
>> Date: Wed, 28 Apr 2004 13:14:59 +0200
>> 
>> (gdb) frame 1
>> #1  0x0012eeac in sys_select (n=126, rfds=0x38e7e4, wfds=0x0, efds=0x0, timeout=0xbfffc770) at mac.c:2787
>> 2787        return select(n, rfds, wfds, efds, timeout);    
>> (gdb) print *timeout
>> $3 = {
>> tv_sec = 0, 
>> tv_usec = 999996
>> }
>> 
>> So this looks normal.

EZ> Well, yes and no: how come it's 999996 microseconds instead of a full
EZ> second?  That is, why don't you see this instead?

EZ>  $3 = {
EZ>    tv_sec = 1, 
EZ>    tv_usec = 0
EZ>  }

EZ> This higher frame in the backtrace:

>> #2  0x00119948 in wait_reading_process_input (time_limit=1, microsecs=0, read_kbd=3506604, do_display=0) at process.c:4311

EZ> seems to imply that wait_reading_process_input was called to wait for
EZ> 1 second and 0 microseconds, so where from did the small inaccuracy
EZ> creep in?

There is some code just above the select that manipulates the usecs.
(The ADAPTIVE_READ_BUFFERING stuff). But I think it always makes it a
multiple of READ_OUTPUT_DELAY_INCREMENT, which this isn't. 

Then there's also timer_delay which gets calculated from something
with the current time in it, so maybe that's it.
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: More info on sporadic OS/X crash

[Kim F. Storm]

"Piet van Oostrum" <piet@cs.uu.nl> writes:

> >>>>> "Eli Zaretskii" <eliz@gnu.org> (EZ) wrote:
> 
> >> From: "Piet van Oostrum" <piet@cs.uu.nl>
> >> Date: Wed, 28 Apr 2004 13:14:59 +0200
> >> 
> >> (gdb) frame 1
> >> #1  0x0012eeac in sys_select (n=126, rfds=0x38e7e4, wfds=0x0, efds=0x0, timeout=0xbfffc770) at mac.c:2787
> >> 2787        return select(n, rfds, wfds, efds, timeout);    
> >> (gdb) print *timeout
> >> $3 = {
> >> tv_sec = 0, 
> >> tv_usec = 999996
> >> }
> >> 
> >> So this looks normal.
> 
> EZ> Well, yes and no: how come it's 999996 microseconds instead of a full
> EZ> second?  That is, why don't you see this instead?
> 
> EZ>  $3 = {
> EZ>    tv_sec = 1, 
> EZ>    tv_usec = 0
> EZ>  }
> 
> EZ> This higher frame in the backtrace:
> 
> >> #2  0x00119948 in wait_reading_process_input (time_limit=1, microsecs=0, read_kbd=3506604, do_display=0) at process.c:4311
> 
> EZ> seems to imply that wait_reading_process_input was called to wait for
> EZ> 1 second and 0 microseconds, so where from did the small inaccuracy
> EZ> creep in?
> 
> There is some code just above the select that manipulates the usecs.
> (The ADAPTIVE_READ_BUFFERING stuff). But I think it always makes it a
> multiple of READ_OUTPUT_DELAY_INCREMENT, which this isn't. 
> 
> Then there's also timer_delay which gets calculated from something
> with the current time in it, so maybe that's it.

The Linux kernel adjusts the timeout value upon return from select to
contain the amount of time "remaining to the specified timeout".  This
is very useful in some situations.

Maybe OS/X does that too.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: More info on sporadic OS/X crash

[Steven Tamm]

 From the 10.2 and 10.3 select man pages.

      Select() should probably have been designed to return the time 
remaining
      from the original timeout, if any, by modifying the time value in 
place.
      However, it is unlikely this semantic will ever be implemented, as 
the
      change would cause source code compatibility problems.  In general 
it is
      unwise to assume that the timeout value will be unmodified by the
      select() call, and the caller should reinitialize it on each 
invocation.

However it appears that in the code for xnu-344/bsd/kern/sys_generic.c 
(which corresponds to 10.2), they actually implemented this change

So don't worry about the timeout changing.

-Steven

On Apr 29, 2004, at 9:32 AM, Kim F. Storm wrote:

> "Piet van Oostrum" <piet@cs.uu.nl> writes:
>
>>>>>>> "Eli Zaretskii" <eliz@gnu.org> (EZ) wrote:
>>
>>>> From: "Piet van Oostrum" <piet@cs.uu.nl>
>>>> Date: Wed, 28 Apr 2004 13:14:59 +0200
>>>>
>>>> (gdb) frame 1
>>>> #1  0x0012eeac in sys_select (n=126, rfds=0x38e7e4, wfds=0x0, 
>>>> efds=0x0, timeout=0xbfffc770) at mac.c:2787
>>>> 2787        return select(n, rfds, wfds, efds, timeout);
>>>> (gdb) print *timeout
>>>> $3 = {
>>>> tv_sec = 0,
>>>> tv_usec = 999996
>>>> }
>>>>
>>>> So this looks normal.
>>
>> EZ> Well, yes and no: how come it's 999996 microseconds instead of a 
>> full
>> EZ> second?  That is, why don't you see this instead?
>>
>> EZ>  $3 = {
>> EZ>    tv_sec = 1,
>> EZ>    tv_usec = 0
>> EZ>  }
>>
>> EZ> This higher frame in the backtrace:
>>
>>>> #2  0x00119948 in wait_reading_process_input (time_limit=1, 
>>>> microsecs=0, read_kbd=3506604, do_display=0) at process.c:4311
>>
>> EZ> seems to imply that wait_reading_process_input was called to wait 
>> for
>> EZ> 1 second and 0 microseconds, so where from did the small 
>> inaccuracy
>> EZ> creep in?
>>
>> There is some code just above the select that manipulates the usecs.
>> (The ADAPTIVE_READ_BUFFERING stuff). But I think it always makes it a
>> multiple of READ_OUTPUT_DELAY_INCREMENT, which this isn't.
>>
>> Then there's also timer_delay which gets calculated from something
>> with the current time in it, so maybe that's it.
>
> The Linux kernel adjusts the timeout value upon return from select to
> contain the amount of time "remaining to the specified timeout".  This
> is very useful in some situations.
>
> Maybe OS/X does that too.
>
> -- 
> Kim F. Storm <storm@cua.dk> http://www.cua.dk
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://mail.gnu.org/mailman/listinfo/emacs-devel

Re: More info on sporadic OS/X crash

[Piet van Oostrum]

>>>>> storm@cua.dk (Kim F. Storm) (KFS) wrote:

KFS> The Linux kernel adjusts the timeout value upon return from select to
KFS> contain the amount of time "remaining to the specified timeout".  This
KFS> is very useful in some situations.

KFS> Maybe OS/X does that too.

The man page says:

     Timeout is not changed by select(), and may be reused on
     subsequent calls, however it is good style to re-initialize it
     before each invocation of select().
-- 
Piet van Oostrum <piet@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van.Oostrum@hccnet.nl

Re: More info on sporadic OS/X crash

[YAMAMOTO Mitsuharu]

>>>>> On 27 Apr 2004 17:24:36 +0200, Piet van Oostrum <piet@cs.uu.nl> said:

> However now I have occasional hangs in select(), always when using
> gnus.  It could be a server that is not responding, but I am not
> sure. 

I encountered the following situation (though I'm not sure whether it
is related to the above one):

   1. select (actually, sys_select in mac.c) is called from
      wait_reading_process_input.
   2. Interrupt by SIGALRM occurs while ReceiveNextEvent in sys_select
      is being processed.
   3. ReceiveNextEvent is called from XTread_socket again.
   4. Emacs hangs.

So at least ReceiveNextEvent in sys_select must be enclosed with
BLOCK_INPUT/UNBLOCK_INPUT.

Below is the sys_select function currently I'm using.  Besides the
above issue, I also modified the calculation of the remaining time for
timeout and added a special handling for the common case where there
are no subprocesses to be monitored.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

#include "blockinput.h"
int
sys_select (n, rfds, wfds, efds, timeout)
  int n;
  SELECT_TYPE *rfds;
  SELECT_TYPE *wfds;
  SELECT_TYPE *efds;
  struct timeval *timeout;
{
  OSErr err;
  EMACS_TIME end_time, now, remaining_time;

  if (inhibit_window_system || noninteractive
      || rfds == NULL || !FD_ISSET (0, rfds))
    return select(n, rfds, wfds, efds, timeout);

  if (wfds == NULL && efds == NULL)
    {
      int i;

      for (i = 1; i < n; i++)
	if (FD_ISSET (i, rfds))
	  break;
      if (i == n)
	{
	  EventTimeout timeout_sec =
	    (timeout
	     ? (EMACS_SECS (*timeout) + EMACS_USECS (*timeout) / 1000000.0)
	     : kEventDurationForever);

	  BLOCK_INPUT;
	  err = ReceiveNextEvent (0, NULL, timeout_sec, false, NULL);
	  UNBLOCK_INPUT;
	  if (err == noErr)
	    {
	      FD_ZERO (rfds);
	      FD_SET (0, rfds);
	      return 1;
	    }
	  else
	    return 0;
	}
    }

  if (timeout)
    {
      remaining_time = *timeout;
      EMACS_GET_TIME (now);
      EMACS_ADD_TIME (end_time, now, remaining_time);
    }

  FD_CLR (0, rfds);
  do
    {
      EMACS_TIME select_timeout;
      SELECT_TYPE orfds = *rfds;
      int r;

      EMACS_SET_SECS_USECS (select_timeout, 0, 20000);

      if (timeout && EMACS_TIME_LT (remaining_time, select_timeout))
	select_timeout = remaining_time;

      r = select (n, &orfds, wfds, efds, &select_timeout);
      BLOCK_INPUT;
      err = ReceiveNextEvent (0, NULL, kEventDurationNoWait, false, NULL);
      UNBLOCK_INPUT;
      if (r > 0)
	{
	  *rfds = orfds;
	  if (err == noErr)
	    {
	      FD_SET (0, rfds);
	      r++;
	    }
	  return r;
	}
      else if (err == noErr)
	{
	  FD_ZERO (rfds);
	  FD_SET (0, rfds);
	  return 1;
	}

      if (timeout)
	{
	  EMACS_GET_TIME (now);
	  EMACS_SUB_TIME (remaining_time, end_time, now);
	}
    }
  while (!timeout || EMACS_TIME_LT (now, end_time));

  return 0;
}

Re: More info on sporadic OS/X crash

[John Wiegley]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Could you please try the patch I posted in the following message and
> see similar crash still occurs?
> http://mail.gnu.org/archive/html/emacs-devel/2004-04/msg00783.html
> (Sorry about copy&paste.)
>
> The reason why I'm saying about event handling is that the current
> CVS code discards window events in the queue when C-g occurs.  I
> suspect this behavior makes some internal structures go into
> inconsistent states.

I will note that I am not using C-g when these crashes occur.  It
seems to happen when pressing return, just before scrolling is about
to happen.

John

Re: More info on sporadic OS/X crash

[YAMAMOTO Mitsuharu]

>>>>> On Mon, 26 Apr 2004 11:08:52 -0700, John Wiegley <johnw@gnu.org> said:

> I will note that I am not using C-g when these crashes occur.  It
> seems to happen when pressing return, just before scrolling is about
> to happen.

C-g may not cause the crash immediately, but possibly cause a later
crash.  Anyway, I have currently no idea how the crash you mentioned
is triggered.  So please try to see if the similar crash occurs even
with the patch I mentioned.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: More info on sporadic OS/X crash

[John Wiegley]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

>> I will note that I am not using C-g when these crashes occur.  It
>> seems to happen when pressing return, just before scrolling is about
>> to happen.
>
> C-g may not cause the crash immediately, but possibly cause a later
> crash.  Anyway, I have currently no idea how the crash you mentioned
> is triggered.  So please try to see if the similar crash occurs even
> with the patch I mentioned.

The crash still occurs with the patch you gave me.

John

Re: More info on sporadic OS/X crash

[YAMAMOTO Mitsuharu]

>>>>> On Thu, 29 Apr 2004 15:08:39 -0700, John Wiegley <johnw@gnu.org> said:

> The crash still occurs with the patch you gave me.

Thanks for your report.  So the crash was not related to the event
handling.

Could you try the following patch?  It does saving/restoring the
current graphics port and device handle when drawing into an offscreen
graphics world.  Lack of this process might have led to an
inconsistent state of a graphics port.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Index: src/image.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/image.c,v
retrieving revision 1.8
diff -c -r1.8 image.c
*** src/image.c	20 Apr 2004 22:16:33 -0000	1.8
--- src/image.c	1 May 2004 10:35:34 -0000
***************
*** 174,187 ****
--- 174,192 ----
       int x, y;
       unsigned long pixel;
  {
+   CGrafPtr old_port;
+   GDHandle old_gdh;
    RGBColor color;
  
+   GetGWorld (&old_port, &old_gdh);
    SetGWorld (ximage, NULL);
  
    color.red = RED16_FROM_ULONG (pixel);
    color.green = GREEN16_FROM_ULONG (pixel);
    color.blue = BLUE16_FROM_ULONG (pixel);
    SetCPixel (x, y, &color);
+ 
+   SetGWorld (old_port, old_gdh);
  }
  
  static unsigned long
***************
*** 189,199 ****
--- 194,209 ----
       XImagePtr ximage;
       int x, y;
  {
+   CGrafPtr old_port;
+   GDHandle old_gdh;
    RGBColor color;
  
+   GetGWorld (&old_port, &old_gdh);
    SetGWorld (ximage, NULL);
  
    GetCPixel (x, y, &color);
+ 
+   SetGWorld (old_port, old_gdh);
    return RGB_TO_ULONG (color.red >> 8, color.green >> 8, color.blue >> 8);
  }
  
***************
*** 2196,2201 ****
--- 2206,2215 ----
      goto error;
    if (draw_all_pixels != graphicsImporterDrawsAllPixels)
      {
+       CGrafPtr old_port;
+       GDHandle old_gdh;
+ 
+       GetGWorld (&old_port, &old_gdh);
        SetGWorld (ximg, NULL);
        bg_color.red = color.red;
        bg_color.green = color.green;
***************
*** 2207,2212 ****
--- 2221,2227 ----
  #else
        EraseRect (&(ximg->portRect));
  #endif
+       SetGWorld (old_port, old_gdh);
      }
    GraphicsImportSetGWorld (gi, ximg, NULL);
    GraphicsImportDraw (gi);
Index: src/macterm.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/macterm.c,v
retrieving revision 1.66
diff -c -r1.66 macterm.c
*** src/macterm.c	24 Apr 2004 23:42:26 -0000	1.66
--- src/macterm.c	1 May 2004 10:35:42 -0000
***************
*** 383,388 ****
--- 383,392 ----
       GC gc;
       int x1, y1, x2, y2;
  {
+   CGrafPtr old_port;
+   GDHandle old_gdh;
+ 
+   GetGWorld (&old_port, &old_gdh);
    SetGWorld (p, NULL);
  
    mac_set_colors (gc);
***************
*** 391,396 ****
--- 395,402 ----
    MoveTo (x1, y1);
    LineTo (x2, y2);
    UnlockPixels (GetGWorldPixMap (p));
+ 
+   SetGWorld (old_port, old_gdh);
  }
  
  /* Mac version of XClearArea.  */
***************
*** 620,630 ****
--- 626,639 ----
  {
    Pixmap pixmap;
    BitMap bitmap;
+   CGrafPtr old_port;
+   GDHandle old_gdh;
  
    pixmap = XCreatePixmap (display, w, width, height, depth);
    if (pixmap == NULL)
      return NULL;
  
+   GetGWorld (&old_port, &old_gdh);
    SetGWorld (pixmap, NULL);
    mac_create_bitmap_from_bitmap_data (&bitmap, data, width, height);
    mac_set_forecolor (fg);
***************
*** 638,643 ****
--- 647,653 ----
  	    &bitmap.bounds, &bitmap.bounds, srcCopy, 0);
  #endif /* not TARGET_API_MAC_CARBON */
    UnlockPixels (GetGWorldPixMap (pixmap));
+   SetGWorld (old_port, old_gdh);
    mac_free_bitmap (&bitmap);
  
    return pixmap;
***************
*** 677,684 ****
--- 687,697 ----
       int x, y;
       unsigned int width, height;
  {
+   CGrafPtr old_port;
+   GDHandle old_gdh;
    Rect r;
  
+   GetGWorld (&old_port, &old_gdh);
    SetGWorld (p, NULL);
    mac_set_colors (gc);
    SetRect (&r, x, y, x + width, y + height);
***************
*** 686,691 ****
--- 699,706 ----
    LockPixels (GetGWorldPixMap (p));
    PaintRect (&r); /* using foreground color of gc */
    UnlockPixels (GetGWorldPixMap (p));
+ 
+   SetGWorld (old_port, old_gdh);
  }
  
  
***************
*** 724,731 ****
--- 739,749 ----
       int x, y;
       unsigned int width, height;
  {
+   CGrafPtr old_port;
+   GDHandle old_gdh;
    Rect r;
  
+   GetGWorld (&old_port, &old_gdh);
    SetGWorld (p, NULL);
    mac_set_colors (gc);
    SetRect (&r, x, y, x + width + 1, y + height + 1);
***************
*** 733,738 ****
--- 751,758 ----
    LockPixels (GetGWorldPixMap (p));
    FrameRect (&r); /* using foreground color of gc */
    UnlockPixels (GetGWorldPixMap (p));
+ 
+   SetGWorld (old_port, old_gdh);
  }
  
  
***************
*** 1003,1010 ****
--- 1023,1033 ----
       unsigned int width, height;
       int dest_x, dest_y;
  {
+   CGrafPtr old_port;
+   GDHandle old_gdh;
    Rect src_r, dest_r;
  
+   GetGWorld (&old_port, &old_gdh);
    SetGWorld (dest, NULL);
    ForeColor (blackColor);
    BackColor (whiteColor);
***************
*** 1023,1028 ****
--- 1046,1053 ----
  #endif /* not TARGET_API_MAC_CARBON */
    UnlockPixels (GetGWorldPixMap (dest));
    UnlockPixels (GetGWorldPixMap (src));
+ 
+   SetGWorld (old_port, old_gdh);
  }
  
  
***************
*** 1036,1043 ****
--- 1061,1071 ----
       unsigned int width, height;
       int dest_x, dest_y;
  {
+   CGrafPtr old_port;
+   GDHandle old_gdh;
    Rect src_r, dest_r;
  
+   GetGWorld (&old_port, &old_gdh);
    SetGWorld (dest, NULL);
    ForeColor (blackColor);
    BackColor (whiteColor);
***************
*** 1058,1063 ****
--- 1086,1093 ----
    UnlockPixels (GetGWorldPixMap (dest));
    UnlockPixels (GetGWorldPixMap (mask));
    UnlockPixels (GetGWorldPixMap (src));
+ 
+   SetGWorld (old_port, old_gdh);
  }

Re: More info on sporadic OS/X crash

[John Wiegley]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Could you try the following patch?  It does saving/restoring the
> current graphics port and device handle when drawing into an
> offscreen graphics world.  Lack of this process might have led to an
> inconsistent state of a graphics port.

So far so good, I've been able to run a full day without a crash
(using multiple frames).  I will post if I run into it again.

John

Re: More info on sporadic OS/X crash

[John Wiegley]

YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp> writes:

> Could you try the following patch?  It does saving/restoring the
> current graphics port and device handle when drawing into an
> offscreen graphics world.  Lack of this process might have led to an
> inconsistent state of a graphics port.

I think your patch has done the trick.  I've not seen the crash in
several days, even though I'm playing with multiple frames again.

John