ld.lld crashed

Question

ld.lld crashed

calvin2021y opened this issue 7 months ago · comments

calvin2021y commented 7 months ago

 #0 0x00007f9b0c15dd8f llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/opt/local/mingw/bin/../lib/libLLVM-17.so+0x88ad8f)
 #1 0x00007f9b0c15b804 (/opt/local/mingw/bin/../lib/libLLVM-17.so+0x888804)
 #2 0x00007f9b0b513fd0 (/lib/x86_64-linux-gnu/libc.so.6+0x3bfd0)
 #3 0x00007f9b0c0e4a0f _ZN4llvm7hashing6detail23hash_combine_range_implIKcEENSt9enable_ifIXsrNS1_16is_hashable_dataIT_EE5valueENS_9hash_codeEE4typeEPS6_SB_ (/opt/local/mingw/bin/../lib/libLLVM-17.so+0x811a0f)
 #4 0x00007f9b0c0e50c0 llvm::DenseMapInfo<llvm::StringRef, void>::getHashValue(llvm::StringRef) (/opt/local/mingw/bin/../lib/libLLVM-17.so+0x8120c0)
 #5 0x00005620e7653b3b lld::coff::LinkerDriver::fixupExports() (/opt/x/test/sdks/linux.x86_64/mingw/bin/ld.lld+0xf4b3b)
 #6 0x00005620e7649403 lld::coff::LinkerDriver::linkerMain(llvm::ArrayRef<char const*>) (/opt/x/test/sdks/linux.x86_64/mingw/bin/ld.lld+0xea403)
 #7 0x00005620e764bace lld::coff::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) (/opt/x/test/sdks/linux.x86_64/mingw/bin/ld.lld+0xecace)
 #8 0x00005620e79adf28 lld::mingw::link(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) (/opt/x/test/sdks/linux.x86_64/mingw/bin/ld.lld+0x44ef28)
 #9 0x00005620e7616cca lld::unsafeLldMain(llvm::ArrayRef<char const*>, llvm::raw_ostream&, llvm::raw_ostream&, llvm::ArrayRef<lld::DriverDef>, bool) (/opt/x/test/sdks/linux.x86_64/mingw/bin/ld.lld+0xb7cca)
#10 0x00005620e761642e lld_main(int, char**, llvm::ToolContext const&) (/opt/x/test/sdks/linux.x86_64/mingw/bin/ld.lld+0xb742e)
#11 0x00005620e7614765 main (/opt/x/test/sdks/linux.x86_64/mingw/bin/ld.lld+0xb5765)
#12 0x00007f9b0b4ff1ca __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:74:3
#13 0x00007f9b0b4ff285 call_init ./csu/../csu/libc-start.c:128:20
#14 0x00007f9b0b4ff285 __libc_start_main ./csu/../csu/libc-start.c:347:5
#15 0x00005620e7615c6e _start (/opt/x/test/sdks/linux.x86_64/mingw/bin/ld.lld+0xb6c6e)

calvin2021y commented 7 months ago

17.0.6

Martin Storsjö · Answer 1 · Sat Jan 13 2024 00:17:35 GMT+0800 (China Standard Time)

Sorry, the backtrace itself doesn't help much for being able to fix the issue - we would need a way to actually reproduce the error as well.

In order to do that, you can add the linker argument -Wl,--reproduce=repro.tar, which produces a file repro.tar which contains all input files. By sharing this file somehow, we should be able to reproduce exactly this scenario, hopefully being able to reproduce the error in order to actually analyze and potentially fix it.

calvin2021y · Answer 2 · Sat Jan 13 2024 00:26:53 GMT+0800 (China Standard Time)

File size too big to upload after compressed, can you message me your email I will send it to you ?

Martin Storsjö · Answer 3 · Sat Jan 13 2024 00:30:06 GMT+0800 (China Standard Time)

My email is martin@martin.st - although I'm not a fan of very large attachments in the mail (how large is it?) if possible to transfer otherwise - are you able to upload it somewhere temporarily?

Biswapriyo Nath · Answer 4 · Sat Jan 13 2024 00:31:43 GMT+0800 (China Standard Time)

Would it be possible to compress the tar file?

calvin2021y · Answer 5 · Sun Jan 14 2024 13:05:19 GMT+0800 (China Standard Time)

sorry for late reply, I just email to you mailbox with attachment repro.tar.gz.

Martin Storsjö · Answer 6 · Sun Jan 14 2024 19:16:48 GMT+0800 (China Standard Time)

sorry for late reply, I just email to you mailbox with attachment repro.tar.gz.

I haven't received that mail, sorry. (I did check the spam folders.) How big is the attachment? Is it possible to upload/transfer it via some file sharing service?

calvin2021y · Answer 7 · Mon Jan 15 2024 12:59:34 GMT+0800 (China Standard Time)

Not sure why you are not get it, my mail server said it send success.

It is 28M after gzip -9, now I use tar -cJf repro.tar.xz repro.tar.

github not allow upload .xz file, so I rename it to repro.tar.gz, after download you may need rename it to repro.tar.xz before decompress

Martin Storsjö · Answer 8 · Mon Jan 15 2024 18:30:43 GMT+0800 (China Standard Time)

Not sure why you are not get it, my mail server said it send success.

It is 28M after gzip -9, now I use tar -cJf repro.tar.xz repro.tar.

github not allow upload .xz file, so I rename it to repro.tar.gz, after download you may need rename it to repro.tar.xz before decompress

repro.tar.gz

Thanks, I got this now, and I can reproduce the issue. It doesn't show up when running with address sanitizer, but it does show up in regular builds. So not very clear what is wrong, but I should be able to take it from here, thanks for the report and reproducer!

Martin Storsjö · Answer 9 · Thu Jan 18 2024 22:51:54 GMT+0800 (China Standard Time)

I've analyzed the issue and filed an upstream report for it now: llvm/llvm-project#78591

calvin2021y · Answer 10 · Fri Jan 19 2024 12:58:44 GMT+0800 (China Standard Time)

Thanks for the hard work.

Martin Storsjö · Answer 11 · Wed Jan 31 2024 04:25:12 GMT+0800 (China Standard Time)

A prerelease with LLVM 18.1.0 RC 1 is out now, at https://github.com/mstorsjo/llvm-mingw/releases/tag/20240130, where this issue should be fixed.

calvin2021y · Answer 12 · Fri Feb 09 2024 23:04:15 GMT+0800 (China Standard Time)

thanks for the great work. I will test and update next week.

calvin2021y · Answer 13 · Wed Feb 14 2024 13:38:50 GMT+0800 (China Standard Time)

confirm fixed with the library build by clang-17.