Re: Strange problem on AMD64-current building latest zig

To: NetBSD current-users <current-users%netbsd.org@localhost>
Subject: Re: Strange problem on AMD64-current building latest zig
From: Chavdar Ivanov <ci4ic4%gmail.com@localhost>
Date: Sat, 2 Nov 2024 20:23:01 +0000
Hi,

Just for completeness, I updated LLVM and friends to 19.1.3 today, as
well as rebuilt the system a couple of days ago; the problem with zig2
remains the same under AMD64, whereas it is still OK on the same
version under AARCH64.

I guess not many NetBSD developers are that much interested in
this,zig is developing at a fast rate and btw I am not able to build
the latest versions under either Free or OpenBSD (for different
reasons, but still...), so in this case NetBSD is best, it still runs
it fine on AARCH64... There are from time to time similar reports on
the zig issues page regarding debitrotting the *bsd ports, so far I
haven't seen a response to this one either.

Chavdar

BTW, the trace is as  follows, if it is of interest:

Core was generated by `zig2'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000007b892e in
codegen_llvm_Builder_Global_Index_getReplacement__13849 ()
[Current thread is 1 (process 1450)]
(gdb) bt
#0  0x00000000007b892e in
codegen_llvm_Builder_Global_Index_getReplacement__13849 ()
#1  0x0000000000795ff0 in codegen_llvm_Builder_Global_Index_unwrap__13825 ()
#2  0x0000000000b82b25 in codegen_llvm_Builder_Global_Index_name__13829 ()
#3  0x0000000000d532c2 in
codegen_llvm_Builder_Global_Index_renameAssumeCapacity__13846 ()
#4  0x000000000093d835 in codegen_llvm_Builder_Global_Index_rename__13841 ()
#5  0x0000000000963f5f in codegen_llvm_Object_updateExportedGlobal__10746 ()
#6  0x000000000072d783 in codegen_llvm_Object_updateExports__10744 ()
#7  0x00000000009524a7 in link_Elf_updateExports__3869 ()
#8  0x000000000072c9ad in link_File_updateExports__3787 ()
#9  0x00000000005ba14e in Zcu_PerThread_processExportsInner__8773 ()
#10 0x00000000004c3f5f in Zcu_PerThread_processExports__8771 ()
#11 0x00000000004d23ab in Compilation_update__4115 ()
#12 0x00000000008a492b in Compilation_updateSubCompilation__4195 ()
#13 0x00000000008eb4c6 in Compilation_buildOutputFromZig__4196 ()
#14 0x0000000000fe1a72 in Compilation_buildRt__4161 ()
#15 0x0000000000c2b97f in
Thread_WaitGroup_spawnManager__anon_103357_Manager_run__64153 ()
#16 0x00000000013ab19d in Thread_callFn__anon_291573__87615 ()
#17 0x0000000000fe19a7 in
Thread_PosixThreadImpl_spawn__anon_234460_Instance_entryFn__80628 ()
#18 0x00007156de1f7145 in ?? () from /usr/lib/libpthread.so.1
#19 0x00007156dd9af200 in ?? () from /usr/lib/libc.so.12
Backtrace stopped: Cannot access memory at address 0x7156d8ffc000
(gdb)

so mostly the same as before.


On Mon, 28 Oct 2024 at 10:57, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
>
> Repeating the process without the release optimisations and using
> gmake instead of ninja gives similar, but more verbose output:
> ....
> Thread 1 (process 18271):
> #0  codegen_llvm_Builder_Global_Index_getReplacement__13852
> (a0=2863311530, a1=0x720119f19020) at
> /home/xci/src/zig.new/build/zig2.c:648247
> #1  0x00000000007661b5 in
> codegen_llvm_Builder_Global_Index_unwrap__13828 (a0=2863311530,
> a1=0x720119f19020) at /home/xci/src/zig.new/build/zig2.c:633445
> #2  0x0000000000b5645e in
> codegen_llvm_Builder_Global_Index_name__13832 (a0=2863311530,
> a1=0x720119f19020) at /home/xci/src/zig.new/build/zig2.c:973383
> #3  0x0000000000d27ca9 in
> codegen_llvm_Builder_Global_Index_renameAssumeCapacity__13849
> (a0=2863311530, a1=2147484074, a2=0x720119f19020) at
> /home/xci/src/zig.new/build/zig2.c:1142934
> #4  0x0000000000909804 in
> codegen_llvm_Builder_Global_Index_rename__13844 (a0=2863311530,
> a1=2147484074, a2=0x720119f19020) at
> /home/xci/src/zig.new/build/zig2.c:785703
> #5  0x000000000092fea2 in
> codegen_llvm_Object_updateExportedGlobal__10749 (a0=0x720119f19010,
> a1=0x720119fe1b80, a2=2863311530, a3=...) at
> /home/xci/src/zig.new/build/zig2.c:800570
> #6  0x00000000006fd909 in codegen_llvm_Object_updateExports__10747
> (a0=0x720119f19010, a1=..., a2=..., a3=...) at
> /home/xci/src/zig.new/build/zig2.c:602456
> #7  0x000000000091e476 in link_Elf_updateExports__3867
> (a0=0x7201206a2410, a1=..., a2=..., a3=...) at
> /home/xci/src/zig.new/build/zig2.c:793223
> #8  0x00000000006fcb33 in link_File_updateExports__3785
> (a0=0x7201206a2540, a1=..., a2=..., a3=...) at
> /home/xci/src/zig.new/build/zig2.c:602139
> #9  0x000000000058dfc2 in Zcu_PerThread_processExportsInner__8769
> (a0=..., a1=0x72011aff63f0, a2=..., a3=...) at
> /home/xci/src/zig.new/build/zig2.c:482417
> #10 0x0000000000499515 in Zcu_PerThread_processExports__8767 (a0=...)
> at /home/xci/src/zig.new/build/zig2.c:409055
> #11 0x00000000004a7a7c in Compilation_update__4113 (a0=0x72012069aef0,
> a1=...) at /home/xci/src/zig.new/build/zig2.c:413088
> #12 0x0000000000873f66 in Compilation_updateSubCompilation__4193
> (a0=0x7201206d55a0, a1=0x72012069aef0, a2=14 '\016', a3=...) at
> /home/xci/src/zig.new/build/zig2.c:739926
> #13 0x00000000008baa6b in Compilation_buildOutputFromZig__4194
> (a0=0x7201206d55a0, a1=..., a2=1 '\001', a3=0x7201206d5ac0, a4=14
> '\016', a5=...) at /home/xci/src/zig.new/build/zig2.c:758145
> #14 0x0000000000fa0817 in Compilation_buildRt__4159
> (a0=0x7201206d55a0, a1=..., a2=14 '\016', a3=1 '\001',
> a4=0x7201206d5ac0, a5=...) at
> /home/xci/src/zig.new/build/zig2.c:1389996
> #15 0x0000000000c00247 in
> Thread_WaitGroup_spawnManager__anon_103569_Manager_run__64008
> (a0=0x7201206d5728, a1=...) at
> /home/xci/src/zig.new/build/zig2.c:1041691
> #16 0x0000000001374473 in Thread_callFn__anon_289814__87190 (a0=...)
> at /home/xci/src/zig.new/build/zig2.c:1722598
> #17 0x0000000000fa074c in
> Thread_PosixThreadImpl_spawn__anon_234567_Instance_entryFn__80557
> (a0=0x7201207308c0) at /home/xci/src/zig.new/build/zig2.c:1389978
> #18 0x0000720121006145 in ?? () from /usr/lib/libpthread.so.1
> #19 0x000072012091a200 in ?? () from /usr/lib/libc.so.12
> Backtrace stopped: Cannot access memory at address 0x72011affb000
> ...
>
> There are still 6 more threads in the trace , all parked.
>
> There is obviously a difference in the thread implementation under
> aarch64 and amd64 and the latter is for some reason causing the second
> stage zig2 compiler to barf out.
>
> On Sat, 26 Oct 2024 at 20:30, Chavdar Ivanov <ci4ic4%gmail.com@localhost> wrote:
> >
> > Hi,
> >
> > I have been following the development of zig for some time now,
> > building the latest versions under NetBSD-current, both amd64 and
> > aarch64. As the latest development versions require the latest llvm,
> > at present minimum 19.0, I used to build llvm (clang, lld and lldb)
> > off-pkgsrc tree as per the instructions in the zig wiki page. This
> > used to work fine on both architectures up until approx. zig 0.14
> > 0-dev.1940; Since then, about a week ago, it stopped building for me
> > under amd64, whereas it continues to build just fine under aarch64. To
> > minimize the differences, I got rid of my own llvm builds on both
> > platforms, after having seen that llvm 19.1.2 was imported into wip,
> > and rebuilt it on both platforms. I also reinstalled -current on both,
> > using exactly the same cvs tree.
> >
> > I now have on aarch64:
> > ...
> > $ uname -a
> > NetBSD ci4o2 10.99.12 NetBSD 10.99.12 (GENERIC64) #0: Sat Oct 26
> > 01:16:53 BST 2024
> > root%ym1r.lorien.lan@localhost:/bd/sysbuild/evbarm64/obj/home/sysbuild/src/sys/arch/evbarm/compile/GENERIC64
> > evbarm
> > $ clang --version
> > clang version 19.1.2 (git://wip.pkgsrc.org/pkgsrc-wip.git
> > 13dd3f5a03826db85228882a701bf76f40f114ea)
> > Target: aarch64-unknown-netbsd10.99
> > Thread model: posix
> > InstalledDir: /usr/pkg/bin
> > $ zig version
> > 0.14.0-dev.2052+6a364b4a5
> > ....
> >
> > On amd64, the second compiler stage consistently crashes the same way
> > (I tried it on different machines with the same result):
> >
> > Core was generated by `zig2'.
> > Program terminated with signal SIGSEGV, Segmentation fault.
> > #0  0x00000000007af07a in
> > codegen_llvm_Builder_Global_Index_getReplacement__13852 ()
> > [Current thread is 1 (process 20655)]
> > (gdb) bt
> > #0  0x00000000007af07a in
> > codegen_llvm_Builder_Global_Index_getReplacement__13852 ()
> > #1  0x000000000078c9e4 in codegen_llvm_Builder_Global_Index_unwrap__13828 ()
> > #2  0x0000000000b7cc8d in codegen_llvm_Builder_Global_Index_name__13832 ()
> > #3  0x0000000000d4e4d8 in
> > codegen_llvm_Builder_Global_Index_renameAssumeCapacity__13849 ()
> > #4  0x0000000000930033 in codegen_llvm_Builder_Global_Index_rename__13844 ()
> > #5  0x00000000009566d1 in codegen_llvm_Object_updateExportedGlobal__10749 ()
> > #6  0x00000000007241df in codegen_llvm_Object_updateExports__10747 ()
> > #7  0x0000000000944ca5 in link_Elf_updateExports__3867 ()
> > #8  0x0000000000723409 in link_File_updateExports__3785 ()
> > #9  0x00000000005b48e9 in Zcu_PerThread_processExportsInner__8769 ()
> > #10 0x00000000004bfe95 in Zcu_PerThread_processExports__8767 ()
> > #11 0x00000000004ce3fc in Compilation_update__4113 ()
> > #12 0x000000000089a795 in Compilation_updateSubCompilation__4193 ()
> > #13 0x00000000008e129a in Compilation_buildOutputFromZig__4194 ()
> > #14 0x0000000000fc7046 in Compilation_buildRt__4159 ()
> > #15 0x0000000000c26a76 in
> > Thread_WaitGroup_spawnManager__anon_103579_Manager_run__64010 ()
> > #16 0x000000000139aca2 in Thread_callFn__anon_289825__87192 ()
> > #17 0x0000000000fc6f7b in
> > Thread_PosixThreadImpl_spawn__anon_234578_Instance_entryFn__80559 ()
> > #18 0x0000707e9703d145 in ?? () from /usr/lib/libpthread.so.1
> > #19 0x0000707e967f5200 in ?? () from /usr/lib/libc.so.12
> > Backtrace stopped: Cannot access memory at address 0x707e90dfb000
> >
> > I have reported this issue on zig's github account
> > (https://github.com/ziglang/zig/issues/21788), with no response so far
> > - this is not the first time I do so, usually some zig developer sorts
> > it quickly enough with a standard 'Debitrot *BSD'  comment...
> >
> > I am posting this with the hope somebody would know some
> > architecture-level difference in the above and suggest some solution.
> > It is nice to follow zig's development and have it available on *BSD.
> >
> > BTW1. I tried to follow the suggestions on zig's wiki for
> > bootstrapping the compiler with llvm 19 under both Open- and FreeBSD,
> > but this also failed. On OpenBSD I wasn't even able to build llvm
> > 19.1.2, on FreeBSD if I were to use llvm19 from ports, it is not
> > capable of linking static files; whereas, if I build llvm myself, the
> > resulting third stage zig compiler link fails with missing symbols
> > from the system's libc...
> >
> > BTW2. lldb build under aarch64 always fails for me, I guess this
> > merits a pkgsrc pr, as it fails on the released pkgsrc llvm as well,
> > not only the one from wip.
> >
> > BTW3. When building zig succeeds, I run the basic test suite (zig
> > build test-behavior). It succeeds only if I remove every trace of zig
> > cache (~/.cache/zig/* and src/zig/.zig-cache/*); otherwise, many tests
> > fail because of some OS-level limit which I haven't yet been able to
> > find.
> >
> >
> > Chavdar
> >
> >
> >
> >
> >
> > --
> > ----
>
>
>
> --
> ----



-- 
----
References:
- Strange problem on AMD64-current building latest zig
  - From: Chavdar Ivanov
- Re: Strange problem on AMD64-current building latest zig
  - From: Chavdar Ivanov
Prev by Date: Re: Compiling fails on MacOS
Next by Date: Re: Sanitizers -- status & how to use?
Previous by Thread: Re: Strange problem on AMD64-current building latest zig
Next by Thread: Sanitizers -- status & how to use?
Indexes:
Home | Main Index | Thread Index | Old Index