``` Reading symbols from ./unittest... (gdb) r Starting program: /var/tmp/portage/dev-util/ccache-4.10.1/work/ccache-4.10.1_build/unittest/unittest [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. std::basic_ios<wchar_t, std::char_traits<wchar_t> >::init (this=this@entry=0x7ffff78c7008 <std::wcout+8>, __sb=0x7ffff78c6940 <__gnu_internal::buf_wcout_sync>) at /usr/src/debug/sys-devel/gcc-15.0.9999/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:150 150 _M_fill = _M_ctype->widen(' '); (gdb) bt #0 std::basic_ios<wchar_t, std::char_traits<wchar_t> >::init (this=this@entry=0x7ffff78c7008 <std::wcout+8>, __sb=0x7ffff78c6940 <__gnu_internal::buf_wcout_sync>) at /usr/src/debug/sys-devel/gcc-15.0.9999/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_ios.tcc:150 #1 0x00007ffff76d0897 in std::basic_ostream<wchar_t, std::char_traits<wchar_t> >::basic_ostream (this=<optimized out>, __sb=<optimized out>, __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at /usr/src/debug/sys-devel/gcc-15.0.9999/build/x86_64-pc-linux-gnu/libstdc++-v3/include/ostream:93 #2 std::ios_base::Init::Init (this=0x7ffff78c6db0 <std::__ioinit>) at /usr/src/debug/sys-devel/gcc-15.0.9999/gcc-15.0.9999/libstdc++-v3/src/c++98/ios_init.cc:106 #3 std::ios_base::Init::Init (this=this@entry=0x7ffff78c6db0 <std::__ioinit>) at /usr/src/debug/sys-devel/gcc-15.0.9999/gcc-15.0.9999/libstdc++-v3/src/c++98/ios_init.cc:78 #4 0x00007ffff76ac5b0 in __static_initialization_and_destruction_0 () at /usr/src/debug/sys-devel/gcc-15.0.9999/gcc-15.0.9999/libstdc++-v3/src/c++98/ios_base_init.h:12 #5 _GLOBAL__sub_I.00090_globals_io.cc(void) () at /usr/src/debug/sys-devel/gcc-15.0.9999/gcc-15.0.9999/libstdc++-v3/src/c++98/globals_io.cc:109 #6 0x00007ffff7fca87e in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffe298, env=env@entry=0x7fffffffe2a8) at dl-init.c:74 #7 0x00007ffff7fca983 in call_init (l=<optimized out>, argc=<optimized out>, argv=<optimized out>, env=<optimized out>) at dl-init.c:120 #8 _dl_init (main_map=0x7ffff7ffe2e0, argc=1, argv=0x7fffffffe298, env=0x7fffffffe2a8) at dl-init.c:121 #9 0x00007ffff7fe5830 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #10 0x0000000000000001 in ?? () #11 0x00007fffffffe507 in ?? () #12 0x0000000000000000 in ?? () ```
``` # valgrind ./unittest ==678830== Memcheck, a memory error detector ==678830== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al. ==678830== Using Valgrind-3.24.0.GIT and LibVEX; rerun with -h for copyright info ==678830== Command: ./unittest ==678830== ==678830== Invalid read of size 8 ==678830== at 0x4EBF92E: widen (locale_facets.h:297) ==678830== by 0x4EBF92E: std::basic_ios<wchar_t, std::char_traits<wchar_t> >::init(std::basic_streambuf<wchar_t, std::char_traits<wchar_t> >*) (basic_ios.tcc:150) ==678830== by 0x4E41896: basic_ostream (ostream:93) ==678830== by 0x4E41896: Init (ios_init.cc:106) ==678830== by 0x4E41896: std::ios_base::Init::Init() (ios_init.cc:78) ==678830== by 0x4E1D5AF: UnknownInlinedFun (ios_base_init.h:12) ==678830== by 0x4E1D5AF: _GLOBAL__sub_I.00090_globals_io.cc (globals_io.cc:109) ==678830== by 0x400487D: call_init.part.0 (dl-init.c:74) ==678830== by 0x4004982: call_init (dl-init.c:120) ==678830== by 0x4004982: _dl_init (dl-init.c:121) ==678830== by 0x401F82F: ??? (in /usr/lib64/ld-linux-x86-64.so.2) ==678830== Address 0x43 is not stack'd, malloc'd or (recently) free'd ```
I have a feeling this might be because I just tried mold, actually...
Yeah, building ccache with bfd works.
I think it's related to -static-libstdc++ in our ebuild for ccache but I haven't yet reproduced it manually.
Ah, mold use was being overridden by cmake/FindFastestLinker.cmake. The key is indeed -static-libstdc++. In a git checkout of `v4.10.2`: ``` $ export CFLAGS="-O3" CXXFLAGS="-O3" $ export LDFLAGS="-fuse-ld=mold -static-libstdc++" $ cmake -B build -S . -GNinja -G Ninja -DDISABLE_FASTEST_LINKER=ON $ ninja -C build $ build/unittest/unittest # crash ```
(In reply to Sam James from comment #5) > $ cmake -B build -S . -GNinja -G Ninja -DDISABLE_FASTEST_LINKER=ON Needs an additional -DWARNINGS_AS_ERRORS=OFF to build, otherwise it might die on libfmt. With that it builds & passes the test using gcc-14.2.0 + mold-2.23.
(In reply to Holger Hoffstätte from comment #6) > mold-2.23. *2.33*
It only shows up if I build GCC 15 with mold too. It bisects to r15-510-g23ef0f68ad5fca (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704).
As an aside and regardless of the underlying cause of the crash I was wondering a bit more about the issue of multiple libstdc++ instances, both statically and dynamically linked. The original motivation for linking ccache statically still seems valid, but to me somehow seems moot as long as other libs pull in libstdc++ dynamically..or is it? As mentioned on IRC it's easy to use bundled libfmt. I gave it a try and as it turns out then it's cpp-httplib's turn to pull in libstdc++. With those two set to bundled, the dependency is gone. Executable size increased by a mere ~40k. Also we have two fewer dependencies - always good for toolchain parts (see cmake vs. json-cpp requiring each other). Would this be a useful change? If so I can file a separate bug and make a patch.
I think this is essentially fixed by bug 938011.
