bug#70914: 29.3; Crashes often on Windows

[Simen Endsjø]

This time I know exactly what I did. I have a file which looks like this
(anonymized paths). Had marked Date to HttpSubStatus, pressed I (bound to
evil-insert), typed "1) " and pressed enter. Then it crashed. I opened the file
again and did a recover, which brought me the content below where it has
partially updated the data.I tried doing the exact same thing again, but it
didn't crash.


(* ref [[file:d:/foo/bar::line content here]]
1) Date
1) Time
1) ClientIP
1) UserName
1) SiteName
1) ComputerName
1) ServerIP
1) Method
-UriStem
UriQuery
HttpStatus
Win32Status
BytesSent
BytesRecv
TimeTaken
ServerPort
UserAgent
Cookie
Referer
ProtocolVersion
Host
HttpSubStatus
*)
let path = "d:/tmp/foo/bar"

On Tue, May 14, 2024 at 2:08 PM Simen Endsjø <simendsjo@gmail.com> wrote:
>
> 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.