GNU bug report logs - #23856
25.0.95; Crash on cancel print dialogue

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 23856 in the body.
You can then email your comments to 23856 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: Alf Lervåg <alf <at> lervag.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.0.95; Crash on cancel print dialogue
Date: Mon, 27 Jun 2016 21:05:11 +0200

Occasionally I press cmd-p by mistake. When I press cancel in the print dialogue, emacs crashes. This is annoying. Let me know if there is anything I can do to help locate the root cause.

1. Press Cmd-P
2. Press Esc



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 $LC_ALL: en_US.UTF-8
  value of $LC_CTYPE: UTF-8
  value of $LANG: en_NO.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-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:
For information about GNU Emacs and the GNU system, type C-h C-a.
C-x C-g is undefined
user-error: The mark is not set now, so there is no region
user-error: No mark set in this buffer
Quit
Print buffer *scratch*? y
Spooling...done
Making completion list... [3 times]

Load-path shadows:
None found.

Features:
(shadow sort mail-extr lpr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg epg-config gnus-util mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail
rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode easymenu
cl-loaddefs pcase cl-lib mail-prsvr mail-utils 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 196218 11101)
(symbols 48 19494 0)
(miscs 40 49 299)
(strings 32 15007 6042)
(string-bytes 1 433033)
(vectors 16 32859)
(vector-slots 8 648289 6769)
(floats 8 158 143)
(intervals 56 218 10)
(buffers 976 13))

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

From: Alan Third <alan <at> idiocy.org>
To: Alf Lervåg <alf <at> lervag.net>
Cc: 23856 <at> debbugs.gnu.org
Subject: Re: bug#23856: 25.0.95; Crash on cancel print dialogue
Date: Tue, 28 Jun 2016 17:57:07 +0100

Alf Lervåg <alf <at> lervag.net> writes:

> Occasionally I press cmd-p by mistake. When I press cancel in the
> print dialogue, emacs crashes. This is annoying. Let me know if there
> is anything I can do to help locate the root cause.
>
> 1. Press Cmd-P
> 2. Press Esc

This can be triggered from any dialogue box, it seems. I eval:

(x-popup-dialogue t '("moo"))

and then hit esc. It doesn't crash every time, but it will after
repeating a few times.

It's a seg fault at line 1446 of nsmenu.m:

    [unwind_data->pool release];

This is Objective C's way of freeing memory and I guess that it's
crashing because it's trying to release some memory that's already been
freed. Maybe.

* thread #1: tid = 0x65736, 0x00007fff8dc21af1 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 403, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
    frame #0: 0x00007fff8dc21af1 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 403
libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop:
->  0x7fff8dc21af1 <+403>: movq   0x10(%rbx), %rax
    0x7fff8dc21af5 <+407>: leaq   0x38(%rbx), %rcx
    0x7fff8dc21af9 <+411>: cmpq   %rcx, %rax
    0x7fff8dc21afc <+414>: jne    0x7fff8dc21b1e            ; <+448>


-- 
Alan Third

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

From: Alan Third <alan <at> idiocy.org>
To: Alf Lervåg <alf <at> lervag.net>
Cc: 23856 <at> debbugs.gnu.org
Subject: [PATCH] Remove separate pool for popup dialogs (bug#23856)
Date: Wed, 29 Jun 2016 20:32:22 +0100

* src/nsmenu.m (pop_down_menu, ns_popup_dialog): Remove references to
autorelease pool and Popdown_data struct.
---
 src/nsmenu.m | 24 ++++--------------------
 1 file changed, 4 insertions(+), 20 deletions(-)

diff --git a/src/nsmenu.m b/src/nsmenu.m
index 7d340e8..12af38b 100644
--- a/src/nsmenu.m
+++ b/src/nsmenu.m
@@ -1426,29 +1426,19 @@ - (NSRect) frame
 
    ========================================================================== */
 
-struct Popdown_data
-{
-  NSAutoreleasePool *pool;
-  EmacsDialogPanel *dialog;
-};
-
 static void
 pop_down_menu (void *arg)
 {
-  struct Popdown_data *unwind_data = arg;
+  EmacsDialogPanel *panel = arg;
 
-  block_input ();
   if (popup_activated_flag)
     {
-      EmacsDialogPanel *panel = unwind_data->dialog;
+      block_input ();
       popup_activated_flag = 0;
       [panel close];
-      [unwind_data->pool release];
       [[FRAME_NS_VIEW (SELECTED_FRAME ()) window] makeKeyWindow];
+      unblock_input ();
     }
-
-  xfree (unwind_data);
-  unblock_input ();
 }
 
 
@@ -1459,7 +1449,6 @@ - (NSRect) frame
   Lisp_Object tem, title;
   NSPoint p;
   BOOL isQ;
-  NSAutoreleasePool *pool;
 
   NSTRACE ("ns_popup_dialog");
 
@@ -1479,18 +1468,13 @@ - (NSRect) frame
     contents = list2 (title, Fcons (build_string ("Ok"), Qt));
 
   block_input ();
-  pool = [[NSAutoreleasePool alloc] init];
   dialog = [[EmacsDialogPanel alloc] initFromContents: contents
                                            isQuestion: isQ];
 
   {
     ptrdiff_t specpdl_count = SPECPDL_INDEX ();
-    struct Popdown_data *unwind_data = xmalloc (sizeof (*unwind_data));
-
-    unwind_data->pool = pool;
-    unwind_data->dialog = dialog;
 
-    record_unwind_protect_ptr (pop_down_menu, unwind_data);
+    record_unwind_protect_ptr (pop_down_menu, dialog);
     popup_activated_flag = 1;
     tem = [dialog runDialogAt: p];
     unbind_to (specpdl_count, Qnil);  /* calls pop_down_menu */
-- 
I'm unsure what the purpose of this autorelease pool is. I guess it's
supposed to be so that the dialog object always get released
correctly, but it seems to be broken.

I've just removed it, which I guess may introduce a memory leak, but I
don't know how to check.

-- 
Alan Third

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

From: Alan Third <alan <at> idiocy.org>
To: Alf Lervåg <alf <at> lervag.net>
Cc: 23856-done <at> debbugs.gnu.org
Subject: Re: bug#23856: [PATCH] Remove separate pool for popup dialogs
 (bug#23856)
Date: Sun, 17 Jul 2016 22:20:40 +0100

Alan Third <alan <at> idiocy.org> writes:

> I'm unsure what the purpose of this autorelease pool is. I guess it's
> supposed to be so that the dialog object always get released
> correctly, but it seems to be broken.
>
> I've just removed it, which I guess may introduce a memory leak, but I
> don't know how to check.

I've tried checking this with "leaks" and it's coming back clean, so
I've pushed it to master.
-- 
Alan Third

Previous Next

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