emacs-app @24.3_2 hangs upon exit on Mavericks

[luke.woloszyn@…]

Attempting to close emacs-app with some unsaved file or active process will bring up a window asking me either to save the file or whether I'm sure I want to exit. These windows are completely unresponsive and I have to Force Quit emacs-app to close it. Closing emacs-app when everything's 'clean' (no unsaved files or active processes) proceeds without a hitch. Using Mavericks.

[luke.woloszyn@…]

Cc Me!

[luke.woloszyn@…]

This problem appears to be specific to closing emacs-app by hitting the close button in upper left; C-x C-c works fine.

[graziosi.angelo@…]

I am seeing a similar issue trying to install an ELPA/MELPA package. I have added

(when (>= emacs-major-version 24)
  (require 'package)
  (package-initialize)
  (add-to-list 'package-archives '("melpa" . "http://melpa.milkbox.net/packages/") t)
  )

to my ~/.emacs.g/init.el file. Then I restarted Emacs and chose Option/Manage Emacs Packages. I choose tabbar-ruler clicking with mouse-1 . An Help window opens with a 'Install' button. I click with mouse-1 'Install'. A dialog opens asking if I want install the package.

I click 'yes' button.. From now on, Emacs does not respond and I have to exit with Apple menu/Force Quit.

If instead of clicking the 'Install' button in the Help window, I select the package to be installed typing 'i' (to mark it as to be installed) and then 'x' (to execute the installation), the request, 'yes' or 'not', to install that package shows up in the minibuffer. Typing 'yes' installs the packages correctly and without any freezing...

Ciao, Angelo.

[easye]

I have a similar hang occurring as SLIME prompts for switching the default REPL when the underlying inferior Lisp has unexpectedly terminated, so the problem seems to lie in the OS X GUI/Emacs layer. I suppose there is some way to tell Emacs not to open "native" dialog prompt windows that would could function as a work-around until the OS X GUI/Emacs interaction could be debugged.

[easye]

Cc Me!

[seb@…]

I have the same issue, i.e. whenever a pop dialog is displayed there is no way to get out of it. (Emacs doesn't actually seem to be "hanging" - more like the event loop is stuck). The problem seems to be in x-popup-dialog, and is easily reproduced by:

(x-popup-dialog t `("Are you sure?" ("Yes" . 'y) ("No" . 'n)))

The bug has been reported as a bug in emacs, see ​http://debbugs.gnu.org/cgi/bugreport.cgi?bug=17592 but since it cannot be reproduced there I suspect that there is something in our MacPorts patches that is causing this. I can try to selectively edit out the patches - but if anyone with more knowledge of emacs internals would like to help...? :-)

PS. A workaround is to set the variable use-dialog-box to nil - which at least prevents invokations of y-or-n-p (and maybe other functions?) to display a dialog box when it normally think it should...

[smaret (Sebastien Maret)]

Cc Me!

[smaret (Sebastien Maret)]

Replying to seb@…:

PS. A workaround is to set the variable use-dialog-box to nil - which at least prevents invokations of y-or-n-p (and maybe other functions?) to display a dialog box when it normally think it should...

Can you give more details on how to do this?

[smaret (Sebastien Maret)]

This bug is due to this patch:

patch-mavericks-memleak.diff

which was introduced to fix issue #42383.

[smaret (Sebastien Maret)]

Attached is a modified version of patch-mavericks-memleak.diff, adapted from emacs bzr repo. It does fix the "freeze" issue, but I am not sure about issue #42383.

[cooljeanius (Eric Gallager)]

Cc Me!

[smaret (Sebastien Maret)]

Replying to sebastien.maret@…:

It does fix the "freeze" issue, but I am not sure about issue #42383.

I've been using the patched version of Emacs for the past three weeks, and I haven't noticed any problem. I think this patch is ready to be committed. Can someone who has commit permission do this?

[mf2k (Frank Schima)]

r123688