GNU bug report logs - #18501
24.3.93; OS X; crash in free() when calling macfont_close()

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18501 in the body.
You can then email your comments to 18501 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jim Radford <radford <at> blackbean.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.93; OS X; crash in free() when calling macfont_close()
Date: Wed, 17 Sep 2014 16:38:49 -0700

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'

Message #8 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Jim Radford <radford <at> blackbean.org>
To: 18501 <at> debbugs.gnu.org
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when
 calling macfont_close())
Date: Thu, 18 Sep 2014 15:14:30 -0700

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.

Message #11 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Jim Radford <radford <at> blackbean.org>
To: 18501 <at> debbugs.gnu.org
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when
 calling macfont_close())
Date: Fri, 19 Sep 2014 10:05:40 -0700

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 ]

Message #14 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Jim Radford <radford <at> blackbean.org>
To: 18501 <at> debbugs.gnu.org
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when
 calling macfont_close())
Date: Fri, 19 Sep 2014 11:05:28 -0700

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.

Message #17 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Jim Radford <radford <at> blackbean.org>
Cc: 18501 <at> debbugs.gnu.org
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when
 calling macfont_close())
Date: Sat, 20 Sep 2014 05:08:15 +0400

[Message part 1 (text/plain, inline)]

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

[bug18501.patch (text/x-diff, attachment)]

Message #20 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Jim Radford <radford <at> blackbean.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 18501 <at> debbugs.gnu.org
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when
 calling macfont_close())
Date: Sat, 20 Sep 2014 15:08:31 -0700

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

Message #23 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: Jim Radford <radford <at> blackbean.org>
Cc: 18501 <at> debbugs.gnu.org
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when
 calling macfont_close())
Date: Sun, 21 Sep 2014 09:03:55 +0400

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

Message #26 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Jim Radford <radford <at> blackbean.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: 18501 <at> debbugs.gnu.org
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when
 calling macfont_close())
Date: Sun, 21 Sep 2014 09:58:04 -0700

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

Message #29 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Jim Radford <radford <at> blackbean.org>, 18501 <at> debbugs.gnu.org
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X;
 crash in free() when calling macfont_close())
Date: Mon, 22 Sep 2014 18:52:59 +0900

>>>>> On Sat, 20 Sep 2014 05:08:15 +0400, Dmitry Antipov <dmantipov <at> 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 <at> math.s.chiba-u.ac.jp

Message #32 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Antipov <dmantipov <at> yandex.ru>
To: YAMAMOTO Mitsuharu <mituharu <at> math.s.chiba-u.ac.jp>
Cc: Jim Radford <radford <at> blackbean.org>, 18501 <at> debbugs.gnu.org
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X;	crash in free() when
 calling macfont_close())
Date: Mon, 22 Sep 2014 15:01:02 +0400

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

Message #35 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Dmitry Antipov <dmantipov <at> yandex.ru>
Cc: Jim Radford <radford <at> blackbean.org>, 18501 <at> debbugs.gnu.org
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X;
 crash in free() when calling macfont_close())
Date: Wed, 25 May 2016 21:38:16 +0100

Dmitry Antipov <dmantipov <at> 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

Message #38 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: radford <at> blackbean.org, 18501 <at> debbugs.gnu.org, dmantipov <at> yandex.ru
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X;
 crash in free() when calling macfont_close())
Date: Fri, 27 May 2016 12:29:36 +0300

> From: Alan Third <alan <at> idiocy.org>
> Date: Wed, 25 May 2016 21:38:16 +0100
> Cc: Jim Radford <radford <at> blackbean.org>, 18501 <at> debbugs.gnu.org
> 
> Dmitry Antipov <dmantipov <at> 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).

Message #43 received at 18501-done <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: radford <at> blackbean.org, 18501-done <at> debbugs.gnu.org, dmantipov <at> yandex.ru
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when
 calling macfont_close())
Date: Fri, 27 May 2016 19:13:25 +0100

On Fri, May 27, 2016 at 12:29:36PM +0300, Eli Zaretskii wrote:
> > From: Alan Third <alan <at> idiocy.org>
> > Date: Wed, 25 May 2016 21:38:16 +0100
> > Cc: Jim Radford <radford <at> blackbean.org>, 18501 <at> 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

Message #46 received at 18501 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: radford <at> blackbean.org, 18501 <at> debbugs.gnu.org, dmantipov <at> yandex.ru
Subject: Re: bug#18501: Acknowledgement (24.3.93; OS X; crash in free() when
 calling macfont_close())
Date: Fri, 27 May 2016 21:56:47 +0300

> Date: Fri, 27 May 2016 19:13:25 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: dmantipov <at> yandex.ru, radford <at> blackbean.org, 18501-done <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.