* bug#18501: 24.3.93; OS X; crash in free() when calling macfont_close()
@ 2014-09-17 23:38 Jim Radford
[not found] ` <handler.18501.B.141107709331502.ack@debbugs.gnu.org>
0 siblings, 1 reply; 14+ messages in thread
From: Jim Radford @ 2014-09-17 23:38 UTC (permalink / raw)
To: 18501
I often see Emacs use 100% of my CPU after closing emacsclient-opened
windows. Here's a backtrace when I connect to the looping process.
* thread #1: tid = 0x149297, 0x0000000100142d8b Emacs`hash_lookup [inlined] AREF(array=4391639061) at lisp.h:1356, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x30ecf2338)
* frame #0: 0x0000000100142d8b Emacs`hash_lookup [inlined] AREF(array=4391639061) at lisp.h:1356
frame #1: 0x0000000100142d8b Emacs`hash_lookup [inlined] HASH_INDEX(h=0x0000000101818990) at lisp.h:1844
frame #2: 0x0000000100142d8b Emacs`hash_lookup(h=0x0000000101818990, key=4370859418, hash=<unavailable>) + 59 at fns.c:3807
frame #3: 0x00000001000874f2 Emacs`code_convert_string(string=140734799784416, coding_system=4370859418, dst_object=4320145514, encodep=false, nocopy=<unavailable>, norecord=true) + 194 at coding.c:9450
frame #4: 0x00000001000ecf8e Emacs`Fexpand_file_name(name=<unavailable>, default_directory=<unavailable>) + 878 at fileio.c:1176
frame #5: 0x00000001000eccfe Emacs`Fexpand_file_name(name=4319204161, default_directory=<unavailable>) + 222 at fileio.c:981
frame #6: 0x00000001000f3e7e Emacs`Fdo_auto_save(no_message=<unavailable>, current_only=4320145466) + 286 at fileio.c:5560
frame #7: 0x00000001000b789f Emacs`shut_down_emacs(sig=6, stuff=4320145466) + 239 at emacs.c:2026
frame #8: 0x00000001000b7699 Emacs`terminate_due_to_signal(sig=6, backtrace_limit=40) + 89 at emacs.c:362
frame #9: 0x00000001000d6436 Emacs`deliver_fatal_thread_signal [inlined] handle_fatal_signal(sig=6) + 134 at sysdep.c:1630
frame #10: 0x00000001000d642f Emacs`deliver_fatal_thread_signal [inlined] deliver_thread_signal + 119 at sysdep.c:1604
frame #11: 0x00000001000d63b8 Emacs`deliver_fatal_thread_signal(sig=<unavailable>) + 8 at sysdep.c:1642
frame #12: 0x00007fff8d11a5aa libsystem_platform.dylib`_sigtramp + 26
frame #13: 0x00007fff8bb1c867 libsystem_kernel.dylib`__pthread_kill + 11
frame #14: 0x00007fff90cbeb1a libsystem_c.dylib`abort + 125
frame #15: 0x00007fff90b0f07f libsystem_malloc.dylib`free + 411
frame #16: 0x00000001001c6108 Emacs`macfont_close(font=<unavailable>) + 280 at macfont.m:2631
frame #17: 0x000000010011be9d Emacs`Fgarbage_collect [inlined] cleanup_vector + 38 at alloc.c:2935
frame #18: 0x000000010011be77 Emacs`Fgarbage_collect [inlined] sweep_vectors + 572 at alloc.c:2986
frame #19: 0x000000010011bc3b Emacs`Fgarbage_collect [inlined] gc_sweep + 239 at alloc.c:6721
frame #20: 0x000000010011bb4c Emacs`Fgarbage_collect + 6172 at alloc.c:5650
frame #21: 0x0000000100170c1a Emacs`exec_byte_code [inlined] maybe_gc + 1338 at lisp.h:4564
In GNU Emacs 24.3.93.1 (x86_64-apple-darwin13.3.0, NS apple-appkit-1265.21)
Configured using:
`configure --with-ns'
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
[not found] ` <handler.18501.B.141107709331502.ack@debbugs.gnu.org>
@ 2014-09-18 22:14 ` Jim Radford
2014-09-19 17:05 ` Jim Radford
2014-09-19 18:05 ` Jim Radford
2 siblings, 0 replies; 14+ messages in thread
From: Jim Radford @ 2014-09-18 22:14 UTC (permalink / raw)
To: 18501
After investigating this a bit more it seems that the hash_lookup()
segfaults because its gcmarkbit is on due the segfault in
macfont_close() happening while garbage collecting.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
[not found] ` <handler.18501.B.141107709331502.ack@debbugs.gnu.org>
2014-09-18 22:14 ` bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close()) Jim Radford
@ 2014-09-19 17:05 ` Jim Radford
2014-09-19 18:05 ` Jim Radford
2 siblings, 0 replies; 14+ messages in thread
From: Jim Radford @ 2014-09-19 17:05 UTC (permalink / raw)
To: 18501
Here's how to reproduce this crash (no ~/.emacs nor ~/.emacs.d).
/Applications/Emacs.app/Contents/MacOS/Emacs --daemon
/Applications/Emacs.app/Contents/MacOS/bin/emacsclient -c
C-x C-c
/Applications/Emacs.app/Contents/MacOS/bin/emacsclient -c
[ Sometimes it crashes here ]
C-x C-c
/Applications/Emacs.app/Contents/MacOS/bin/emacsclient -c
[ Sometimes it crashes here ]
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
[not found] ` <handler.18501.B.141107709331502.ack@debbugs.gnu.org>
2014-09-18 22:14 ` bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close()) Jim Radford
2014-09-19 17:05 ` Jim Radford
@ 2014-09-19 18:05 ` Jim Radford
2014-09-20 1:08 ` Dmitry Antipov
2 siblings, 1 reply; 14+ messages in thread
From: Jim Radford @ 2014-09-19 18:05 UTC (permalink / raw)
To: 18501
Here are the two calls that free the font:
frame #1: 0x00000001001c5ffd Emacs`macfont_close(font=0x0000000105c2a8c0) + 13 at macfont.m:2621
frame #2: 0x000000010014de80 Emacs`font_clear_cache(f=<unavailable>, cache=<unavailable>, driver=<unavailable>) + 304 at font.c:2620
frame #1: 0x00000001001c5ffd Emacs`macfont_close(font=0x0000000105c2a8c0) + 13 at macfont.m:2621
frame #2: 0x000000010011be9d Emacs`Fgarbage_collect [inlined] cleanup_vector + 38 at alloc.c:2935
Notice that the pointer is the same in both cases. Both cleanup_vector() and font_clear_cache() call
drv->close(font)
It seems that font_clear_cache is leaving the font around for the GC to clean up (a second time) later.
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
2014-09-19 18:05 ` Jim Radford
@ 2014-09-20 1:08 ` Dmitry Antipov
2014-09-20 22:08 ` Jim Radford
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Dmitry Antipov @ 2014-09-20 1:08 UTC (permalink / raw)
To: Jim Radford; +Cc: 18501
[-- Attachment #1: Type: text/plain, Size: 814 bytes --]
On 09/19/2014 10:05 PM, Jim Radford wrote:
> Here are the two calls that free the font:
>
> frame #1: 0x00000001001c5ffd Emacs`macfont_close(font=0x0000000105c2a8c0) + 13 at macfont.m:2621
> frame #2: 0x000000010014de80 Emacs`font_clear_cache(f=<unavailable>, cache=<unavailable>, driver=<unavailable>) + 304 at font.c:2620
>
> frame #1: 0x00000001001c5ffd Emacs`macfont_close(font=0x0000000105c2a8c0) + 13 at macfont.m:2621
> frame #2: 0x000000010011be9d Emacs`Fgarbage_collect [inlined] cleanup_vector + 38 at alloc.c:2935
>
> Notice that the pointer is the same in both cases. Both cleanup_vector() and font_clear_cache() call
>
> drv->close(font)
>
> It seems that font_clear_cache is leaving the font around for the GC to clean up (a second time) later.
Please try this.
Dmitry
[-- Attachment #2: bug18501.patch --]
[-- Type: text/x-diff, Size: 1278 bytes --]
=== modified file 'src/macfont.m'
--- src/macfont.m 2014-07-20 13:18:47 +0000
+++ src/macfont.m 2014-09-20 01:05:58 +0000
@@ -2616,20 +2616,25 @@
macfont_close (struct font *font)
{
struct macfont_info *macfont_info = (struct macfont_info *) font;
- int i;
-
- block_input ();
- CFRelease (macfont_info->macfont);
- CGFontRelease (macfont_info->cgfont);
- if (macfont_info->screen_font)
- CFRelease (macfont_info->screen_font);
- macfont_release_cache (macfont_info->cache);
- for (i = 0; i < macfont_info->metrics_nrows; i++)
- if (macfont_info->metrics[i])
- xfree (macfont_info->metrics[i]);
- if (macfont_info->metrics)
- xfree (macfont_info->metrics);
- unblock_input ();
+
+ if (macfont_info->cache)
+ {
+ int i;
+
+ block_input ();
+ CFRelease (macfont_info->macfont);
+ CGFontRelease (macfont_info->cgfont);
+ if (macfont_info->screen_font)
+ CFRelease (macfont_info->screen_font);
+ macfont_release_cache (macfont_info->cache);
+ for (i = 0; i < macfont_info->metrics_nrows; i++)
+ if (macfont_info->metrics[i])
+ xfree (macfont_info->metrics[i]);
+ if (macfont_info->metrics)
+ xfree (macfont_info->metrics);
+ macfont_info->cache = NULL;
+ unblock_input ();
+ }
}
static int
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
2014-09-20 1:08 ` Dmitry Antipov
@ 2014-09-20 22:08 ` Jim Radford
2014-09-21 5:03 ` Dmitry Antipov
2014-09-22 9:52 ` YAMAMOTO Mitsuharu
2016-05-25 20:38 ` Alan Third
2 siblings, 1 reply; 14+ messages in thread
From: Jim Radford @ 2014-09-20 22:08 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: 18501
Hi Dmitry,
Thanks for the patch! It fixes the problem for me.
I'm curious, why not just let the GC clean up the fonts in all cases?
Wouldn't they then also stay cached across frame-create /
frame-delete?
-Jim
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
2014-09-20 22:08 ` Jim Radford
@ 2014-09-21 5:03 ` Dmitry Antipov
2014-09-21 16:58 ` Jim Radford
0 siblings, 1 reply; 14+ messages in thread
From: Dmitry Antipov @ 2014-09-21 5:03 UTC (permalink / raw)
To: Jim Radford; +Cc: 18501
On 09/21/2014 02:08 AM, Jim Radford wrote:
> I'm curious, why not just let the GC clean up the fonts in all cases?
This should be possible, but probably requires a substantial rewrite
of font.c and type-specific font drivers (xfont.c, w32font.c, etc).
Initially font cleanup at GC was introduced as a workaround for some
flaws in current font management subsystem. See
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00740.html
> Wouldn't they then also stay cached across frame-create /
> frame-delete?
This should be possible too, but it's hard to say whether it's really
worth doing. I just don't see a usage pattern where frames are created
and deleted often enough so any caching makes sense.
Dmitry
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
2014-09-21 5:03 ` Dmitry Antipov
@ 2014-09-21 16:58 ` Jim Radford
0 siblings, 0 replies; 14+ messages in thread
From: Jim Radford @ 2014-09-21 16:58 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: 18501
On Sun, Sep 21, 2014 at 09:03:55AM +0400, Dmitry Antipov wrote:
> This should be possible too, but it's hard to say whether it's really
> worth doing. I just don't see a usage pattern where frames are created
> and deleted often enough so any caching makes sense.
FWIW, my personal usage pattern does this which is why I've run into
this bug consistently for a while now. I use emacsclient with lots of
tty frames, but by EDITOR is set to plain emacsclient so I frequently
pop up frames which then get closed almost immediately.
Thanks again for the patch,
-Jim
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
2014-09-20 1:08 ` Dmitry Antipov
2014-09-20 22:08 ` Jim Radford
@ 2014-09-22 9:52 ` YAMAMOTO Mitsuharu
2014-09-22 11:01 ` Dmitry Antipov
2016-05-25 20:38 ` Alan Third
2 siblings, 1 reply; 14+ messages in thread
From: YAMAMOTO Mitsuharu @ 2014-09-22 9:52 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Jim Radford, 18501
>>>>> On Sat, 20 Sep 2014 05:08:15 +0400, Dmitry Antipov <dmantipov@yandex.ru> said:
> On 09/19/2014 10:05 PM, Jim Radford wrote:
>> Here are the two calls that free the font:
>>
>> frame #1: 0x00000001001c5ffd Emacs`macfont_close(font=0x0000000105c2a8c0) + 13 at macfont.m:2621
>> frame #2: 0x000000010014de80 Emacs`font_clear_cache(f=<unavailable>, cache=<unavailable>, driver=<unavailable>) + 304 at font.c:2620
>>
>> frame #1: 0x00000001001c5ffd Emacs`macfont_close(font=0x0000000105c2a8c0) + 13 at macfont.m:2621
>> frame #2: 0x000000010011be9d Emacs`Fgarbage_collect [inlined] cleanup_vector + 38 at alloc.c:2935
>>
>> Notice that the pointer is the same in both cases. Both cleanup_vector() and font_clear_cache() call
>>
drv-> close(font)
>>
>> It seems that font_clear_cache is leaving the font around for the GC to clean up (a second time) later.
> Please try this.
Does this mean each font backend driver should prepare for multiple
"close" calls for a single font object? Or is this something specific
to OS X?
YAMAMOTO Mitsuharu
mituharu@math.s.chiba-u.ac.jp
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
2014-09-22 9:52 ` YAMAMOTO Mitsuharu
@ 2014-09-22 11:01 ` Dmitry Antipov
0 siblings, 0 replies; 14+ messages in thread
From: Dmitry Antipov @ 2014-09-22 11:01 UTC (permalink / raw)
To: YAMAMOTO Mitsuharu; +Cc: Jim Radford, 18501
On 09/22/2014 01:52 PM, YAMAMOTO Mitsuharu wrote:
> Does this mean each font backend driver should prepare for multiple
> "close" calls for a single font object?
Yes. I don't like this too much, but I don't see how to avoid an issue from
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00740.html without
an attempt to finalize font object when it's collected.
Dmitry
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
2014-09-20 1:08 ` Dmitry Antipov
2014-09-20 22:08 ` Jim Radford
2014-09-22 9:52 ` YAMAMOTO Mitsuharu
@ 2016-05-25 20:38 ` Alan Third
2016-05-27 9:29 ` Eli Zaretskii
2 siblings, 1 reply; 14+ messages in thread
From: Alan Third @ 2016-05-25 20:38 UTC (permalink / raw)
To: Dmitry Antipov; +Cc: Jim Radford, 18501
Dmitry Antipov <dmantipov@yandex.ru> writes:
> On 09/19/2014 10:05 PM, Jim Radford wrote:
>
>> Here are the two calls that free the font:
>>
>> frame #1: 0x00000001001c5ffd Emacs`macfont_close(font=0x0000000105c2a8c0) + 13 at macfont.m:2621
>> frame #2: 0x000000010014de80 Emacs`font_clear_cache(f=<unavailable>, cache=<unavailable>, driver=<unavailable>) + 304 at font.c:2620
>>
>> frame #1: 0x00000001001c5ffd Emacs`macfont_close(font=0x0000000105c2a8c0) + 13 at macfont.m:2621
>> frame #2: 0x000000010011be9d Emacs`Fgarbage_collect [inlined] cleanup_vector + 38 at alloc.c:2935
>>
>> Notice that the pointer is the same in both cases. Both cleanup_vector() and font_clear_cache() call
>>
>> drv->close(font)
>>
>> It seems that font_clear_cache is leaving the font around for the GC to clean up (a second time) later.
>
> Please try this.
Does anyone know if this patch was committed?
--
Alan Third
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
2016-05-25 20:38 ` Alan Third
@ 2016-05-27 9:29 ` Eli Zaretskii
2016-05-27 18:13 ` Alan Third
0 siblings, 1 reply; 14+ messages in thread
From: Eli Zaretskii @ 2016-05-27 9:29 UTC (permalink / raw)
To: Alan Third; +Cc: radford, 18501, dmantipov
> From: Alan Third <alan@idiocy.org>
> Date: Wed, 25 May 2016 21:38:16 +0100
> Cc: Jim Radford <radford@blackbean.org>, 18501@debbugs.gnu.org
>
> Dmitry Antipov <dmantipov@yandex.ru> writes:
>
> >> Notice that the pointer is the same in both cases. Both cleanup_vector() and font_clear_cache() call
> >>
> >> drv->close(font)
> >>
> >> It seems that font_clear_cache is leaving the font around for the GC to clean up (a second time) later.
> >
> > Please try this.
>
> Does anyone know if this patch was committed?
Yes, see commit fc5ebc3f (which amply references the bug report).
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
2016-05-27 9:29 ` Eli Zaretskii
@ 2016-05-27 18:13 ` Alan Third
2016-05-27 18:56 ` Eli Zaretskii
0 siblings, 1 reply; 14+ messages in thread
From: Alan Third @ 2016-05-27 18:13 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: radford, 18501-done, dmantipov
On Fri, May 27, 2016 at 12:29:36PM +0300, Eli Zaretskii wrote:
> > From: Alan Third <alan@idiocy.org>
> > Date: Wed, 25 May 2016 21:38:16 +0100
> > Cc: Jim Radford <radford@blackbean.org>, 18501@debbugs.gnu.org
> >
> > Does anyone know if this patch was committed?
>
> Yes, see commit fc5ebc3f (which amply references the bug report).
Thanks Eli. I think I need to learn how to use git and it's logs
better.
It looks like this bug is fixed, so I'll close it and if anyone
disagrees, let me know.
--
Alan Third
^ permalink raw reply [flat|nested] 14+ messages in thread
* bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close())
2016-05-27 18:13 ` Alan Third
@ 2016-05-27 18:56 ` Eli Zaretskii
0 siblings, 0 replies; 14+ messages in thread
From: Eli Zaretskii @ 2016-05-27 18:56 UTC (permalink / raw)
To: Alan Third; +Cc: radford, 18501, dmantipov
> Date: Fri, 27 May 2016 19:13:25 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: dmantipov@yandex.ru, radford@blackbean.org, 18501-done@debbugs.gnu.org
>
> > > Does anyone know if this patch was committed?
> >
> > Yes, see commit fc5ebc3f (which amply references the bug report).
>
> Thanks Eli. I think I need to learn how to use git and it's logs
> better.
Don't feel bad. I actually did this the other way around: looked at
the relevant function in the source, saw that the code which the patch
modified already was, then used "git annotate" to find the commit.
Alternatively, "git grep 18501" finds the log entry for that commit
(but using that requires one to believe that the bug number is always
mentioned in the log entry, something that isn't 100% true.
> It looks like this bug is fixed, so I'll close it and if anyone
> disagrees, let me know.
Thanks. Let me take this opportunity and thank you for your efforts
in triage of the old bugs.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2016-05-27 18:56 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-09-17 23:38 bug#18501: 24.3.93; OS X; crash in free() when calling macfont_close() Jim Radford
[not found] ` <handler.18501.B.141107709331502.ack@debbugs.gnu.org>
2014-09-18 22:14 ` bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when calling macfont_close()) Jim Radford
2014-09-19 17:05 ` Jim Radford
2014-09-19 18:05 ` Jim Radford
2014-09-20 1:08 ` Dmitry Antipov
2014-09-20 22:08 ` Jim Radford
2014-09-21 5:03 ` Dmitry Antipov
2014-09-21 16:58 ` Jim Radford
2014-09-22 9:52 ` YAMAMOTO Mitsuharu
2014-09-22 11:01 ` Dmitry Antipov
2016-05-25 20:38 ` Alan Third
2016-05-27 9:29 ` Eli Zaretskii
2016-05-27 18:13 ` Alan Third
2016-05-27 18:56 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).