Multiple ccalls to jl_get_UNAME in base/c.jl causes AppVeyor to SIGABRT

[ararslan]

The second ccall in following change triggers a SIGABRT on AppVeyor:

diff --git a/base/c.jl b/base/c.jl
index 3385e18b4e..c3459a3d0a 100644
--- a/base/c.jl
+++ b/base/c.jl
@@ -18,7 +18,7 @@ Equivalent to the native `char` c-type.
 """
 Cchar
 
-if is_windows()
+if ccall(:jl_get_UNAME, Any, ()) === :NT
     const Clong = Int32
     const Culong = UInt32
     const Cwchar_t = UInt16
@@ -49,7 +49,7 @@ Equivalent to the native `wchar_t` c-type ([`Int32`](@ref)).
 """
 Cwchar_t
 
-if !is_windows()
+if ccall(:jl_get_UNAME, Any, ()) !== :NT
     const sizeof_mode_t = ccall(:jl_sizeof_mode_t, Cint, ())
     if sizeof_mode_t == 2
         const Cmode_t = Int16
@@ -118,7 +118,7 @@ end
 # symbols are guaranteed not to contain embedded NUL
 convert(::Type{Cstring}, s::Symbol) = Cstring(unsafe_convert(Ptr{Cchar}, s))
 
-if is_windows()
+if ccall(:jl_get_UNAME, Any, ()) === :NT
 """
     Base.cwstring(s)

The error portion of the log:

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

signal (22): SIGABRT
while loading c.jl, in expression starting on line 53
raise at C:\windows\SYSTEM32\msvcrt.dll (unknown line)
abort at C:\windows\SYSTEM32\msvcrt.dll (unknown line)
.text at C:\projects\julia\usr\bin\libjulia.dll (unknown line)
__assert at C:\projects\julia\usr\bin\libjulia.dll (unknown line)
runtime_sym_gvs<LazyModule<emit_plt(llvm::FunctionType*, const llvm::AttributeSet&, llvm::CallingConv::ID, char const*, char const*)::<lambda()> >&> at C:/projects/julia/src\ccall.cpp:100 [inlined]
emit_plt at C:/projects/julia/src\ccall.cpp:316 [inlined]
emit_a_ccall at C:/projects/julia/src\ccall.cpp:2048
emit_ccall at C:/projects/julia/src\ccall.cpp:1870
emit_expr at C:/projects/julia/src\codegen.cpp:4002
emit_assignment at C:/projects/julia/src\codegen.cpp:3681 [inlined]
emit_expr at C:/projects/julia/src\codegen.cpp:4005
emit_stmtpos at C:/projects/julia/src\codegen.cpp:3907 [inlined]
emit_function at C:/projects/julia/src\codegen.cpp:5981
jl_compile_linfo at C:/projects/julia/src\codegen.cpp:1171
jl_compile_for_dispatch at C:/projects/julia/src\gf.c:1670
jl_compile_method_internal at C:/projects/julia/src\julia_internal.h:337 [inlined]
jl_call_method_internal at C:/projects/julia/src\julia_internal.h:384 [inlined]
jl_toplevel_eval_flex at C:/projects/julia/src\toplevel.c:594
jl_parse_eval_all at C:/projects/julia/src\ast.c:908
jl_load at C:/projects/julia/src\toplevel.c:620 [inlined]
jl_load_ at C:/projects/julia/src\toplevel.c:627
include at .\sysimg.jl:21
unknown function (ip: 0693C0B7)
jl_call_fptr_internal at C:/projects/julia/src\julia_internal.h:369 [inlined]
jl_call_method_internal at C:/projects/julia/src\julia_internal.h:388 [inlined]
jl_apply_generic at C:/projects/julia/src\gf.c:1928
do_call at C:/projects/julia/src\interpreter.c:66
eval at C:/projects/julia/src\interpreter.c:246
jl_interpret_toplevel_expr_in at C:/projects/julia/src\interpreter.c:46
jl_toplevel_eval_flex at C:/projects/julia/src\toplevel.c:582
jl_eval_module_expr at C:/projects/julia/src\toplevel.c:204
jl_toplevel_eval_flex at C:/projects/julia/src\toplevel.c:482
jl_parse_eval_all at C:/projects/julia/src\ast.c:908
jl_load at C:/projects/julia/src\toplevel.c:620
exec_program at C:/projects/julia/ui\repl.c:35
true_main at C:/projects/julia/ui\repl.c:125
wmain at C:/projects/julia/ui\repl.c:250
___tmainCRTStartup at C:\projects\julia\usr\bin\julia.exe (unknown line)
BaseThreadInitThunk at C:\windows\SYSTEM32\KERNEL32.DLL (unknown line)
RtlInitializeExceptionChain at C:\windows\SYSTEM32\ntdll.dll (unknown line)
RtlInitializeExceptionChain at C:\windows\SYSTEM32\ntdll.dll (unknown line)
Allocations: 942240 (Pool: 942229; Big: 11); GC: 5
Assertion failed!

Full log: https://gist.github.com/ararslan/5a023867d8f58b241b015fd20ec93def

[tkelman]

would @static fix this?

[ararslan]

Using that in #22182 seems to have gotten around it. As of this writing CI on that PR hasn't finished, but AV has at least gotten well beyond the point at which it failed with SIGABRT when I tried it without @static. Edit: AV finished and passed.

So it's likely that @static is a good solution for this, but it would still be good to know what the underlying issue with it is.

[gbaraldi]

Do we still care about this @ararslan

[vtjnash]

Seems unlikely we could still reproduce this after a lot of changes