bug#70914: 29.3; Crashes often on Windows

[Simen Endsjø]

I understood it as writing outside the stack space for a completion.
Could be caused by some incorrect handling of coding systems where too
little space was reserved as you note.

    #6  0x00007ffbb271440f in ntdll!.chkstk () from
C:\WINDOWS\SYSTEM32\ntdll.dll
    #7  0x00007ffbb268e466 in ntdll!RtlFindCharInUnicodeString () from
    C:\WINDOWS\SYSTEM32\ntdll.dll
    #8  0x00007ffbb27133fe in ntdll!KiUserExceptionDispatcher () from
    C:\WINDOWS\SYSTEM32\ntdll.dll
    #9  0x00007ff71e0ec111 in Fall_completions ()
    #10 0x00007ff71e145688 in Ffuncall ()
    #11 0x00007ffb8d5c1dd0 in
    F636f6d706c6574652d776974682d616374696f6e_complete_with_action_0 ()
    from 
c:\programs\emacs\latest\lib\emacs\29.3\native-lisp\29.3-5efa4952\preloaded\minibuffer-1b0f548b-25462d74.eln

I'm setting LANG to en_US both in the system environment and in my
emacs configuration. I've also enabled UTF-8 everywhere on the systems
(beta feature).

But it's better to use LANG=ENU and the default coding system?

Here's the relevant configuration from my init.el:

  ;; Windows doesn't set this, but some packages might depend on the variable
  (setenv "LANG" "en_US")

  ;; While the Windows clipboard shouldn't change the coding system,
  ;; I get latin-1 back when pasting in Emacs.
  ;; See `list-coding-systems'
  ;; NOTE: I've turned on the global utf8 beta feature in Windows,
  ;; and we thus don't need this
  ;;(set-clipboard-coding-system 'latin-1)
  (set-clipboard-coding-system 'utf-8)

On Tue, May 14, 2024 at 1:23 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Simen Endsjø <simendsjo@gmail.com>
> > Date: Tue, 14 May 2024 12:14:11 +0200
> > Cc: 70914@debbugs.gnu.org
> >
> > Here's a backtrace of the most recent crash. I have no idea if it's
> > one issue or several. It seems to be crashing at arbitrary times,
> > often just when writing plain text in org-mode buffers.
>
> It's unclear what happened here and why.  Seems like some fatal
> exception in the middle of all-completions call, but why would that
> be?
>
> I do see that you have quite a few 3rd-party packages involved in
> this: vertico, orderless, and consult at least.
>
> I also see that one of the threads is run by Glib, which sounds
> strange to me, but maybe it's because of librsvg?  Not sure if this is
> related to the crash.
>
> This part of your environment:
>
>   Important settings:
>     value of $LANG: en_US
>     locale-coding-system: cp65001   <<<<<<<<<<<<<<<<<<<<<<<
>
> might also be related: AFAIU it means you configured your system to
> use UTF-8 encoding by default, which might cause issues with
> sub-processes, because Emacs on Windows doesn't support passing UTF-8
> encoded arguments to sub-processes.  And the backtrace indicates that
> you had a sub-process running when this happened (or at least a thread
> was running waiting for output from a sub-process).
>
> And why is the value of $LANG "en_US"?  It's supposed to be "ENU" on
> Windows.  Did you customize the locale and/or the defaults for the
> coding-systems, and if so, how?
>
> In any case, please keep running Emacs under GDB and post two or three
> more backtraces from the crash, so that we could see which parts of
> this to focus on.
>
> Thanks.