[vim/vim] Vim crashes on Windows 11 arm64 (Issue #13453)
Wilhelm Payne
Steps to reproduce
- Compile vim on Windows 11 arm64 with Visual Studio and MSVC
- Run it.
- The terminal ends up with corruption and vim abnormally exits with a log of a crash placed in the Windows event log.
A crash log is as follows:
Faulting module name: vim.exe, version: 9.0.0.0, time stamp: 0x653ea118
Exception code: 0xc0000005
Fault offset: 0x000000000021d41c
Faulting process id: 0x0x1DC
Faulting application start time: 0x0x1DA0A95BE82E49C
Faulting application path: C:\tools\c\viminst\vim\src\vim.exe
Faulting module path: C:\tools\c\viminst\vim\src\vim.exe
Report Id: 45ce53a8-375e-4ff8-ae02-5f6142d77c9d
Faulting package full name:
Faulting package-relative application ID:
Event Name: APPCRASH
Response: Not available
Cab Id: 0
Problem signature:
P1: vim.exe
P2: 9.0.0.0
P3: 653ea118
P4: vim.exe
P5: 9.0.0.0
P6: 653ea118
P7: c0000005
P8: 000000000021d41c
P9:
P10:
Attached files:
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.d45d6800-e776-486c-ba68-da72de767334.tmp.WERInternalMetadata.xml
These files may be available here:
\\?\C:\ProgramData\Microsoft\Windows\WER\ReportArchive\AppCrash_vim.exe_aea879d8a26ec452e7c8965ef49ab4c8711edb_32c84bb0_78c8fc2c-acf2-4c6c-b23e-db9f204cb8e1
Analysis symbol:
Rechecking for solution: 0
Report Id: 45ce53a8-375e-4ff8-ae02-5f6142d77c9d
Report Status: 2147487744
Hashed bucket: 09305fb3a3c1d5c648360f5c3015aeb1
Cab Guid: 0
Expected behaviour
It shouldn't run and crash.
Version of Vim
9.0.2081
Environment
OS: Windows 11 23H2 ARM64
Terminal: Windows Terminal
Shell: cmd.exe
Compiler used to compile vim: Microsoft (R) C/C++ Optimizing Compiler Version 19.37.32825 for ARM64
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Am 29.10.2023 um 19:37 schrieb Wilhelm Payne <vim-dev...@256bit.org>:
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_dev/vim/vim/issues/13453%40github.com.
Dominique Pelle
I'm not a Windows person, but I think Visual Studio now integrates with asan (address sanitizer).
See: https://devblogs.microsoft.com/cppblog/addresssanitizer-asan-for-windows-with-msvc/
So can you try to build with asan? If there is invalid memory access, it should be much better information to allow developers to understand the issue.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Wilhelm Payne
I did try to build with asan but it appears that right now it is not available on ARM64 versions of Windows yet. Should I build with debugging instead and see if I can get some information on what's going on that way?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Wilhelm Payne
I build vim with nmake -f Make_mvc.mak DEBUG=yes MAP=yes and lo and behold, it works fine with debugging enabled.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
How about running vim.exe on the Visual Studio's debugger? It should detect the crash even without asan.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Wilhelm Payne
I just did, and it show me where in the code vim crashed.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Do you have some more information please? Stack trace? error message?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
This line?
https://github.com/vim/vim/blob/1bf1bf569b96d2f9b28e0cce0968ffbf2fb80aac/src/os_win32.c#L7004
I have no idea why the crash occurs in this line. Optimization bug in VC++ ARM compiler?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Wilhelm Payne
That is the correct line of code though, it looks innocuous to me but this didn't happen when I compiled it a few months ago for ARM64.
Stack trace is:
vim64.dll!write_chars(unsigned char * pchBuf, unsigned long cbToWrite) Line 7004
at C:\tools\c\viminst\vim\src\os_win32.c(7004)
vim64.dll!mch_write(unsigned char * s, int len) Line 7144
at C:\tools\c\viminst\vim\src\os_win32.c(7144)
[Inline Frame] vim64.dll!ui_write(unsigned char *) Line 52
at C:\tools\c\viminst\vim\src\ui.c(52)
vim64.dll!out_flush() Line 2736
at C:\tools\c\viminst\vim\src\term.c(2736)
[Inline Frame] vim64.dll!out_char(unsigned int) Line 2813
at C:\tools\c\viminst\vim\src\term.c(2813)
vim64.dll!screen_char(unsigned int off, int row, int col) Line 1997
at C:\tools\c\viminst\vim\src\screen.c(1997)
vim64.dll!screen_fill(int start_row, int end_row, int start_col, int end_col, int c1, int c2, int attr) Line 2279
at C:\tools\c\viminst\vim\src\screen.c(2279)
[Inline Frame] vim64.dll!disable_regexp_timeout() Line 73
at C:\tools\c\viminst\vim\src\regexp.c(73)
vim64.dll!win_update(window_S * wp) Line 2728
at C:\tools\c\viminst\vim\src\drawscreen.c(2728)
vim64.dll!update_screen(int type_arg) Line 324
at C:\tools\c\viminst\vim\src\drawscreen.c(324)
vim64.dll!main_loop(int cmdwin, int noexmode) Line 1451
at C:\tools\c\viminst\vim\src\main.c(1451)
vim64.dll!vim_main2() Line 899
at C:\tools\c\viminst\vim\src\main.c(899)
vim64.dll!VimMain(int argc, char * * argv) Line 441
at C:\tools\c\viminst\vim\src\main.c(441)
vim.exe!00007ff665b2eb20()
vim.exe!00007ff665b220c0()
vim.exe!00007ff665b2215c()
kernel32.dll!00007ff907f82310()
ntdll.dll!00007ff90931577c()
Error message is: Exception thrown at 0x00007FF87726241C (vim64.dll) in vim.exe: 0xC0000005: Access violation writing location 0x0000676F774E5494
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
that part of the code hasn't changed in years. I suppose it's a compiler bug on ARM then.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Wilhelm Payne
Yes, and when optimizing for space it seems to compile and work fine, perhaps a change in the makefile is warranted so that when compiling on ARM64 on MSVC it defaults to optimizing for space.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Did that happen with the default Makefile? And what changes would you then suggest? And can we make sure, this only applies when compiling for ARM?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Wilhelm Payne
It did happen with the default Make_mvc.mak makefile that I've always used to compile with MSVC. Up until four or five months ago it worked fine on ARM64. I don't know how to write makefiles but if they include conditionals then perhaps there is a way to set the makefile up so that if it is an arm64 system it would set OPTIMIZE=SPACE as a default as then it compiles and works fine. Other than that I don't really know.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
There is another way to change the optimization settings:
https://learn.microsoft.com/en-us/cpp/preprocessor/optimize?view=msvc-170
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
I haven't tried, but how about the following patch?
--- a/src/os_win32.c +++ b/src/os_win32.c @@ -6902,6 +6902,9 @@ cursor_visible(BOOL fVisible) } +# if defined(_MSC_VER) && defined(_M_ARM64) +# pragma optimize("t", off) +# endif /* * Write "cbToWrite" bytes in `pchBuf' to the screen. * Returns the number of bytes actually written (at least one). @@ -7010,6 +7013,9 @@ write_chars( return written; } +# if defined(_MSC_VER) && defined(_M_ARM64) +# pragma optimize("", on) +# endif static char_u * get_seq(
Not sure if optimize("t", off) is correct. It can be optimize("", off) or optimize("s", on)?
And it might be better to check more detail compiler version...
https://dev.to/yumetodo/list-of-mscver-and-mscfullver-8nd
E.g.: # if defined(_MSC_VER) && (_MSC_VER == 1937) && defined(_M_ARM64)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Dominique Pelle
Bugs triggered when enabling optimization can often be caused by undefined behaviors.
I understand asan is not available on Windows for ARM but perhaps ubsan is.
And undefined behaviors may in fact be found on Windows x86_64 with ubsan even if they do not cause problems.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Saleem Abdulrasool
@k-takata unfortunately, that doesn't seem to resolve the issue for me.
This seems to be located within:
while (g_coord.X > g_srScrollRegion.Right) { g_coord.X -= (SHORT) Columns; if (g_coord.Y < g_srScrollRegion.Bottom) g_coord.Y++; }
0:000> ?? g_coord
struct _COORD
+0x000 X : 0n120
+0x002 Y : 0n1
0:000> ?? g_srScrollRegion
struct _SMALL_RECT
+0x000 Left : 0n0
+0x002 Top : 0n0
+0x004 Right : 0n119
+0x006 Bottom : 0n29
0:000> ?? Columns
long 0n120
(1e7c.5cc): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
vim64!write_chars+0x4bc:
00007ff9`f87208a4 78286ad7 strh w23,[x22,x8]
0:000> r x8
x8=ffffcc8900010000
0:000> r x22
x22=00007ff9f898eac4
The value in x8 seems suspect, an offset of -56586194059264 seems rather unlikely. Reading the disassembly around this area:
00007ff9`f8720870 690340b9 ldr w9, [x27] 00007ff9`f8720874 d76aeb78 ldrsh w23, [x22, x11] 00007ff9`f8720878 8c02094b sub w12, w20, w9 00007ff9`f872087c 943d0013 sxth w20, w12 00007ff9`f8720880 0b0b85d2 mov x11, #0x2858 00007ff9`f8720884 d46a2b78 strh w20, [x22, x11] 00007ff9`f8720888 ff020a6b cmp w23, w10 00007ff9`f872088c 6a000054 bge vim64!write_chars+0x4b0 (7ff9f8720898) 00007ff9`f8720890 eb060011 add w11, w23, #1 00007ff9`f8720894 773d0013 sxth w23, w11 00007ff9`f8720898 1fa12c6b cmp w8, w12, sxth #0 00007ff9`f872089c ebfeff54 blt vim64!write_chars+0x490 (7ff9f8720878) 00007ff9`f87208a0 e80740f9 ldr x8, [sp, #8] 00007ff9`f87208a4 d76a2878 strh w23, [x22, x8]
However, the load at x8 is particularly interesting!
0:000> r sp
sp=000000e0a06fede0
0:000> dd 0x000000e0a06fede8
000000e0`a06fede8 00010000 ffffcc89 f8993687 00007ff9
000000e0`a06fedf8 00000762 00000000 00000078 00000000
000000e0`a06fee08 f898eac4 00007ff9 00000763 00000000
000000e0`a06fee18 f8993686 00007ff9 f8955cd8 00007ff9
000000e0`a06fee28 f8997000 00007ff9 a06fee70 000000e0
000000e0`a06fee38 f871fef8 00007ff9 a06fee70 000000e0
000000e0`a06fee48 97956be8 00000767 00000000 ffffffff
000000e0`a06fee58 00000000 00000001 f8993dea 00007ff9
Here we see (LE) the 0xffffcc8900010000. If we re-consider the type layout:
0:000> dt COORD
vim64!COORD
+0x000 X : Int2B
+0x002 Y : Int2B
This would match what we expect given the previous inspection - a pair of shorts: (0, 1). This feels like an indirection thing - [x8] would be the the value, x8 would be a pointer. So, why is the pointer being indirected off of x22?
00007ff9`f87204b0 761300d0 adrp x22, vim64!debug_skipped (7ff9f898e000)
00007ff9`f87204b4 d6122b91 add x22, x22, #0xAC4 (7ff9f898eac4 = vim64!g_attrCurrent)
The g_attrCurrent is a bit unexpected, however, given the layout of the code, I wouldn't be surprised to have g_coord near by in the .bss as it is the nearest BSS entry within the TU, but this makes me worry that there is some aliasing going on, which smells like a miscompile. I think that it could be useful to run this under AppVerifier and see if that helps catch an errant read/write. The ASAN/UBSAN shadow memory would be useful but doesn't seem to be available yet.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Saleem Abdulrasool
I really think that this might be a MSVC bug. I need to test clang-cl still, but a small patch that works around the issue:
diff --git a/src/os_win32.c b/src/os_win32.c
index 2bf0fe712..51c1aaf58 100644
--- a/src/os_win32.c
+++ b/src/os_win32.c
@@ -156,7 +156,7 @@ static HANDLE g_hConOut = INVALID_HANDLE_VALUE;
// Win32 Screen buffer,coordinate,console I/O information
static SMALL_RECT g_srScrollRegion;
-static COORD g_coord; // 0-based, but external coords are 1-based
+static COORD g_coord = {0, 0}; // 0-based, but external coords are 1-based
// The attribute of the screen when the editor was started
static WORD g_attrDefault = 7; // lightgray text on black background
The difference is that the explicit initialisation wiil push this from .bss to .data. However, the code generated does seem to be correct now:
00007ffc`50da084c 4a0fc379 ldrsh w10, [x26, #0x186] 00007ffc`50da0850 8b02094b sub w11, w20, w9 00007ffc`50da0854 743d0013 sxth w20, w11 00007ffc`50da0858 14030079 strh w20, [x24] 00007ffc`50da085c ff020a6b cmp w23, w10 ; if (g_coord.y >= g_srScrollRegion.Bottom) 00007ffc`50da0860 6a000054 bge vim64!write_chars+0x4c4 (7ffc50da086c) ; goto ... 00007ffc`50da0864 ec060011 add w12, w23, #1 ; g_coord.Y++ 00007ffc`50da0868 973d0013 sxth w23, w12
The code is properly doing the math on the word rather than quad, and sexting the half to a short (sxth). Additionally, x24 is loaded properly now!
00007ffc`50da0640 b81300f0 adrp x24, vim64!first_autopat+0x220 (7ffc51017000) 00007ffc`50da0644 18332491 add x24, x24, #0x90C (7ffc5101790c = vim64!g_coord)
I thought that what I saw previously was an artifact of release mode builds, but I suspect that this is actually an aliasing issue. I wonder if it is caused by the LTCG as that can coalesce storage, which matches the fact that this only occurs in OPTIMIZE=SPACE. Verified that using /LTCG:OFF does in fact resolve the issue.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
K.Takata
Could you create a PR, then?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Saleem Abdulrasool
Sure, happy to create a PR for this, just didn't know it was acceptable enough as a workaround. I assume that the workaround of pushing it to .data instead of .bss is sufficient (as opposed to just disabling LTCG).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #13453 as completed via 38bea30.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.