bug#70914: 29.3; Crashes often on Windows

[Simen Endsjø]

> Does this happen in "emacs -Q", or only with your customizations?  If
> the latter, perhaps try disabling the customizations one by one or in
> related groups, so we could at least have some hint what triggers
> these problems if not causes them.

I think I managed to narrow it down, but I'm not exactly sure what combination
of settings has to be in effect for it to trigger.

We got an indication that there was a unicode problem earier, and as it crashes
in org-mode buffers, I looked at the configuration there. When I turned of the
+pretty feature in Doom Emacs, it didn't crash anymore.

    (when (modulep! +pretty)
      (package! org-appear :pin "81eba5d7a5b74cdb1bad091d85667e836f16b997")
      (package! org-superstar :pin "54c81c27dde2a6dc461bb064e79a8b2089093a2e")
      (package! org-fancy-priorities :pin
"7f677c6c14ecf05eab8e0efbfe7f1b00ae68eb1d"))

    (after! org
      (setq org-highlight-latex-and-related '(native script entities)))

    (use-package! org-fancy-priorities ; priority icons
      :hook (org-mode . org-fancy-priorities-mode)
      :hook (org-agenda-mode . org-fancy-priorities-mode)
      :config (setq org-fancy-priorities-list '("⚑" "⬆" "■")))

    (use-package! org-superstar ; "prettier" bullets
      :hook (org-mode . org-superstar-mode)
      :config
      ;; Make leading stars truly invisible, by rendering them as spaces!
      (setq org-superstar-leading-bullet ?\s
            org-superstar-leading-fallback ?\s
            org-hide-leading-stars nil
            org-superstar-todo-bullet-alist
            '(("TODO" . 9744)
              ("[ ]"  . 9744)
              ("DONE" . 9745)
              ("[X]"  . 9745))))

    (use-package! org-appear ; better markup edit
      :hook (org-mode . org-appear-mode))

When looking ath the org-superstar-mode documentation I see the following
section

    The package in question has matured, but suffers from intricate timing
    errors which will require looking into. Especially since they are so far
    impossible to test reliably due to their nature.

Ref 
https://github.com/integral-dw/org-superstar-mode?tab=readme-ov-file#planned-features

I cannot see any open or closed issues referring to crashes though.

But this might indicate why I'm not getting the errors reproducible, and that I
get them a lot when debugging.

Looks like I need both org-superstar and org-fancy-priorities for it to trigger
often.

On Thu, May 16, 2024 at 10:07 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Simen Endsjø <simendsjo@gmail.com>
> > Date: Wed, 15 May 2024 22:03:42 +0200
> > Cc: 70914@debbugs.gnu.org
> >
> > >>     (process:13240): GLib-GIO-WARNING **: 20:15:06.678: Unexpectedly,
> > >> UWP app `Microsoft.OutlookForWindows_1.2023.1101.300_x64__8wekyb3d8bbwe'
> > >> (AUMId 
> > >> `Microsoft.OutlookForWindows_8wekyb3d8bbwe!Microsoft.OutlookforWindows')
> > >> supports 1 extensions but has no verbs
> > >
> > > What are these warnings from Glib, and why should Emacs care about
> > > problems with Outlook?
> >
> > After querying chatgpt a bit, it looks like GIO scans all installed 
> > applications
> > on the systems, and shows warning for incorrectly specified ones:
> >
> >     The warnings you're seeing indicate that certain UWP applications 
> > declare
> >     extensions (indicating they have certain capabilities) but do not 
> > declare
> >     any verbs (actions they can perform). This is unusual because 
> > typically, an
> >     app that supports an extension should also support verbs to interact 
> > with
> >     those extensions.
> >
> > And that these are unrelated to the running process.
>
> Yes, I know all that already.  I just don't understand why we see this
> in Emacs from Glib, nor why should Glib make Emacs "scan all the
> installed applications" in the first place.  We only use Glib in Emacs
> on Windows because it's a dependency of librsvg, so the above sounds
> like some gross mis-configuration issue of librsvg as provided by the
> MSYS2 folks.  Corwin, any ideas about this? should we raise this issue
> with the MSYS2 folks?
>
> > > I again suggest to review all the software installed there, maybe 
> > > something will
> > > stand out.
> >
> > There is a lot of processes running on Windows, and I have no idea what most
> > is... Here's a list of the running processes. I've removed the command line 
> > in
> > case there's something sensitive there though.
>
> I didn't mean to look at the processes, I meant to look at the
> installed software.  Start Settings, then select System->System
> Components, then review the installed Components.  Then click on
> "Installed apps" and review the applications you have installed.
>
> You can also do the last part with the "winget list" command from the
> command line.
>
> For example, I see indications that you have Power Toys installed.  So
> maybe disable them (or uninstall completely, if you can), and see if
> that helps.  And maybe if you look at the installed components and
> apps, there would be other clues like that.
>
> > Here's a new crash report using cmd.exe. Note that it didn't crash the first
> > time, so I `(kill-emacs)` and ran again to get a crash.
>
> Thanks.  This again shows that the program counter got set to zero
> somehow.  Why that happens, I don't know.  Perhaps some stack
> overwriting, or some software that injects code into the running Emacs
> process.
>
> Does this happen in "emacs -Q", or only with your customizations?  If
> the latter, perhaps try disabling the customizations one by one or in
> related groups, so we could at least have some hint what triggers
> these problems if not causes them.
>
> The only other idea I have is to try installing older versions of
> Emacs -- if you find one that doesn't crash, maybe we could consider
> the changes between it and the first version which does crash, and
> take it from there (although the list of changes is usually huge, so
> it won't be easy).