Emacs freezes completely when calling `dap-continue` after `dap-ui-locals` was opened

[aalystama]

Description

Emacs freezes completely and becomes unresponsive when the following sequence occurs:

1. Start debugging a Flutter project using dap-debug.
2. Wait for a breakpoint to be hit (either automatically due to an unhandled exception or a manually added one).
3. Call dap-ui-locals to inspect local variables — this works fine.
4. Then call dap-continue
5. Emacs instantly freezes and stops responding to any input. The only way to recover is to force quit and restart Emacs.

My Environment

• macOS Sonoma 14.2 (Apple Silicon)
• Emacs 30.1 (latest stable)
• Doom Emacs 3.0.0-pre
• I don’t have an exotic config.el. It’s almost the default Doom configuration, so I’m fairly certain this isn’t caused by a custom setup.

Additional Context: How I Narrowed It Down

Originally, I was encountering a complete Emacs freeze immediately upon hitting any breakpoint, even without interacting with the UI.

After some investigation, I discovered that the freeze was caused by DAP mode’s automatic UI configuration. My initial setup used Doom Emacs's default DAP integration, which includes auto-loading UI components like dap-ui-locals, dap-ui-sessions, tooltips, and the REPL.

To mitigate the issue, I disabled all automatic UI features by explicitly adding the following to my config.el:

(after! dap-mode
  (setq dap-auto-configure-features '()) ; disable all UI auto features
  (dap-mode 1))

This prevented Emacs from freezing immediately at breakpoints.

However, if I manually invoke dap-ui-locals during a paused session and then call dap-continue, Emacs still freezes. Even closing the dap-ui-locals window before continuing does not help.

[aalystama]

I also tried different Emacs builds: emacs-mac, emacs-plus and the official one

[MrMcKenzie]

I've seen this too, and Just to note, this seems to be resolved by the last comment in a similiarly reported issue (#842 )

This freeze happens at least with all the Debuggers I normally use (dap-cpptools, dap-lldb, dap-python (with debugpy), dap-dlv-go, dap-java) (imo it should be considered fairly high prio as stepping through code isn't possible at the moment without the edit described in the other issue).

[aalystama]

@MrMcKenzie Man, thanks a lot! I forked the original lsp-treemacs repo, pushed a commit with the fix you mentioned in the comment, and configured my straight.el to use it — and it worked! I recently switched to Emacs from my Neovim setup and was really frustrated by this issue.

By the way, should I go ahead and close this issue? I'm not very familiar with open source contribution etiquette.

[aalystama]

I can also confirm that using treemacs-do-update-node instead of treemacs-update-node seems to completely solve the problem — I no longer need to disable all UI auto features with (setq dap-auto-configure-features '())

[MrMcKenzie]

I wouldn't close this issue just yet - even though the root cause is (seemingly) the same, the issue isn't resolved properly yet in either case and this issue is more descriptive (dap-mode is just hanging on process debug stop period) than the other (debugpy specific).

[dsyzling]

No, this is definitely not a fix, I posted the code to provoke discussion in helping to track down the underlying cause. There are no doubt scenarios where the treemacs-save-position is required so I'd expect that code change to fail at some point. However either there is some code in save-position (macro) that is causing a problem or repeated calls to update-node after wrapping in save-position is causing problems with the dap-ui-locals refresh.

[dsyzling]

After further investigation the problem appears to be within the treemacs-save-position macro. Specifically this section of code:

(_
 ;; point is on a custom node
 (cond
  ((treemacs-is-path-visible? curr-node-path)
   (treemacs-goto-extension-node curr-node-path))
  ((and next-path (treemacs-is-path-visible? next-path))
   (treemacs-goto-extension-node next-path))
  ((and prev-path (treemacs-is-path-visible? prev-path))
   (treemacs-goto-extension-node prev-path))
  (t
   (-let [detour (treemacs--parent curr-file)]
     (while (not (treemacs-is-path-visible? detour))
       (setf detour (treemacs--parent detour)))
     (treemacs-goto-extension-node detour))))))

treemacs--parent-curr-file returns nil in the context of this problem - which is assigned to detour. We then enter an infinite loop (within the while). Secondly, treemacs-goto-extension-node also cannot take a nil so this will also fail.

One possible fix would be:

(-when-let (detour (treemacs--parent curr-file))
  (while (not (treemacs-is-path-visible? detour))
    (setf detour (treemacs--parent detour)))
  (treemacs-goto-extension-node detour))

@yyoncho any comments on the above and do we need to raise this as a treemacs issue to resolved?

[dsyzling]

The fix has now been applied to treemacs so if you update your Emacs packages to include treemacs-20250423.2024 the dap-mode lockup should be resolved. If a few others could verify this we can close this isuse.

[MrMcKenzie]

I've quickly verified on pull of latest master for treemacs (which contains the final change you suggested) that dap-mode breakpoint stopping + continue works.

[btab-z]

The fix has now been applied to treemacs so if you update your Emacs packages to include treemacs-20250423.2024 the dap-mode lockup should be resolved. If a few others could verify this we can close this isuse.

I can verify this: After upgrading to treemacs 20250423.2024, emacs/dap-mode does not freeze anymore (I am using that with dap-python).

[aalystama]

Issue resolved, closing now. Thanks, everyone, for your involvement.