Emacs freezing on org file save on M1 mac

Hi, I have a peculiar issue - when I'm trying to save an org file, the entire Emacs app freezes. Hitting C-g for a while eventually unlocks the application. The org-file in question is a bit long (~2k lines). When the app freezes, if I run `pkill -USR2 Emacs` from an external shell, I get to see the following debug trace: Debugger entered--entering a function: * #f(compiled-function () #<bytecode 0x1f53241d0d03>)() org-element--parse-to(27493) org-element-cache-map(ignore :granularity headline+inlinetask) org-element-cache-map(#f(compiled-function (el) #<bytecode 0x1041c1b32c4d8314>) :next-re "^\\*+ " :fail-re "^\\*+ " :narrow t) org-scan-tags(org-encrypt-entry (lambda (todo tags-list level) (progn (setq org-cached-props nil) (or (and (member "crypt" tags-list))))) nil) org-encrypt-entries() run-hooks(before-save-hook) basic-save-buffer(t) save-buffer(1) funcall-interactively(save-buffer 1) command-execute(save-buffer) I'm using the latest Doom Emacs, with Emacs-Mac 28.1 (https://github.com/railwaycat/homebrew-emacsmacport) on an M1 Mac Air. Any tips/suggestions on how to debug this? Thanks in advance!

Check `org-encrypt-entries` in `before-save-hook`. Have you installed the cli program (GnuPG?) to do the actual encrypting thing?

Yup gpg is present alright. I’m using this setup for a year now, never did I find this sort of issue (I have worked with large org files before). One thing to note for this particular org file I’m using ox-hugo to generate my blog, with one header per entry. subsequently, I have many property drawers for those headers. Idk whether that matters!

You could test this by duplicating the file and saving it. It should cause the same crash. Next remove all property drawers and save. If it doesn’t crash you can be reasonably sure it’s the property drawers

I think the issue is related to the recent version of Org mode. This discussion in ox-hugo gave some good pointers: https://github.com/kaushalmodi/ox-hugo/discussions/551 . Rolling org-mode back to 9.4.6 seems to solve the problem. Anyone else facing this issue and have other suggestions?

What is the output of M-x org-version?

I'm using Org 9.6.

Sure. I am interested in more details. I need the commit number (shown by M-x org-version)

Apologies! I upgraded to the commit `39005dc09`.

This is fairly recent. If you are seeing the problem on this commit, can you please try to set `(setq org-element--cache-self-verify 'backtrace)` and `(setq org-element--cache-self-verify-frequency 1.0)` in your config. Then, open the problematic file and run `M-x org-element-cache-reset` and try to reproduce the issue. Upon reproducing and exiting the infinite loop, run `M-: (org-element--cache-warn "Backtrace")` and share the results.

Thanks for the tip! I'm not facing the issue yet, but I will report as soon as I do!

I'm running into a similar issue, and fwiw after following these steps (up through `org-element-cache-reset`) the problem went away for me (at least for now) btw, I'm on an M1 macbook pro, org 9.6 e9da29b6f, doom emacs on railwaycat port 28.1 w/ native comp. the org file's about 1200 lines.

> org 9.6 e9da29b6f Some related fixes have been made in later commits. Note that `org-element` is nutotiously difficult to debug. Detailed bug reports with the backtrace (you can get it as I described above) are extremely helpful. Escpecially since we are not seeing any reports for months on Org ML and any observed issues are likely caused by rare edge case scenarios.

gotcha, thanks! guess it's time to update :)