When the "LANG" environment variable contains locale with included encoding (like "en_US.utf8" OR "en_US.UTF-8"), Execution results in SIGSEGV. when the $LANG is unset OR doesn't include an encoding (like "en_US") problem does not arise. flags: USE="X bitmap cairo doc examples gd gpic latex lua qt6 readline wxwidgets -amos (-aqua) -libcaca -libcerf -metafont -metapost -regis -tgif" LUA_SINGLE_TARGET="lua5-4 -lua5-1 -lua5-3"
fwiw: my ~amd64 works ok, but i have -lua. it also may depend on the terminal in use. i get qt as the default terminal. i've also test wxt.
It's some type of Heisenbug. It just somehow runs under the gdb without any trouble. I've compiled the source manually and bug still occurs. It looks like gnuplot SIGSEGVs before execution even hits "main" symbol. Probably some bug in shared library. edit. After running the gnuplot with "LD_DEBUG=symbols" it appears that this bug has something to do with "/usr/lib64/gconv/UTF-32.so" and symbol "gconv_end" or one after it. Sorry for sending a bug report without researching it first!
Please include emerge --info and a backtrace: https://wiki.gentoo.org/wiki/Debugging.
(In reply to Sam James from comment #3) > Please include emerge --info and a backtrace: > https://wiki.gentoo.org/wiki/Debugging. I'm unable to provide a backtrace because SIGSEGV occurs when resolving dynamic libraries. As some form of backtrace I'm able to send some last lines of stderr of "LD_DEBUG=symbols gnuplot" before SIGSEGV emerge --info: https://pastebin.com/uDfUn5um LD_DEBUG=symbols gnuplot: https://pastebin.com/aNS1TN3Z It may be an issue with sys-libs/glibc (2.40-r7) I'm also using GCC 15 (15.0.9999) but compiling with GCC 14 (14.2.1_p20241221) has comparable results
Compiling gnuplot or glibc? It's possible the loader was miscompiled. What version specifically (what commit) for gcc-15.0.9999 (run --version)? Can you hit it with any other application?
(In reply to Sam James from comment #5) > Compiling gnuplot or glibc? It's possible the loader was miscompiled. > > What version specifically (what commit) for gcc-15.0.9999 (run --version)? > > Can you hit it with any other application? gcc (Gentoo 15.0.9999 p, commit 2e47edeb6aa67d66f1ebe828137dd296fd9bb4dc) 15.0.1 20250115 (experimental) bea593f115bccffcb2570fc9cd642403193265d9 I can't find any other application with the same problem. this bug occurs only when using terminal emulator (kitty in my case) or graphical environment (Hyprland in my case), gnuplot works fine in TTY
(In reply to Sam James from comment #5) > Compiling gnuplot or glibc? It's possible the loader was miscompiled. > Please answer this bit too. I'll try reproduce now. Could you also try.. emerge -v1o --with-test-deps sys-libs/glibc --usepkg=n FEATURES=test emerge -v1 sys-libs/glibc --usepkg=n and show me the build.log if any tests fail? (keep the builddir around if so).
Created attachment 916935 [details] compressed build.log
After too many attempts (my fault) I got build.log (sorry for so long). As you probably expected some tests failed. === Summary of results === 14 FAIL 4937 PASS 42 UNSUPPORTED 17 XFAIL 10 XPASS
Thanks. ``` FAIL: malloc/tst-aligned-alloc FAIL: malloc/tst-aligned-alloc-malloc-check FAIL: malloc/tst-aligned-alloc-malloc-hugetlb1 FAIL: malloc/tst-aligned-alloc-malloc-hugetlb2 FAIL: malloc/tst-aligned-alloc-mcheck FAIL: malloc/tst-aligned-alloc-static FAIL: malloc/tst-aligned-alloc-static-malloc-hugetlb1 FAIL: malloc/tst-aligned-alloc-static-malloc-hugetlb2 FAIL: malloc/tst-compathooks-on FAIL: malloc/tst-malloc-too-large FAIL: malloc/tst-malloc-too-large-malloc-check FAIL: malloc/tst-malloc-too-large-malloc-hugetlb1 FAIL: malloc/tst-malloc-too-large-malloc-hugetlb2 FAIL: malloc/tst-malloc-too-large-mcheck ``` These are okay. See https://sourceware.org/PR32366 which I've backported upstream to 2.39/2.40 but not yet downstream in Gentoo.
I still haven't been able to reproduce. Please confirm whether building glibc and gnuplot w/ GCC 14 helps?
Created attachment 917461 [details] emerge --info
Created attachment 917462 [details] LD_DEBUG=symbols gnuplot
(I've added both your pastes as attachments, as pastebins expire/may not be accessible behind firewalls.)
Please tell us what version this bug is about and attach the build.log.
