Menubar crashes Aquamacs when R buffer is open #15
Comments
|
Well, crashes are certainly out of polymode's scope. Something is not right with the emacs/aquamacs on your machine. Particularly with |
|
I am able to replicate the issue with GNU Emacs 26.3 (downloaded from emacsformacos.com), so it is not just an Aquamacs 3.5 (based on emacs 25.3) problem. I am able to use the menu bar with other emacs packages (e.g., AucTeX). To replicate on GNU Emacs, I opened a file with the following contents: I then launched an R session, and clicked the menu bar. Crash. Below I pasted the Problem Report generated by the OS after the crash of GNU Emacs. I'm just a "user" reporting a crash that occurs only after loading a newly updated version of poly-R, on two different computers, and two different versions of emacs. |
|
Can you replicate it from plain r-mode buffers? That menu appears in ess mode as well. Can you trigger the crash by executing It's something low level and surely OS/window manager specific. I would be happy to add a work around but as I cannot reproduce I am afraid your are alone here. The GNU bug tracker is the right place for this really. |
|
I can now replicate it without any buffers at all. For GNU Emacs 26.3, running with no configurations at all: From Terminal: Then, in Emacs: After launching the R session, I evaluated the two expressions you suggested. In either case, I would still get a crash after clicking on the menu bar. Because I launched emacs from the Terminal window, I get the following output there after the crash: Removing the offending lines in poly-R.el would be a useful workaround, but at this point, it matters to me only if I update the package again. I see your point about this being a lower-level GNU Emacs thing, but I'm going to try the ESS list next. The crash appears to occur only with R. I tried after launching a bash shell and a python session, and had no problems. If there is no solution there, I'll move up to the Emacs list. Are there any other packages, other than poly-R, that you know use easy-menu-define in a way that would trigger the same kind of crash? In any case, thanks for your help with the debugging. |
|
I think a lot of packages do use easy menu define. I will cross check if I use it incorrectly somehow. Back to my previous question. Do you see the crash from |
|
I just checked using a basic Emacs 26.3 instance with no configurations, as above. It appears that if the active buffer is either the R session, or a buffer in ess-R mode, there is a crash. But if, say, there is an R session open, but the cursor is in a tex file, there is no crash. I reported the issue to ess-bugs, and a respondent was able to replicate the problem. The crash occurs if I click on any menu item at the top of the screen (File, Edit, etc.). |
|
It's most surely Mac OS issue. Let's try to narrow it down. Can you just redefine (defun poly-r-rmarkdown-templates-menu (&optional _items)
'(("rmarkdown" ["GitHub Document (Markdown)" (poly-r--rmarkdown-draft "rmarkdown" "github_document") :help "Template for documents to be published as GitHub Flavored Markdown.
"] ["Package Vignette (HTML)" (poly-r--rmarkdown-draft "rmarkdown" "html_vignette") :help "Template for package vignettes. This customises the basic HTML output to take up as little space as possible.
"])))If it doesn't crash that means it has something to do with calling a process from the menu. Would it be possible for you to pull emacs source and compile emacs 27. Just to be sure that this thing hasn't been fixed on the emacs side already? |
|
The crash no longer happens after redefining |
|
You just need to clone poly-R and from the comand line: this will start emacs 27 with all polymode and ESS dependencies installed from scratch. Replace emacs27 with whatever binary you want to try with. |
|
Here's what I did from the cloned poly-R directory: This launched the GUI for emacs 27.0.50. Then, in Emacs: |
|
I'm also affected by this issue. When I disable poly-R by commenting out |
|
It's not specific to R. |
|
After some more investigation I just detailed in Tramp bug https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24472 I suspect rendering the menu takes too long, a macOS timeout cancels that rendering and frees up something in the NSAutoreleasePool that Emacs tries to release a second time as described by Alan Third in 24472. I know absolutely nothing about poly-R but the workaround(s) listed above all feel like running less code (i.e.: in a shorter time) when the user tries to click on the menu. Confirm? Does artificially increasing that time make the crash more likely? |
|
Thanks @marc-h38 for the updates. I personally never experienced this, but what you say does make sense. Compiling those menus in poly-R takes time because a sub-process has to be queried and many directories checked. So yes, it can take non-trivial amount of time. |
|
I root caused the similar issue with tramp (see 24472 above) and found a simple and pretty good workaround: This stops tramp from accessing the network when reaching the menu bar and the corresponding crashes are gone on my system. The key lead for 24472 was to notice the time-consuming network activity. Again I don't know anything about Poly-R but IMHO you should first attempt to track down and nip every time-consuming activity happening when accessing the menubar. It feels just wrong. |
|
This turns out to have been a long-standing bug in the memory management for menus in Aquamacs, still present in the released Emacs 27. Patches for both have been submitted. The discussion here, and Michael's distillation of how to reproduce it, were very helpful in tracking it down, so thanks very much! (I'm the current Aquamacs maintainer.) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I recently updated to polymode and poly-R versions 0.2. I am running Aquamacs 3.5 on MacOS 10.14.6 Mojave. When I open an R buffer, as soon as I click on the menu bar, Aquamacs immediately crashes. I have replicated this on two different computers.
I traced the problem to the (easy-menu-define poly-markdown+R-menu) function in poly-R.el. If I comment out lines 218-225, and byte-compile the modified file, the crash goes away. I'm not sure what functionality I am losing, so I don't want to submit a pull request just yet. But there appears to be an issue with that function.
The text was updated successfully, but these errors were encountered: