On Tue, Apr 29, 2025 at 08:44:50PM +0200, Dimitry Andric wrote: > On 29 Apr 2025, at 19:43, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > > > > On Sun, Apr 27, 2025 at 07:42:44PM +0200, Dimitry Andric wrote: > >> On 27 Apr 2025, at 17:04, Shawn Webb <shawn.w...@hardenedbsd.org> wrote: > >>> > >>> On Sat, Apr 26, 2025 at 06:06:54PM +0200, Dimitry Andric wrote: > >> ... > >>>> Please let me know if you encounter any problems resulting due to this > >>>> change, as I intend to MFC it. For example, I tried covering all > >>>> incremental build scenarios, but I may have missed some corner case. > >>> > >>> Hey Dimitry, > >>> > >>> I suspect this may be a problem specific to HardenedBSD, but it looks > >>> like cc occasionally crashes. It hits an assert at > >>> /usr/src/contrib/llvm-project/clang/lib/Driver/Driver.cpp:2702. > >>> > >>> I can reproduce this by running `env SHELL=/bin/sh make buildenv` at > >>> the top of /usr/src. Though, it doesn't reproduce 100%, but perhaps > >>> around 60%. > >> > >> It's asserting on this line: > >> > >> assert(!CCGenDiagnostics && "stdin produces no crash > >> reproducer"); > >> > >> I think during make buildenv the make framework will run cc --version > >> and ld --version to get at the compiler and linker version, but it could > >> be that it's doing some weird combination that hasn't been thought of. > >> Can you get the exact command line out of the debugger? > > > > For some reason, I'm failing to figure out how to view the program's > > invocation using lldb or gdb. But, running `strings > > /usr/obj/usr/src/amd64.amd64/cc.core`, I see this, which may or may > > not be the arguments passed to cc: > > > > ==== BEGIN OUTPUT ==== > > "-cc1" "-ferror-limit" "19" "-o" "-" "-disable-free" "-E" "-x" "c" "-" > > "-tune-cpu" "generic" "-target-cpu" "x86-64" "-triple" > > "x86_64-unknown-freebsd15.0" "-resource-dir" "/usr/lib/clang/19" "-isystem" > > "/usr/lib/clang/19/include" "-internal-externc-i > > system" "/usr/include" "-std=gnu17" "-fskip-odr-check-in-gmf" > > "-ftrivial-auto-var-init=zero" "-fgnuc-version=4.2.1" "-ffp-con > > tract=on" "-fno-experimental-relative-c++-abi-vtables" > > "-fno-file-reproducible" "-O0" "-fdebug-compilation-dir=/usr/obj/usr/s > > rc/amd64.amd64" "-fcoverage-compilation-dir=/usr/obj/usr/src/amd64.amd64" > > "-faddrsig" "-mrelocation-model" "static" "-debugge > > r-tuning=gdb" "-funwind-tables=2" "-mconstructor-aliases" > > "-clear-ast-before-backend" "-main-file-name" "-" "-mframe-pointer= > > all" "-fdiagnostics-hotness-threshold=0" > > "-fdiagnostics-misexpect-tolerance=0" "-D" "__GCC_HAVE_DWARF2_CFI_ASM=1" > > ==== END OUTPUT ==== > > > > I hope that helps. Otherwise, can you provide me a hint as to how to > > get lldb/gdb to show the arguments passed to cc? > > "settings show target.run-args", but I just checked buildenv, and it really > only runs "cc --version" twice. If you do that in a loop, does it sometimes > crash?
I think that `settings show...` command only pertains to actually executing the application: ==== BEGIN OUTPUT ==== $ lldb /usr/bin/cc -c /usr/obj/usr/src/amd64.amd64/cc.core (lldb) target create "/usr/bin/cc" --core "/usr/obj/usr/src/amd64.amd64/cc.core" Core file '/usr/obj/usr/src/amd64.amd64/cc.core' (x86_64) was loaded. (lldb) settings show target.run-args target.run-args (arguments) = ==== END OUTPUT ==== Running `cc --version` does not reproduce the crash. I ran that in a loop over 200 iterations with zero crashes. I can reproduce it somewhat reliably with `env SHELL=/bin/sh make buildenv` at the top of the src tree. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Signal Username: shawn_webb.74 Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
signature.asc
Description: PGP signature
