bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Ivan Cibrario Bertolotti]

Emacs occasionally crashes with a segmentation fault when deleting a
frame on OSX.  The crash occurs with low probability, I am sorry I
cannot provide a detailed recipe to reproduce it at the moment.

Looking at the crash report (at the bottom of this email) it seems to me
that an EmacsImage is being deallocated by autorelease after it has
already been freed, thus causing a NULL pointer dereference.

Might this be another case of omitted bracketing with
block_input()/unblock_input(), like in bug #23462?

I am now running Emacs with NSTRACE_ENABLED.  If you have any better
idea on how to gather more information, please let me know.  I am
willing to help.

Thanks and best regards,
ICB


Process:               Emacs-x86_64-10_9 [3325]
Path:                  /Users/USER/*/Emacs.app/Contents/MacOS/Emacs-x86_64-10_9
Identifier:            org.gnu.Emacs
Version:               Version 25.0.95 (9.0)
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           Emacs-x86_64-10_9 [3325]
User ID:               501

Date/Time:             2016-06-30 18:51:07.043 +0200
OS Version:            Mac OS X 10.11.5 (15F34)
Report Version:        11
Anonymous UUID:        12F2E9FF-07EA-3C6C-2998-78FF89BB8F8C

Sleep/Wake UUID:       C2DE9394-F9B8-453B-9D91-81E1D8F25C28

Time Awake Since Boot: 53000 seconds
Time Since Wake:       1800 seconds

System Integrity Protection: enabled

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

Exception Type:        EXC_BAD_ACCESS (SIGABRT)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000018
Exception Note:        EXC_CORPSE_NOTIFY

VM Regions Near 0x18:
--> 
    __TEXT                 0000000100000000-000000010020d000 [ 2100K] r-x/rwx SM=COW  /Users/USER/*/Emacs.app/Contents/MacOS/Emacs-x86_64-10_9

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	0x00007fff8671a8ea __kill + 10
1   Emacs-x86_64-10_9             	0x00000001000b9b80 terminate_due_to_signal + 144
2   Emacs-x86_64-10_9             	0x00000001000d6393 emacs_abort + 19
3   Emacs-x86_64-10_9             	0x00000001001a61ac ns_term_shutdown + 124
4   Emacs-x86_64-10_9             	0x00000001000b9d45 shut_down_emacs + 261
5   Emacs-x86_64-10_9             	0x00000001000b9b45 terminate_due_to_signal + 85
6   Emacs-x86_64-10_9             	0x00000001000d7cd6 deliver_fatal_thread_signal + 134
7   Emacs-x86_64-10_9             	0x00000001000d8a26 handle_sigsegv + 150
8   libsystem_platform.dylib      	0x00007fff9766452a _sigtramp + 26
9   ???                           	000000000000000000 0 + 0
10  libobjc.A.dylib               	0x00007fff8ff342f4 objc_object::sidetable_release(bool) + 242
11  com.apple.CoreFoundation      	0x00007fff99a58a4d -[__NSArrayM dealloc] + 205
12  libobjc.A.dylib               	0x00007fff8ff342f4 objc_object::sidetable_release(bool) + 242
13  com.apple.AppKit              	0x00007fff967d0437 -[NSImage dealloc] + 152
14  Emacs-x86_64-10_9             	0x00000001001c114e -[EmacsImage dealloc] + 94
15  libobjc.A.dylib               	0x00007fff8ff342f4 objc_object::sidetable_release(bool) + 242
16  libobjc.A.dylib               	0x00007fff8ff32ac4 (anonymous namespace)::AutoreleasePoolPage::pop(void*) + 476
17  com.apple.CoreFoundation      	0x00007fff99a72c12 _CFAutoreleasePoolPop + 50
18  com.apple.Foundation          	0x00007fff93c6e9ea -[NSAutoreleasePool drain] + 153
19  com.apple.AppKit              	0x00007fff967d9e53 -[NSApplication run] + 893
20  Emacs-x86_64-10_9             	0x00000001001a6348 -[EmacsApp run] + 344
21  Emacs-x86_64-10_9             	0x00000001001b1916 ns_read_socket + 710
22  Emacs-x86_64-10_9             	0x00000001000c0600 gobble_input + 336
23  Emacs-x86_64-10_9             	0x00000001000c1412 read_char + 1986
24  Emacs-x86_64-10_9             	0x00000001000bed1c read_key_sequence + 2092
25  Emacs-x86_64-10_9             	0x00000001000bd432 command_loop_1 + 1154
26  Emacs-x86_64-10_9             	0x0000000100138a36 internal_condition_case + 70
27  Emacs-x86_64-10_9             	0x00000001000ce050 command_loop_2 + 48
28  Emacs-x86_64-10_9             	0x0000000100138596 internal_catch + 54
29  Emacs-x86_64-10_9             	0x00000001000bc67e command_loop + 158
30  Emacs-x86_64-10_9             	0x00000001000bc595 recursive_edit_1 + 117
31  Emacs-x86_64-10_9             	0x00000001000bc7bc Frecursive_edit + 220
32  Emacs-x86_64-10_9             	0x00000001000bb48e main + 5854
33  libdyld.dylib                 	0x00007fff8635c5ad start + 1

In GNU Emacs 25.0.95.1 (x86_64-apple-darwin13.4.0, NS appkit-1265.21 Version 10.9.5 (Build 13F1603))
of 2016-06-11 built on builder10-9.local
Windowing system distributor 'Apple', version 10.3.1404
Configured using:
'configure --with-ns '--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp''

Configured features:
NOTIFY ACL LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS

Important settings:
  value of $LANG: en_GB.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  recentf-mode: t
  global-whitespace-mode: t
  display-time-mode: t
  display-battery-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Loading whitespace...done
Loading recentf...done
Loading paren...done
Loading type-break...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort flyspell ispell mail-extr emacsbug message dired
format-spec rfc822 mml mml-sec password-cache epg gnus-util mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr
mail-utils server printing ps-print ps-def lpr type-break paren recentf
tree-widget wid-edit whitespace time battery cus-start cus-load
exec-path-from-shell finder-inf info tex-site package epg-config seq
byte-opt gv bytecomp byte-compile cl-extra help-mode easymenu cconv
cl-loaddefs pcase cl-lib time-date mule-util tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel ns-win ucs-normalize
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock
syntax facemenu font-core frame cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
kqueue cocoa ns multi-tty make-network-process emacs)

Memory information:
((conses 16 245035 7260)
(symbols 48 24308 0)
(miscs 40 59 278)
(strings 32 30488 6991)
(string-bytes 1 933458)
(vectors 16 38029)
(vector-slots 8 700699 3288)
(floats 8 454 200)
(intervals 56 256 0)
(buffers 976 12))

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Alan Third]

Ivan Cibrario Bertolotti <ivan.cibrario@polito.it> writes:

> Emacs occasionally crashes with a segmentation fault when deleting a
> frame on OSX.  The crash occurs with low probability, I am sorry I
> cannot provide a detailed recipe to reproduce it at the moment.

Can you provide any information about what you're doing when it crashes?
Are you just closing a frame with C-x 5 0?

> Looking at the crash report (at the bottom of this email) it seems to me
> that an EmacsImage is being deallocated by autorelease after it has
> already been freed, thus causing a NULL pointer dereference.
>
> Might this be another case of omitted bracketing with
> block_input()/unblock_input(), like in bug #23462?

It could be, but I don't think so. That one happened when the event
handler fired *within* the iconify function. I don't see anything in the
stack trace that looks like that.

> I am now running Emacs with NSTRACE_ENABLED.  If you have any better
> idea on how to gather more information, please let me know.  I am
> willing to help.

I'm not sure how to go about debugging this stuff, but NSZombiesEnabled
seems to be the way:

$ NSZombiesEnabled=YES /path/to/emacs.app/Contents/MacOS/Emacs

this should print out a message when an object is deallocated too many
times, instead of just crashing.
-- 
Alan Third

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Ivan Cibrario Bertolotti]

Hello Alan,

first of all, thank you so much for your help.


> On 30 Jun 2016, at 20:50, Alan Third <alan@idiocy.org> wrote:
> 
> Ivan Cibrario Bertolotti <ivan.cibrario@polito.it> writes:
> 
>> Emacs occasionally crashes with a segmentation fault when deleting a
>> frame on OSX.  The crash occurs with low probability, I am sorry I
>> cannot provide a detailed recipe to reproduce it at the moment.
> 
> Can you provide any information about what you're doing when it crashes?
> Are you just closing a frame with C-x 5 0?

Sorry, I forgot to mention.  Yes, that’s it.  It seems that the way the frame was created (C-x 5 2, C-x 5 f, or emacsclient) does not make any difference.

On the other hand (but this is just a wild guess given the low probability of the crash) it seems that having another frame in full-screen mode makes the crash more likely.  In this case, emacs switches from windowed to full-screen mode when the frame is closed.


>> Looking at the crash report (at the bottom of this email) it seems to me
>> that an EmacsImage is being deallocated by autorelease after it has
>> already been freed, thus causing a NULL pointer dereference.
>> 
>> Might this be another case of omitted bracketing with
>> block_input()/unblock_input(), like in bug #23462?
> 
> It could be, but I don't think so. That one happened when the event
> handler fired *within* the iconify function. I don't see anything in the
> stack trace that looks like that.

That’s right, I stand corrected.


>> I am now running Emacs with NSTRACE_ENABLED.  If you have any better
>> idea on how to gather more information, please let me know.  I am
>> willing to help.
> 
> I'm not sure how to go about debugging this stuff, but NSZombiesEnabled
> seems to be the way:
> 
> $ NSZombiesEnabled=YES /path/to/emacs.app/Contents/MacOS/Emacs
> 
> this should print out a message when an object is deallocated too many
> times, instead of just crashing.

> -- 
> Alan Third

I understand, it looks nasty indeed and it happens on average only once a day.  Thank you for the hint.  I will keep using Emacs with NSTRACE_ENABLED and NSZombiesEnabled=YES.  Will get back as soon as I have more substantial information.

Thanks again,
Ivan

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Alan Third]

Ivan Cibrario Bertolotti <ivan.cibrario@polito.it> writes:

>> I'm not sure how to go about debugging this stuff, but NSZombiesEnabled
>> seems to be the way:
>> 
>> $ NSZombiesEnabled=YES /path/to/emacs.app/Contents/MacOS/Emacs
>> 
>> this should print out a message when an object is deallocated too many
>> times, instead of just crashing.
>
>> -- 
>> Alan Third
>
> I understand, it looks nasty indeed and it happens on average only
> once a day. Thank you for the hint. I will keep using Emacs with
> NSTRACE_ENABLED and NSZombiesEnabled=YES. Will get back as soon as I
> have more substantial information.

Hi Ivan, did you ever get anywhere with this?
-- 
Alan Third

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Ivan Cibrario Bertolotti]

Hi Alan,

unfortunately, no.  I am still using Emacs with NSTRACE_ENABLED and NSZombiesEnabled=YES, plus some extra debugging printouts of my own, related to allocation and deallocation of EmacsImages.  However, I cannot trigger the bug anymore.  In my opinion, there are two possible reasons for this:

- triggering the bug was related to “something special” I was doing with Emacs at that time (somewhat unlikely), or

- it is a timing-dependent bug and the debugging printouts steered Emacs away from it (perhaps more likely)

At this time I seldom see EmacsImage allocations/deallocations in the Emacs trace if at all.  It seems to me that most of them are allocated before dumping (like fringe bitmaps in bimgs, ns_draw_fringe_bitmap, nsterm.m) and never deallocated.

I would like to force Emacs to make heavier use of EmacsImages and increase the probability of running into the bug again, but I don’t know the code base well enough for that.

If you know of any way of attaining that, please let me know and I will give it a try.

Thanks,
Ivan


> On 11 Sep 2016, at 12:15, Alan Third <alan@idiocy.org> wrote:
> 
> Ivan Cibrario Bertolotti <ivan.cibrario@polito.it> writes:
> 
>>> I'm not sure how to go about debugging this stuff, but NSZombiesEnabled
>>> seems to be the way:
>>> 
>>> $ NSZombiesEnabled=YES /path/to/emacs.app/Contents/MacOS/Emacs
>>> 
>>> this should print out a message when an object is deallocated too many
>>> times, instead of just crashing.
>> 
>>> -- 
>>> Alan Third
>> 
>> I understand, it looks nasty indeed and it happens on average only
>> once a day. Thank you for the hint. I will keep using Emacs with
>> NSTRACE_ENABLED and NSZombiesEnabled=YES. Will get back as soon as I
>> have more substantial information.
> 
> Hi Ivan, did you ever get anywhere with this?
> -- 
> Alan Third

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Alan Third]

Ivan Cibrario Bertolotti <ivan.cibrario@polito.it> writes:

> unfortunately, no. I am still using Emacs with NSTRACE_ENABLED and
> NSZombiesEnabled=YES, plus some extra debugging printouts of my own,
> related to allocation and deallocation of EmacsImages. However, I
> cannot trigger the bug anymore. In my opinion, there are two possible
> reasons for this:
>
> - triggering the bug was related to “something special” I was doing
>   with Emacs at that time (somewhat unlikely), or
>
> - it is a timing-dependent bug and the debugging printouts steered
>   Emacs away from it (perhaps more likely)
>
> At this time I seldom see EmacsImage allocations/deallocations in the
> Emacs trace if at all. It seems to me that most of them are allocated
> before dumping (like fringe bitmaps in bimgs, ns_draw_fringe_bitmap,
> nsterm.m) and never deallocated.
>
> I would like to force Emacs to make heavier use of EmacsImages and
> increase the probability of running into the bug again, but I don’t
> know the code base well enough for that.
>
> If you know of any way of attaining that, please let me know and I
> will give it a try.

I'm afraid I don't know any way of doing that. I guess you could just
try loading and deleting images repeatedly:

(dotimes (i 10)
  (let ((image (find-image '((:type xpm :file "delete.xpm")))))
    (insert (propertize " " 'display `(,image (slice .0 .0 1.0 1.0)))))
  (redisplay)
  (delete-backward-char 1))

That should display a bin icon ten times quickly, but I don't know if
it'll dealloc it each time or if it gets cached in some way.

Since you're the only person to report this so far I'd be inclined to
think that perhaps some part of your configuration is causing it. Would
it be possible for you to turn off the debug output and try
systematically disabling different parts of your configuration to see if
the crashes go away? That could perhaps help us narrow down what code is
causing the crash.

-- 
Alan Third

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Ivan Cibrario Bertolotti]

> On 11 Sep 2016, at 20:18, Alan Third <alan@idiocy.org> wrote:
> 
> Ivan Cibrario Bertolotti <ivan.cibrario@polito.it> writes:
> 
>> unfortunately, no. I am still using Emacs with NSTRACE_ENABLED and
>> NSZombiesEnabled=YES, plus some extra debugging printouts of my own,
>> related to allocation and deallocation of EmacsImages. However, I
>> cannot trigger the bug anymore. In my opinion, there are two possible
>> reasons for this:
>> 
>> - triggering the bug was related to “something special” I was doing
>>  with Emacs at that time (somewhat unlikely), or
>> 
>> - it is a timing-dependent bug and the debugging printouts steered
>>  Emacs away from it (perhaps more likely)
>> 
>> At this time I seldom see EmacsImage allocations/deallocations in the
>> Emacs trace if at all. It seems to me that most of them are allocated
>> before dumping (like fringe bitmaps in bimgs, ns_draw_fringe_bitmap,
>> nsterm.m) and never deallocated.
>> 
>> I would like to force Emacs to make heavier use of EmacsImages and
>> increase the probability of running into the bug again, but I don’t
>> know the code base well enough for that.
>> 
>> If you know of any way of attaining that, please let me know and I
>> will give it a try.
> 
> I'm afraid I don't know any way of doing that. I guess you could just
> try loading and deleting images repeatedly:
> 
> (dotimes (i 10)
>  (let ((image (find-image '((:type xpm :file "delete.xpm")))))
>    (insert (propertize " " 'display `(,image (slice .0 .0 1.0 1.0)))))
>  (redisplay)
>  (delete-backward-char 1))
> 
> That should display a bin icon ten times quickly, but I don't know if
> it'll dealloc it each time or if it gets cached in some way.

Thank you, I tried something very similar in the past and it works perfectly.
In the trace I see a single instance of [EmacsImage initForXPMWithDepth:::],
so I guess the image gets cached.


> Since you're the only person to report this so far I'd be inclined to
> think that perhaps some part of your configuration is causing it. Would
> it be possible for you to turn off the debug output and try
> systematically disabling different parts of your configuration to see if
> the crashes go away? That could perhaps help us narrow down what code is
> causing the crash.

I agree, it makes a lot of sense, indeed.  I will definitely try to tweak
my configuration to the extent I can.

Concerning the way of using Emacs, may I ask if there is any “grey area”
in using Emacs in native full screen mode?

When I saw the bug, I was switching in and out of full screen mode quite
often.  One thing I noticed is that the bug appeared during or shortly
after a switch.

I don’t see how it can be related to EmacsImages, but it is
the most significant clue I can think of at this time.

Thank you so much again for your time and for the hints.  Sorry for not
being of much help.

Best regards,
Ivan

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Alan Third]

[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]

On 11 September 2016 at 20:24, Ivan Cibrario Bertolotti <
ivan.cibrario@polito.it> wrote:
>
> Concerning the way of using Emacs, may I ask if there is any “grey area”
> in using Emacs in native full screen mode?
>
> When I saw the bug, I was switching in and out of full screen mode quite
> often.  One thing I noticed is that the bug appeared during or shortly
> after a switch.
>
> I don’t see how it can be related to EmacsImages, but it is
> the most significant clue I can think of at this time.

I’m not aware of any particular issues with full‐screen mode, but I
don’t know if it gets a lot of use. I certainly never use it.

One thing that does come to mind is that NS Emacs sometimes puts an
image in the title‐bar to represent the file, but it’s not consistent
and I don’t understand what the code is doing.

When you’re in full‐screen there is no title‐bar, iirc, so I don’t
know what happens to that image.

I think there’s a way to disable the image, but I can’t remember how.
I’ll see if I can work it out this evening.

-- 
Alan Third

[-- Attachment #2: Type: text/html, Size: 1516 bytes --]

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Ivan Cibrario Bertolotti]

> On 12 Sep 2016, at 14:58, Alan Third <alan@idiocy.org> wrote:
> 
> On 11 September 2016 at 20:24, Ivan Cibrario Bertolotti <ivan.cibrario@polito.it> wrote:
> > 
> > Concerning the way of using Emacs, may I ask if there is any “grey area”
> > in using Emacs in native full screen mode?
> > 
> > When I saw the bug, I was switching in and out of full screen mode quite
> > often.  One thing I noticed is that the bug appeared during or shortly
> > after a switch.
> > 
> > I don’t see how it can be related to EmacsImages, but it is
> > the most significant clue I can think of at this time.
> 
> I’m not aware of any particular issues with full‐screen mode, but I
> don’t know if it gets a lot of use. I certainly never use it.
> 
> One thing that does come to mind is that NS Emacs sometimes puts an
> image in the title‐bar to represent the file, but it’s not consistent
> and I don’t understand what the code is doing.
> 
> When you’re in full‐screen there is no title‐bar, iirc, so I don’t
> know what happens to that image.
> 
> I think there’s a way to disable the image, but I can’t remember how.
> I’ll see if I can work it out this evening.

I had a look at the source (starting from syms_of_nsfns, nsfsn.m).
Are you referring to the frame-title-format lisp variable perhaps?  I tried:

(setq frame-title-format “%b”)

in my .emacs (the default value was t).  This should make Emacs call ns_set_name instead of ns_set_name_as_filename in x_implicitly_set_name, nsfns.m.

Now my frames no longer have any icon, just the buffer name.  If this setting looks good you, I will keep it and see what happens.  If this is not what you had in mind, please let me know.

I also spotted the icon-title-format variable, but I didn’t touch it.  Sorry if I wrote/did something silly, I am not an expert on the Emacs code base.

Thanks again,
Ivan

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Alan Third]

On Mon, Sep 12, 2016 at 04:04:23PM +0200, Ivan Cibrario Bertolotti wrote:
> 
> > On 12 Sep 2016, at 14:58, Alan Third <alan@idiocy.org> wrote:
> > 
> > One thing that does come to mind is that NS Emacs sometimes puts an
> > image in the title‐bar to represent the file, but it’s not consistent
> > and I don’t understand what the code is doing.
> > 
> > When you’re in full‐screen there is no title‐bar, iirc, so I don’t
> > know what happens to that image.
> > 
> > I think there’s a way to disable the image, but I can’t remember how.
> > I’ll see if I can work it out this evening.
> 
> I had a look at the source (starting from syms_of_nsfns, nsfsn.m).
> Are you referring to the frame-title-format lisp variable perhaps?  I tried:
> 
> (setq frame-title-format “%b”)
>
> in my .emacs (the default value was t). This should make Emacs call
> ns_set_name instead of ns_set_name_as_filename in
> x_implicitly_set_name, nsfns.m.

That’s exactly what I was thinking of.

> Now my frames no longer have any icon, just the buffer name. If this
> setting looks good you, I will keep it and see what happens. If this
> is not what you had in mind, please let me know.
> 
> I also spotted the icon-title-format variable, but I didn’t touch
> it. Sorry if I wrote/did something silly, I am not an expert on the
> Emacs code base.

No, this is all good. We’ll see if it makes any difference. If you get
any crashes then we’ll have to look for something else.
-- 
Alan Third

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Ivan Cibrario Bertolotti]

Hello Alan,

> On 12 Sep 2016, at 18:52, Alan Third <alan@idiocy.org> wrote:
> 
> On Mon, Sep 12, 2016 at 04:04:23PM +0200, Ivan Cibrario Bertolotti wrote:
>> 
>>> On 12 Sep 2016, at 14:58, Alan Third <alan@idiocy.org> wrote:
>>> 
>>> One thing that does come to mind is that NS Emacs sometimes puts an
>>> image in the title‐bar to represent the file, but it’s not consistent
>>> and I don’t understand what the code is doing.
>>> 
>>> When you’re in full‐screen there is no title‐bar, iirc, so I don’t
>>> know what happens to that image.
>>> 
>>> I think there’s a way to disable the image, but I can’t remember how.
>>> I’ll see if I can work it out this evening.
>> 
>> I had a look at the source (starting from syms_of_nsfns, nsfsn.m).
>> Are you referring to the frame-title-format lisp variable perhaps?  I tried:
>> 
>> (setq frame-title-format “%b”)
>> 
>> in my .emacs (the default value was t). This should make Emacs call
>> ns_set_name instead of ns_set_name_as_filename in
>> x_implicitly_set_name, nsfns.m.
> 
> That’s exactly what I was thinking of.
> 
>> Now my frames no longer have any icon, just the buffer name. If this
>> setting looks good you, I will keep it and see what happens. If this
>> is not what you had in mind, please let me know.
>> 
>> I also spotted the icon-title-format variable, but I didn’t touch
>> it. Sorry if I wrote/did something silly, I am not an expert on the
>> Emacs code base.
> 
> No, this is all good. We’ll see if it makes any difference. If you get
> any crashes then we’ll have to look for something else.
> -- 
> Alan Third

After ~10 days of rather heavy testing (~8 hours/day of use, initially
with the last RC and now with 25.1), no crashes at all.  I am reverting
to my original configuration (setq frame-title-format t) to double-check.

Thanks again for your help,
Ivan

bug#23875: 25.0.95; Emacs crashes when closing a frame on OSX

[Alan Third]

On Mon, Sep 26, 2016 at 02:48:18PM +0200, Ivan Cibrario Bertolotti wrote:
> >> Now my frames no longer have any icon, just the buffer name. If this
> >> setting looks good you, I will keep it and see what happens. If this
> >> is not what you had in mind, please let me know.
> >> 
> >> I also spotted the icon-title-format variable, but I didn’t touch
> >> it. Sorry if I wrote/did something silly, I am not an expert on the
> >> Emacs code base.
> > 
> > No, this is all good. We’ll see if it makes any difference. If you get
> > any crashes then we’ll have to look for something else.
> 
> After ~10 days of rather heavy testing (~8 hours/day of use, initially
> with the last RC and now with 25.1), no crashes at all.  I am reverting
> to my original configuration (setq frame-title-format t) to double-check.

Hi Ivan,

Did you get any more crashes after reverting to your original
configuration? I’d like to know whether this icon was the source of
your crashes.

Thanks!
-- 
Alan Third