LineageOS build interrupted by Segmentation Fault on Debian 10

[Quuxplusone]

Bugzilla Link	PR45692
Status	NEW
Importance	P normal
Reported by	Clayton (claytonk@gmx.com)
Reported on	2020-04-27 02:03:25 -0700
Last modified on	2020-04-28 23:43:59 -0700
Version	5.0
Hardware	PC Linux
CC	dimitry@andric.com, htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments	runtime-7e506f.sh (13897 bytes, application/x-shellscript) xai-runtime-7e506f.cpp (813315 bytes, text/x-c++src) runtime-7e506f-a.cpp.gz (610196 bytes, application/gzip) runtime-7e506f-b.cpp.gz (669723 bytes, application/gzip)
Blocks
Blocked by
See also

Created attachment 23404
build log

[Quuxplusone]

Attached runtime-7e506f.sh (13897 bytes, application/x-shellscript): build log

[Quuxplusone]

This bug filed in accordance with instructions from build script:

clang++.real: error: unable to execute command: Segmentation fault
clang++.real: error: clang frontend command failed due to signal (use -v to see
invocation)
Android clang version 5.0.300080  (based on LLVM 5.0.300080)
Target: x86_64--linux-gnu
Thread model: posix
InstalledDir: prebuilts/clang/host/linux-x86/clang-4053586/bin
clang++.real: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang++.real: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang++.real: note: diagnostic msg: /tmp/runtime-7e506f.cpp
clang++.real: note: diagnostic msg: /tmp/runtime-7e506f.sh
clang++.real: note: diagnostic msg:

********************
[ 78% 73261/93313] //art/runtime:libartd clang++ verifier/method_verifier.cc
[linux]
ninja: build stopped: subcommand failed.
02:53:01 ninja failed with: exit status 1

#### failed to build some targets (05:42:30 (hh:mm:ss)) ####

[Quuxplusone]

This clang version is very old, so it is not really likely you will get any fixes for it. Then again, maybe you can convince your toolchain supplier to apply a patch.

That said, you need to gather the two files it has dropped in /tmp, runtime-7e506f.cpp and runtime-7e506f.sh, and attach them to this PR.

[Quuxplusone]

I should also mention, for posterity and search engines, that this is a
bullhead build of LineageOS 15.1.

> This clang version is very old, so it is not really likely you will get any
> fixes for it. Then again, maybe you can convince your toolchain supplier to
> apply a patch.

It is my impression that LineageOS is a thin layer over top of AOSP (Android
Open Source Project) and the clang is almost certainly coming from Google.
Whom, every time I have checked in the past, just ignore me. (And I try to
ignore them where I can, but there seems to be no good alternative to Android
as yet....)

> That said, you need to gather the two files it has dropped in /tmp,
> runtime-7e506f.cpp and runtime-7e506f.sh, and attach them to this PR.

Already done:
* runtime-7e506f.sh = attachment 23404
* runtime-7e506f.cpp (last ~10% / ~700M) = attachment 23405

This might be an intermittent issue. Let me know if you have all the forensics
you need, and if so, I will blow this build away and try again.

[Quuxplusone]

(In reply to Clayton from comment #4)
> Already done:
> * runtime-7e506f.sh = attachment 23404 [details]
> * runtime-7e506f.cpp (last ~10% / ~700M) = attachment 23405 [details]

Unfortunately the full .cpp file is required, otherwise it is not reproducible.
Can you please use e.g. xz -9 or gzip -9 to compress the file, then attach it?

[Quuxplusone]

Attached xai-runtime-7e506f.cpp (813315 bytes, text/x-c++src): cpp build log

[Quuxplusone]

Attached runtime-7e506f-a.cpp.gz (610196 bytes, application/gzip): runtime-7e506f.cpp (first half)

[Quuxplusone]

Attached runtime-7e506f-b.cpp.gz (669723 bytes, application/gzip): runtime-7e506f.cpp (2nd half)

[Quuxplusone]

> Unfortunately the full .cpp file is required, otherwise it is not
> reproducible. Can you please use e.g. xz -9 or gzip -9 to compress the file,
> then attach it?

Done, in two parts! (A gzip of the whole file still exceeded 1M.)