Emacs seems awfully unstable on OS X lately

Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

Do other OS X users experience stability problems on OS X with recent
builds from trunk?

I built an emacs from current trunk on September 6. It had a tendency
to get stuck in garbage collection and needing to be killed,
especially when I tried sending emails with large-ish attachments (on
the order of a megabyte or two).

So I built a new one yesterday. It is even more unstable, just
crashing randomly in the main event loop.

So for the time being, I have reverted to a version that I build in
late July, which seems stable enough.

I am not sure that I have enough data to send a meaningful bug report.
Are the OS provided crash logs useful? I have read somewhere that gdb
doesn't work with the output of the current crop of Apple's compilers,
so I haven't even tried using that.

I'll try to gather more information on these crashes if needed, but
then I could use some tips on how to do it. But if others are seeing
these crashes and are actively working on fixing them, I'll just wait.

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Ivan Andrus]

On Sep 14, 2012, at 9:25 AM, Harald Hanche-Olsen wrote:

> Do other OS X users experience stability problems on OS X with recent
> builds from trunk?

Yes.  I've been using the Mac Port for the past week or so because of it. I plan to run it under gdb and see if I can track it down, but I haven't had time yet.  I'm not sure when I will.  

> I built an emacs from current trunk on September 6. It had a tendency
> to get stuck in garbage collection and needing to be killed,
> especially when I tried sending emails with large-ish attachments (on
> the order of a megabyte or two).
> 
> So I built a new one yesterday. It is even more unstable, just
> crashing randomly in the main event loop.

I see that here too.

> So for the time being, I have reverted to a version that I build in
> late July, which seems stable enough.

If you can bisect that would probably be helpful.

> I am not sure that I have enough data to send a meaningful bug report.
> Are the OS provided crash logs useful? I have read somewhere that gdb
> doesn't work with the output of the current crop of Apple's compilers,
> so I haven't even tried using that.

I'm on 10.6, but gdb seems to work fine for me.

> I'll try to gather more information on these crashes if needed, but
> then I could use some tips on how to do it. But if others are seeing
> these crashes and are actively working on fixing them, I'll just wait.


I certainly wouldn't wait for me to fix it. :-)

-Ivan

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

[Ivan Andrus <darthandrus@gmail.com> (2012-09-14 08:37:49 UTC)]

> If you can bisect that would probably be helpful.

I'll work on it. It may take a while, though, since the gap between
the last known good revision and the first known bad revision is quite
large.

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Óscar Fuentes]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> [Ivan Andrus <darthandrus@gmail.com> (2012-09-14 08:37:49 UTC)]
>
>> If you can bisect that would probably be helpful.
>
> I'll work on it. It may take a while, though, since the gap between
> the last known good revision and the first known bad revision is quite
> large.

Bisecting across N revisions requires approximately ln N steps, so don't
be afraid of long lists of revisions :-)

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

[Óscar Fuentes <ofv@wanadoo.es> (2012-09-14 15:40:36 UTC)]

> Bisecting across N revisions requires approximately ln N steps, so don't
> be afraid of long lists of revisions :-)

I'm aware of the math (log with base 2 seems a better match than ln).
The problem is more the constant in front of the logarithm; i.e.,
since I am not too sure how much testing is required to accept a
certain revision as good, doing it about log 500 times still seems
like it could take a while.

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

After much bisecting, much slowed downn and somewhat complicated by a
whole range of revisions that didn't even build, I have identified the
culprit: It's a one line addition (!) revision 109470 of trunk.

I have further verified this by patching the current tip of trunk
(revision 110013) as follows, which undoes revision 109470.

=== modified file 'src/keyboard.c'
--- src/keyboard.c	2012-09-13 02:21:28 +0000
+++ src/keyboard.c	2012-09-14 19:12:15 +0000
@@ -4484,7 +4484,6 @@
 	    }
 
 	  nexttime = make_emacs_time (0, 0);
-          break;
 	}
       else
 	/* When we encounter a timer that is still waiting,


Without the patch, I see emacs freezing, using lots of CPU, and
sampling the process using Activity Monitor I get mark_object calls
nested "infinitely deep". Well, I don't know that, the saved sample
file is 74 MB big, and I just don't feel like analyzing it to bits.

My patch above is probably not TRT, but hopefully someone can figure
it out. Meanwhile, it's a workaround for Mac users.

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

Um, maybe I should file a bug report. Does it need any more info than
what is in my previous mail?

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

I have filed a bug report (#12447). As I suspected, there is a second
bug as well, causing emacs to crash (rather than hang) while waiting
for input. I'll try to track that one down next.

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

[Harald Hanche-Olsen <hanche@math.ntnu.no> (2012-09-14 21:15:49 UTC)]

> I have filed a bug report (#12447). As I suspected, there is a second
> bug as well, causing emacs to crash (rather than hang) while waiting
> for input. I'll try to track that one down next.

ACtually, I could a bit of help with that: Since I have a range of
more than 500 revisions to bisect, I think the most efficient
procedure would be to create a branch that is identical to trunk
except that revision 109470 is not applied, and then to bisect that.
But I don't understand bzr well enought to know how to do that. Can
someone tell me a good way to do it?

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Óscar Fuentes]

Harald Hanche-Olsen <hanche@math.ntnu.no> writes:

> ACtually, I could a bit of help with that: Since I have a range of
> more than 500 revisions to bisect, I think the most efficient
> procedure would be to create a branch that is identical to trunk
> except that revision 109470 is not applied, and then to bisect that.
> But I don't understand bzr well enought to know how to do that. Can
> someone tell me a good way to do it?

AFAIK there is no simple way of doing that. It is possible with
exporting/filtering/importing (which is quite time-demanding). It could
be done too by branching at revision 109469 and
then patching the working copy with 109471, committing, patching with
109472, committing... all done by a script, of course.

But IMO the easier way is to create a reverse patch for 109470, start
with the bisection as usual and, on each test, before building emacs,
apply the patch if the revision being tested comes after 109470, then
clean the working copy for undoing your patching and continue bisecting.

Re: Emacs seems awfully unstable on OS X lately

[Andreas Schwab]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
>
>> ACtually, I could a bit of help with that: Since I have a range of
>> more than 500 revisions to bisect, I think the most efficient
>> procedure would be to create a branch that is identical to trunk
>> except that revision 109470 is not applied, and then to bisect that.
>> But I don't understand bzr well enought to know how to do that. Can
>> someone tell me a good way to do it?
>
> AFAIK there is no simple way of doing that.

With git this is pretty trivial.  Before building each try, just run
"git revert" with the bad revision, and after testing use "git bisect
[good|bad] HEAD^".

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Emacs seems awfully unstable on OS X lately

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Sat, 15 Sep 2012 01:00:11 +0200
> 
> Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
> 
> > ACtually, I could a bit of help with that: Since I have a range of
> > more than 500 revisions to bisect, I think the most efficient
> > procedure would be to create a branch that is identical to trunk
> > except that revision 109470 is not applied, and then to bisect that.
> > But I don't understand bzr well enought to know how to do that. Can
> > someone tell me a good way to do it?
> 
> AFAIK there is no simple way of doing that.

Doesn't "bzr branch -r 109469" do the job?

Re: Emacs seems awfully unstable on OS X lately

[Stephen J. Turnbull]

Óscar Fuentes writes:

 > Harald Hanche-Olsen <hanche@math.ntnu.no> writes:
 > 
 > > ACtually, I could a bit of help with that: Since I have a range of
 > > more than 500 revisions to bisect, I think the most efficient
 > > procedure would be to create a branch that is identical to trunk
 > > except that revision 109470 is not applied, and then to bisect that.
 > > But I don't understand bzr well enought to know how to do that. Can
 > > someone tell me a good way to do it?
 > 
 > AFAIK there is no simple way of doing that.

Cherrypicking, like so:

bzr branch --revision=109469 trunk no-109470
cd no-109470
bzr merge --revision 109471..last:0 ../trunk

should do the trick.  There's no way to identify the merged revisions
with their upstream sources so you can never merge no-109470 back into
trunk normally (of course you can reverse cherrypick, but this gets
tedious right quick).  Just use no-109470 to identify the issue and
discard it as soon as possible.

See bzr help merge for a tiny bit more background on cherrypicking.

Steve

Re: Emacs seems awfully unstable on OS X lately

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Date: Sat, 15 Sep 2012 18:37:38 +0900
> Cc: Harald Hanche-Olsen <hanche@math.ntnu.no>, emacs-devel@gnu.org
> 
> bzr branch --revision=109469 trunk no-109470
> cd no-109470
> bzr merge --revision 109471..last:0 ../trunk
> 
> should do the trick.

Why is the second command necessary?  Are you assuming that the bug
was introduced after 109470?

My line of thought was: it's quite easy to establish whether the bug
is present in 109471, with 109470 reverse cherry-picked.  If it is
present, bisect the trunk where 109470 is removed; if it is not
present, bisect the branch created by the first command above.

Wouldn't that work, too?

Re: Emacs seems awfully unstable on OS X lately

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > Why is the second command necessary?  Are you assuming that the bug
 > was introduced after 109470?

No.  I'm simply allowing for the possibility that it was.
> 
 > My line of thought was: it's quite easy to establish whether the bug
 > is present in 109471, with 109470 reverse cherry-picked.  If it is
 > present, bisect the trunk where 109470 is removed;

How do you propose doing that?  It's not possible to remove a revision
from a branch.  You either do a rebase (what I proposed), or you have
to reapply the reverse cherrypick on each revision tested in the
bisection (as Óscar proposed) because the reverse cherrypick is always
the *tip*, it cannot be applied "in place".

Re: Emacs seems awfully unstable on OS X lately

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: ofv@wanadoo.es,
>     hanche@math.ntnu.no,
>     emacs-devel@gnu.org
> Date: Sat, 15 Sep 2012 22:46:22 +0900
> 
> Eli Zaretskii writes:
> 
>  > Why is the second command necessary?  Are you assuming that the bug
>  > was introduced after 109470?
> 
> No.  I'm simply allowing for the possibility that it was.
> > 
>  > My line of thought was: it's quite easy to establish whether the bug
>  > is present in 109471, with 109470 reverse cherry-picked.  If it is
>  > present, bisect the trunk where 109470 is removed;
> 
> How do you propose doing that?  It's not possible to remove a revision
> from a branch.

By a local commit after reverse cherry-picking, I guess.  Or will this
not work when bisect selects some revision before the commit?

Re: Emacs seems awfully unstable on OS X lately

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > By a local commit after reverse cherry-picking, I guess.  Or will
 > this not work when bisect selects some revision before the commit?

Exactly.  If you do it on *trunk*, because of the way revisions are
chained, a cherrypick commit must come *after* all the commits already
on trunk.  So reverting to a previous revision while bisecting also
reverts the cherrypick.

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

[Óscar Fuentes <ofv@wanadoo.es> (2012-09-14 23:00:11 UTC)]

> But IMO the easier way is to create a reverse patch for 109470, start
> with the bisection as usual and, on each test, before building emacs,
> apply the patch if the revision being tested comes after 109470, then
> clean the working copy for undoing your patching and continue bisecting.

Great suggestion. I'm going with that. Thanks.

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

Well, after a day of testing I am inclined to blame revision 109972
for the instability on OS X. At least, I get crashes with that
revision and later ones, and so far I haven't seen any crashes with
earlier revisions. I am running on revision 109971 now. I'll probably
have to use it for several hours before I can feel confident in this
conclusion, however.

Now I know nothing about Objective C, but the added code in nsterm.m
doesn't look to me like something that would cause crashes.

However that may be, I managed to provoke a crash with gdb attached,
but didn't get a useful backtrace; only this:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000011
0x00007fff8fc7ae90 in objc_msgSend ()
(gdb) back
#0  0x00007fff8fc7ae90 in objc_msgSend ()
#1  0x0000000000000000 in ?? ()

The backtrace supplied by the OS X crash reporter is a lot more
informative, I suppose. I supply it below.

- Harald


Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff89aa782a __kill + 10
1   org.gnu.Emacs                 	0x00000001000ad57e fatal_error_backtrace + 254 (emacs.c:332)
2   org.gnu.Emacs                 	0x00000001000ca6e3 emacs_abort + 19
3   org.gnu.Emacs                 	0x000000010019ca2d ns_term_shutdown + 125
4   org.gnu.Emacs                 	0x00000001000adbba shut_down_emacs + 250 (emacs.c:2066)
5   org.gnu.Emacs                 	0x00000001000ad531 fatal_error_backtrace + 177 (emacs.c:315)
6   org.gnu.Emacs                 	0x00000001000afc3e handle_fatal_signal + 14
7   org.gnu.Emacs                 	0x00000001000ca953 handle_on_main_thread + 131 (sysdep.c:1551)
8   libsystem_c.dylib             	0x00007fff90ebccfa _sigtramp + 26
9   libobjc.A.dylib               	0x00007fff8fc7ae90 objc_msgSend + 16
10  org.gnu.Emacs                 	0x000000010019a1d2 ns_update_begin + 146 (nsterm.m:644)
11  org.gnu.Emacs                 	0x000000010000ade5 update_frame + 213 (dispnew.c:3187)
12  org.gnu.Emacs                 	0x0000000100042668 redisplay_internal + 4696 (xdisp.c:13559)
13  org.gnu.Emacs                 	0x00000001000bd7da read_char + 8410 (keyboard.c:2496)
14  org.gnu.Emacs                 	0x00000001000c07d1 read_key_sequence + 7521
15  org.gnu.Emacs                 	0x00000001000c2278 command_loop_1 + 5192 (keyboard.c:1498)
16  org.gnu.Emacs                 	0x0000000100129226 internal_condition_case + 294 (eval.c:1320)
17  org.gnu.Emacs                 	0x00000001000c0e0e command_loop_2 + 62 (keyboard.c:1194)
18  org.gnu.Emacs                 	0x000000010012932b internal_catch + 219 (eval.c:1076)
19  org.gnu.Emacs                 	0x00000001000c28cd recursive_edit_1 + 301 (keyboard.c:1158)
20  org.gnu.Emacs                 	0x00000001000e09da read_minibuf + 2346 (minibuf.c:686)
21  org.gnu.Emacs                 	0x00000001000dde65 Fread_from_minibuffer + 245 (minibuf.c:988)
22  org.gnu.Emacs                 	0x00000001000ddfce Fread_string + 110 (minibuf.c:1053)
23  org.gnu.Emacs                 	0x00000001001277c7 Ffuncall + 1047 (eval.c:2825)
24  org.gnu.Emacs                 	0x000000010015ff08 exec_byte_code + 1992 (bytecode.c:898)
25  org.gnu.Emacs                 	0x000000010012aa62 funcall_lambda + 930 (eval.c:3041)
26  org.gnu.Emacs                 	0x0000000100127857 Ffuncall + 1191 (eval.c:2858)
27  org.gnu.Emacs                 	0x0000000100124854 Fcall_interactively + 6004 (callint.c:853)
28  org.gnu.Emacs                 	0x0000000100127793 Ffuncall + 995 (eval.c:2816)
29  org.gnu.Emacs                 	0x000000010012abe6 call3 + 38 (eval.c:2634)
30  org.gnu.Emacs                 	0x00000001000c1475 command_loop_1 + 1605 (keyboard.c:1634)
31  org.gnu.Emacs                 	0x0000000100129226 internal_condition_case + 294 (eval.c:1320)
32  org.gnu.Emacs                 	0x00000001000c0e0e command_loop_2 + 62 (keyboard.c:1194)
33  org.gnu.Emacs                 	0x000000010012932b internal_catch + 219 (eval.c:1076)
34  org.gnu.Emacs                 	0x00000001000c2890 recursive_edit_1 + 240 (keyboard.c:1173)
35  org.gnu.Emacs                 	0x00000001000b2e9d Frecursive_edit + 237 (keyboard.c:857)
36  org.gnu.Emacs                 	0x00000001000afb8c main + 6316 (emacs.c:1660)
37  org.gnu.Emacs                 	0x00000001000018a4 start + 52

Re: Emacs seems awfully unstable on OS X lately

[Jan Djärv]

Hello.

16 sep 2012 kl. 02:47 skrev Harald Hanche-Olsen <hanche@math.ntnu.no>:

> Well, after a day of testing I am inclined to blame revision 109972
> for the instability on OS X. At least, I get crashes with that
> revision and later ones, and so far I haven't seen any crashes with
> earlier revisions. I am running on revision 109971 now. I'll probably
> have to use it for several hours before I can feel confident in this
> conclusion, however.
> 

I see craches also, but haven't been able to reproduce it when running with gdb.

> Now I know nothing about Objective C, but the added code in nsterm.m
> doesn't look to me like something that would cause crashes.
> 
> However that may be, I managed to provoke a crash with gdb attached,
> but didn't get a useful backtrace; only this:
> 
> Program received signal EXC_BAD_ACCESS, Could not access memory.
> Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000011
> 0x00007fff8fc7ae90 in objc_msgSend ()
> (gdb) back
> #0  0x00007fff8fc7ae90 in objc_msgSend ()
> #1  0x0000000000000000 in ?? ()
> 

This usually means that an object was freed and after that someone tried to send it a signal (i.e. method call).

> The backtrace supplied by the OS X crash reporter is a lot more
> informative, I suppose. I supply it below.
> 

Actually it is informative, the memory isn't handeled right in this case. I'll figure out a solution and check in a fix.

Thanks,

	Jan D.

> - Harald
> 
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib        	0x00007fff89aa782a __kill + 10
> 1   org.gnu.Emacs                 	0x00000001000ad57e fatal_error_backtrace + 254 (emacs.c:332)
> 2   org.gnu.Emacs                 	0x00000001000ca6e3 emacs_abort + 19
> 3   org.gnu.Emacs                 	0x000000010019ca2d ns_term_shutdown + 125
> 4   org.gnu.Emacs                 	0x00000001000adbba shut_down_emacs + 250 (emacs.c:2066)
> 5   org.gnu.Emacs                 	0x00000001000ad531 fatal_error_backtrace + 177 (emacs.c:315)
> 6   org.gnu.Emacs                 	0x00000001000afc3e handle_fatal_signal + 14
> 7   org.gnu.Emacs                 	0x00000001000ca953 handle_on_main_thread + 131 (sysdep.c:1551)
> 8   libsystem_c.dylib             	0x00007fff90ebccfa _sigtramp + 26
> 9   libobjc.A.dylib               	0x00007fff8fc7ae90 objc_msgSend + 16
> 10  org.gnu.Emacs                 	0x000000010019a1d2 ns_update_begin + 146 (nsterm.m:644)
> 11  org.gnu.Emacs                 	0x000000010000ade5 update_frame + 213 (dispnew.c:3187)
> 12  org.gnu.Emacs                 	0x0000000100042668 redisplay_internal + 4696 (xdisp.c:13559)
> 13  org.gnu.Emacs                 	0x00000001000bd7da read_char + 8410 (keyboard.c:2496)
> 14  org.gnu.Emacs                 	0x00000001000c07d1 read_key_sequence + 7521
> 15  org.gnu.Emacs                 	0x00000001000c2278 command_loop_1 + 5192 (keyboard.c:1498)
> 16  org.gnu.Emacs                 	0x0000000100129226 internal_condition_case + 294 (eval.c:1320)
> 17  org.gnu.Emacs                 	0x00000001000c0e0e command_loop_2 + 62 (keyboard.c:1194)
> 18  org.gnu.Emacs                 	0x000000010012932b internal_catch + 219 (eval.c:1076)
> 19  org.gnu.Emacs                 	0x00000001000c28cd recursive_edit_1 + 301 (keyboard.c:1158)
> 20  org.gnu.Emacs                 	0x00000001000e09da read_minibuf + 2346 (minibuf.c:686)
> 21  org.gnu.Emacs                 	0x00000001000dde65 Fread_from_minibuffer + 245 (minibuf.c:988)
> 22  org.gnu.Emacs                 	0x00000001000ddfce Fread_string + 110 (minibuf.c:1053)
> 23  org.gnu.Emacs                 	0x00000001001277c7 Ffuncall + 1047 (eval.c:2825)
> 24  org.gnu.Emacs                 	0x000000010015ff08 exec_byte_code + 1992 (bytecode.c:898)
> 25  org.gnu.Emacs                 	0x000000010012aa62 funcall_lambda + 930 (eval.c:3041)
> 26  org.gnu.Emacs                 	0x0000000100127857 Ffuncall + 1191 (eval.c:2858)
> 27  org.gnu.Emacs                 	0x0000000100124854 Fcall_interactively + 6004 (callint.c:853)
> 28  org.gnu.Emacs                 	0x0000000100127793 Ffuncall + 995 (eval.c:2816)
> 29  org.gnu.Emacs                 	0x000000010012abe6 call3 + 38 (eval.c:2634)
> 30  org.gnu.Emacs                 	0x00000001000c1475 command_loop_1 + 1605 (keyboard.c:1634)
> 31  org.gnu.Emacs                 	0x0000000100129226 internal_condition_case + 294 (eval.c:1320)
> 32  org.gnu.Emacs                 	0x00000001000c0e0e command_loop_2 + 62 (keyboard.c:1194)
> 33  org.gnu.Emacs                 	0x000000010012932b internal_catch + 219 (eval.c:1076)
> 34  org.gnu.Emacs                 	0x00000001000c2890 recursive_edit_1 + 240 (keyboard.c:1173)
> 35  org.gnu.Emacs                 	0x00000001000b2e9d Frecursive_edit + 237 (keyboard.c:857)
> 36  org.gnu.Emacs                 	0x00000001000afb8c main + 6316 (emacs.c:1660)
> 37  org.gnu.Emacs                 	0x00000001000018a4 start + 52

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

[Jan Djärv <jan.h.d@swipnet.se> (2012-09-16 08:04:03 UTC)]

> Actually it is informative, the memory isn't handeled right in this case. I'll figure out a solution and check in a fix.

I checked out this one and tried it:

110045: Jan D. 2012-09-16 Try to fix crashes introduced by rev 109972.

Unfortunately, I managed to crash it within a few minutes of launch, so it seems that another attempt is required.

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Jan Djärv]

16 sep 2012 kl. 15:15 skrev Harald Hanche-Olsen <hanche@math.ntnu.no>:

> [Jan Djärv <jan.h.d@swipnet.se> (2012-09-16 08:04:03 UTC)]
> 
>> Actually it is informative, the memory isn't handeled right in this case. I'll figure out a solution and check in a fix.
> 
> I checked out this one and tried it:
> 
> 110045: Jan D. 2012-09-16 Try to fix crashes introduced by rev 109972.
> 
> Unfortunately, I managed to crash it within a few minutes of launch, so it seems that another attempt is required.

Hmm, did you get any sort of backtrace?

	Jan D.

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

[Jan Djärv <jan.h.d@swipnet.se> (2012-09-16 15:21:10 UTC)]

> 
> 16 sep 2012 kl. 15:15 skrev Harald Hanche-Olsen <hanche@math.ntnu.no>:
> 
> > Unfortunately, I managed to crash it within a few minutes of
> launch, so it seems that another attempt is required.
> 
> Hmm, did you get any sort of backtrace?

Yeah. Sorry about that, I should have included it, especially as it
was somewhat different from earlier ones. This one happened in GC:

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BAD_ACCESS (SIGABRT)
Exception Codes: 0x000000000000000d, 0x0000000000000000

VM Regions Near 0:
--> 
    __TEXT                 0000000100000000-0000000100207000 [ 2076K] r-x/rwx SM=COW  /Applications/Emacs.app/Contents/MacOS/Emacs

Application Specific Information:
objc[47805]: garbage collection is OFF

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff89aa782a __kill + 10
1   org.gnu.Emacs                 	0x00000001000ad45e fatal_error_backtrace + 254 (emacs.c:331)
2   org.gnu.Emacs                 	0x00000001000ca513 emacs_abort + 19
3   org.gnu.Emacs                 	0x000000010019c92d ns_term_shutdown + 125
4   org.gnu.Emacs                 	0x00000001000ada90 shut_down_emacs + 240 (emacs.c:2063)
5   org.gnu.Emacs                 	0x00000001000ad411 fatal_error_backtrace + 177 (emacs.c:314)
6   org.gnu.Emacs                 	0x00000001000afb0e handle_fatal_signal + 14
7   org.gnu.Emacs                 	0x00000001000ca783 handle_on_main_thread + 131 (sysdep.c:1501)
8   libsystem_c.dylib             	0x00007fff90ebccfa _sigtramp + 26
9   org.gnu.Emacs                 	0x0000000100109a29 mark_object + 1657 (alloc.c:6202)
10  org.gnu.Emacs                 	0x00000001001097b8 mark_object + 1032 (alloc.c:5800)
11  org.gnu.Emacs                 	0x00000001001097b8 mark_object + 1032 (alloc.c:5800)
12  org.gnu.Emacs                 	0x0000000100109a63 mark_object + 1715 (alloc.c:6215)
13  org.gnu.Emacs                 	0x000000010010e3eb Fgarbage_collect + 475 (alloc.c:5486)
14  org.gnu.Emacs                 	0x00000001001273de Ffuncall + 382 (lisp.h:3646)
15  org.gnu.Emacs                 	0x000000010015fdc8 exec_byte_code + 1992 (bytecode.c:898)
16  org.gnu.Emacs                 	0x000000010012a912 funcall_lambda + 930 (eval.c:3038)
17  org.gnu.Emacs                 	0x0000000100127707 Ffuncall + 1191 (eval.c:2855)
18  org.gnu.Emacs                 	0x000000010015fdc8 exec_byte_code + 1992 (bytecode.c:898)
19  org.gnu.Emacs                 	0x000000010012a912 funcall_lambda + 930 (eval.c:3038)
20  org.gnu.Emacs                 	0x0000000100127707 Ffuncall + 1191 (eval.c:2855)
21  org.gnu.Emacs                 	0x000000010015fdc8 exec_byte_code + 1992 (bytecode.c:898)
22  org.gnu.Emacs                 	0x000000010012a912 funcall_lambda + 930 (eval.c:3038)
23  org.gnu.Emacs                 	0x0000000100127707 Ffuncall + 1191 (eval.c:2855)
24  org.gnu.Emacs                 	0x000000010015fdc8 exec_byte_code + 1992 (bytecode.c:898)
25  org.gnu.Emacs                 	0x000000010012a912 funcall_lambda + 930 (eval.c:3038)
26  org.gnu.Emacs                 	0x0000000100127707 Ffuncall + 1191 (eval.c:2855)
27  org.gnu.Emacs                 	0x000000010015fdc8 exec_byte_code + 1992 (bytecode.c:898)
28  org.gnu.Emacs                 	0x000000010012a912 funcall_lambda + 930 (eval.c:3038)
29  org.gnu.Emacs                 	0x0000000100127707 Ffuncall + 1191 (eval.c:2855)
30  org.gnu.Emacs                 	0x00000001001246e4 Fcall_interactively + 6004 (callint.c:852)
31  org.gnu.Emacs                 	0x0000000100127643 Ffuncall + 995 (eval.c:2813)
32  org.gnu.Emacs                 	0x000000010012aa96 call3 + 38 (eval.c:2631)
33  org.gnu.Emacs                 	0x00000001000c12a5 command_loop_1 + 1605 (keyboard.c:1625)
34  org.gnu.Emacs                 	0x00000001001290d6 internal_condition_case + 294 (eval.c:1316)
35  org.gnu.Emacs                 	0x00000001000c0c3e command_loop_2 + 62 (keyboard.c:1185)
36  org.gnu.Emacs                 	0x00000001001291d2 internal_catch + 210 (eval.c:1075)
37  org.gnu.Emacs                 	0x00000001000c26c0 recursive_edit_1 + 240 (keyboard.c:1164)
38  org.gnu.Emacs                 	0x00000001000b2d4d Frecursive_edit + 237 (keyboard.c:848)
39  org.gnu.Emacs                 	0x00000001000afa5c main + 6316 (emacs.c:1659)
40  org.gnu.Emacs                 	0x0000000100001824 start + 52

I'm afraid I didn't have gdb attached.

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Jan Djärv]

Hello.


16 sep 2012 kl. 17:47 skrev Harald Hanche-Olsen <hanche@math.ntnu.no>:

> [Jan Djärv <jan.h.d@swipnet.se> (2012-09-16 15:21:10 UTC)]
> 
>> 
>> 16 sep 2012 kl. 15:15 skrev Harald Hanche-Olsen <hanche@math.ntnu.no>:
>> 
>>> Unfortunately, I managed to crash it within a few minutes of
>> launch, so it seems that another attempt is required.
>> 
>> Hmm, did you get any sort of backtrace?
> 
> Yeah. Sorry about that, I should have included it, especially as it
> was somewhat different from earlier ones. This one happened in GC:

Ah, then it is not related to the first one you sent.  It might me related to the one discussed in bug 12447.

	Jan D.

> 
> Crashed Thread:  0  Dispatch queue: com.apple.main-thread
> 
> Exception Type:  EXC_BAD_ACCESS (SIGABRT)
> Exception Codes: 0x000000000000000d, 0x0000000000000000
> 
> VM Regions Near 0:
> --> 
>    __TEXT                 0000000100000000-0000000100207000 [ 2076K] r-x/rwx SM=COW  /Applications/Emacs.app/Contents/MacOS/Emacs
> 
> Application Specific Information:
> objc[47805]: garbage collection is OFF
> 
> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
> 0   libsystem_kernel.dylib        	0x00007fff89aa782a __kill + 10
> 1   org.gnu.Emacs                 	0x00000001000ad45e fatal_error_backtrace + 254 (emacs.c:331)
> 2   org.gnu.Emacs                 	0x00000001000ca513 emacs_abort + 19
> 3   org.gnu.Emacs                 	0x000000010019c92d ns_term_shutdown + 125
> 4   org.gnu.Emacs                 	0x00000001000ada90 shut_down_emacs + 240 (emacs.c:2063)
> 5   org.gnu.Emacs                 	0x00000001000ad411 fatal_error_backtrace + 177 (emacs.c:314)
> 6   org.gnu.Emacs                 	0x00000001000afb0e handle_fatal_signal + 14
> 7   org.gnu.Emacs                 	0x00000001000ca783 handle_on_main_thread + 131 (sysdep.c:1501)
> 8   libsystem_c.dylib             	0x00007fff90ebccfa _sigtramp + 26
> 9   org.gnu.Emacs                 	0x0000000100109a29 mark_object + 1657 (alloc.c:6202)
> 10  org.gnu.Emacs                 	0x00000001001097b8 mark_object + 1032 (alloc.c:5800)
> 11  org.gnu.Emacs                 	0x00000001001097b8 mark_object + 1032 (alloc.c:5800)
> 12  org.gnu.Emacs                 	0x0000000100109a63 mark_object + 1715 (alloc.c:6215)
> 13  org.gnu.Emacs                 	0x000000010010e3eb Fgarbage_collect + 475 (alloc.c:5486)
> 14  org.gnu.Emacs                 	0x00000001001273de Ffuncall + 382 (lisp.h:3646)
> 15  org.gnu.Emacs                 	0x000000010015fdc8 exec_byte_code + 1992 (bytecode.c:898)
> 16  org.gnu.Emacs                 	0x000000010012a912 funcall_lambda + 930 (eval.c:3038)
> 17  org.gnu.Emacs                 	0x0000000100127707 Ffuncall + 1191 (eval.c:2855)
> 18  org.gnu.Emacs                 	0x000000010015fdc8 exec_byte_code + 1992 (bytecode.c:898)
> 19  org.gnu.Emacs                 	0x000000010012a912 funcall_lambda + 930 (eval.c:3038)
> 20  org.gnu.Emacs                 	0x0000000100127707 Ffuncall + 1191 (eval.c:2855)
> 21  org.gnu.Emacs                 	0x000000010015fdc8 exec_byte_code + 1992 (bytecode.c:898)
> 22  org.gnu.Emacs                 	0x000000010012a912 funcall_lambda + 930 (eval.c:3038)
> 23  org.gnu.Emacs                 	0x0000000100127707 Ffuncall + 1191 (eval.c:2855)
> 24  org.gnu.Emacs                 	0x000000010015fdc8 exec_byte_code + 1992 (bytecode.c:898)
> 25  org.gnu.Emacs                 	0x000000010012a912 funcall_lambda + 930 (eval.c:3038)
> 26  org.gnu.Emacs                 	0x0000000100127707 Ffuncall + 1191 (eval.c:2855)
> 27  org.gnu.Emacs                 	0x000000010015fdc8 exec_byte_code + 1992 (bytecode.c:898)
> 28  org.gnu.Emacs                 	0x000000010012a912 funcall_lambda + 930 (eval.c:3038)
> 29  org.gnu.Emacs                 	0x0000000100127707 Ffuncall + 1191 (eval.c:2855)
> 30  org.gnu.Emacs                 	0x00000001001246e4 Fcall_interactively + 6004 (callint.c:852)
> 31  org.gnu.Emacs                 	0x0000000100127643 Ffuncall + 995 (eval.c:2813)
> 32  org.gnu.Emacs                 	0x000000010012aa96 call3 + 38 (eval.c:2631)
> 33  org.gnu.Emacs                 	0x00000001000c12a5 command_loop_1 + 1605 (keyboard.c:1625)
> 34  org.gnu.Emacs                 	0x00000001001290d6 internal_condition_case + 294 (eval.c:1316)
> 35  org.gnu.Emacs                 	0x00000001000c0c3e command_loop_2 + 62 (keyboard.c:1185)
> 36  org.gnu.Emacs                 	0x00000001001291d2 internal_catch + 210 (eval.c:1075)
> 37  org.gnu.Emacs                 	0x00000001000c26c0 recursive_edit_1 + 240 (keyboard.c:1164)
> 38  org.gnu.Emacs                 	0x00000001000b2d4d Frecursive_edit + 237 (keyboard.c:848)
> 39  org.gnu.Emacs                 	0x00000001000afa5c main + 6316 (emacs.c:1659)
> 40  org.gnu.Emacs                 	0x0000000100001824 start + 52
> 
> I'm afraid I didn't have gdb attached.
> 
> - Harald

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

[Jan Djärv <jan.h.d@swipnet.se> (2012-09-16 18:27:34 UTC)]

> Ah, then it is not related to the first one you sent.  It might me 
> related to the one discussed in bug 12447.

That could be. I'll continue to use 110045 and see if I get more 
crashes, then. I should perhaps have mentioned that I built 110045 
after backing out of 109470. (That revision, though I am fairly 
convinced it does not cause the problem in bug 12447, certainly seems 
to tickle it much more often.)

- Harald

Re: Emacs seems awfully unstable on OS X lately

[Harald Hanche-Olsen]

This message is just for the benefit of lurkers and readers of the
mail archive: The stability problems described in this thread appear
to be solved by trunk revision 110138, closing bug#12447.

- Harald