After trying to launch st through xterm I get the error: segmentation fault. This happens with glibc-2.32-r7 as well as r6 and above. I haven't tried this on the 9999 version yet though. Reproducible: Always Steps to Reproduce: 1. Launch st through xterm Actual Results: The error occurs. Executing "dmesg" shows that it appears that this segfault has something to do with glibc Expected Results: My expectation was for it to actually launch I'm on an encrypted and hardened AMD64 Gentoo install. I'm also on a Optimus NVIDIA Intel laptop. Being on stable or unstable/testing doesn't seem to make a difference.
Please don’t try glibc 9999 if that’s what you meant. Please show the full output and ideally build xterm with debugging symbols and get a backtrace
The full output is as follows: [11784.118166] st[30709]: segfault at afffffffd ip 00007f458a3537bc 00007fff0b3a6db0 error 4 in libc-2.32.so[7f458a2ee000+147000] And I'm not entirely sure how to get you a backtrace. But how would that help anyways? The problem here is suckless-terminal giving a segfault no matter how I launch it. Sorry if it didn't make this clear.
A backtrace would give us some clue as to where the code is broken. https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
Ok, now looking back at my previous comment, I sound hostile. However that was not my intention what so ever, sorry for that. Anyways, I managed to get this: Starting program: /usr/bin/st [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program recieved signal SIGSEGV, Segmentation fault. 0x00007ffff7ad4315 in free () from /lib64/libc.so.6 I hope this is helps.
Also, I just wanted to note that, it appears that none of the suckless programs seem to be communicating with eachother. It's like they don't know that the other exists. For example: when I open DWM st doesn't even launch at all, not even with Shift+Alt+Enter/Alt+Shift+Enter. Nor does dmenu launch with dwm. And nor does slstatus. This might be some misconfiguration in my kernel or config on my part.
(In reply to bothbakith from comment #4) When you see that SIGSEGV in gdb, run the "bt" command to get a back trace.
Here is the backtrace: (gdb) bt #0 0x00007ffff7ad4325 in free () from /lib64/libc.so.6 #1 0x00007ffff7d7f899 in XFree () from /usr/lib64/libX11.so.6 #2 0x00005555555613ba in xsettitle () #3 0x000055555555c257 in resettitle () #4 0x0000555555561e3d in main ()
Ok, so something is going wrong in this function. https://git.suckless.org/st/file/x.c.html#l1598
Ok, what can we do to fix this? Also, I was wondering, why am I having this error? I've seen people on a AMD64 hardened Gentoo install on stable and on unstable. And they run dwm and st flawlessly, they can get into a base install of dwm with the ability to launch st, slstatus, dmenu, and what not. That and they get no errors.
A developer will need to investigate further.
Ok, thanks. I'll be waiting.
Could you re-run the program in gdb and run "bt full" this time? That will give some additional debug info.
It says the same lines but then under each line, it says "No symbol table info available." Any ideas for why the command may be acting this way?
1. Note that I meant to say st needs debugging symbols, not xterm 2. I’ve seen issues like this when the locale isn’t set or set to a non generated value. IIRC it’s fixed in git of st.
Ok, so firstly: I can't launch st outside of xterm since I get the error "can't open display" and as far as I can gather it's normal for it to say that outside of a window server. Second of all: I'm already running the git version of st. Same goes with dwm, dmenu, and slstatus. Lastly: What do you exactly mean by giving st debugging symbols? Like giving it the debug USE flag? How do I do that when I installed it from git? Sorry if I'm being dumb I'm sorta new to Gentoo. Not to Linux though.
(In reply to bothbakith from comment #15) > What do you exactly mean by giving st debugging symbols? Like giving it the > debug USE flag? How do I do that when I installed it from git? Are you building st manually, or are you installing x11-terms/st-9999? If the latter: 1. Add "-g -Og" to CFLAGS and CXXFLAGS in make.conf. 2. Set FEATURES="splitdebug" in make.conf. 3. Rebuild x11-terms/st.
I'm building st manually, by cloning the repository using git and then doing "make clean install" once I'm in the respective directory.
(In reply to bothbakith from comment #17) > I'm building st manually, by cloning the repository using git and then doing > "make clean install" once I'm in the respective directory. export CFLAGS="-Og -g" before calling make.
Didn't seem to make any difference unfortunately.
Given that you are building this package outside of portage, I am closing this bug report as INVALID. The issue is almost certainy not with glibc, but is rather a problem in the code for st. You should contact the st developer.
I don't get it, even when building this within portage, I still get the same error.
Well, that's part of why I asked how you are building it.
Ok, thanks for all. I think that I'm gonna find a different wm, didn't quite like the suckless philosophy anyways.
>locale isn’t set or set to a non generated value. IIRC it’s fixed in git of st. Seems to be fixed four months after the fact with st commit 2f6e597, unless a previous commit between 0.8.4..HEAD also fixed the issue in another way. I have this issue with st-0.8.4 and musl, and it makes sense that lack of set locale would cause this issue for me, since musl isn't aware of locales. Cherry-picked the commit, added it to /etc/portage/patches, and it builds and runs fine. Maybe backporting this fix as a patch in the ebuild would be valuable.
Created attachment 744954 [details, diff] Patch cherrypicked from st fixing segfault
(In reply to opal hart from comment #24) > >locale isn’t set or set to a non generated value. IIRC it’s fixed in git of st. > > Seems to be fixed four months after the fact with st commit 2f6e597, unless > a previous commit between 0.8.4..HEAD also fixed the issue in another way. > > I have this issue with st-0.8.4 and musl, and it makes sense that lack of > set locale would cause this issue for me, since musl isn't aware of locales. > > Cherry-picked the commit, added it to /etc/portage/patches, and it builds > and runs fine. Maybe backporting this fix as a patch in the ebuild would be > valuable. I suspect this is partly bug 799437 too.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=332fe1cb7b2588d0fc0fb3086f7f44ac2386a2f0 commit 332fe1cb7b2588d0fc0fb3086f7f44ac2386a2f0 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-10-14 17:22:43 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-10-14 17:22:43 +0000 x11-terms/st: backport locale crash fix Closes: https://bugs.gentoo.org/784071 Signed-off-by: Sam James <sam@gentoo.org> .../st/files/st-0.8.4-locale-musl-segfault.patch | 16 +++++ x11-terms/st/st-0.8.4-r1.ebuild | 72 ++++++++++++++++++++++ 2 files changed, 88 insertions(+)
