[SOLVED] dmenu segfault with new libX11

3yan · 2016-10-06 12:24:32

Hi,
I would like to ask if I'm the only one who is encountering this issue.

After upgrade I noticed that my dmenu (dmenu_run command to be precise) started to act wierd. When I tried to pinpoint this issue I've found out that it is segfault (one segfault per failed app, those are segfaults from 6 attemps to execute app from dmenu)

Output from dmesg:

[11216.528250] dmenu[22861]: segfault at 8 ip 00007f19e086b3f0 sp 00007ffcd3cf4338 error 4 in libX11.so.6.3.0[7f19e081c000+139000]
[11218.432572] dmenu[22877]: segfault at 8 ip 00007f8a387e03f0 sp 00007fff46ccc8f8 error 4 in libX11.so.6.3.0[7f8a38791000+139000]
[11219.833788] dmenu[22892]: segfault at 8 ip 00007fa5667213f0 sp 00007ffcb783d688 error 4 in libX11.so.6.3.0[7fa5666d2000+139000]
[13527.867780] dmenu[24917]: segfault at 8 ip 00007f876ea4f3f0 sp 00007ffea043d788 error 4 in libX11.so.6.3.0[7f876ea00000+139000]
[13581.920338] dmenu[24980]: segfault at 8 ip 00007f0ce2f893f0 sp 00007fff4c4adca8 error 4 in libX11.so.6.3.0[7f0ce2f3a000+139000]
[13586.993089] dmenu[24997]: segfault at 8 ip 00007f02684b53f0 sp 00007ffc449dc718 error 4 in libX11.so.6.3.0[7f0268466000+139000]

I've pinpointed package which owns mentioned library (i'ts libx11 package) and tried previous version. Result is that dmenu_run works flawlessly with libx11-1.6.3-1 (old archlinux package version), but fails with libx11-1.6.4-1 (current archlinux package version).

Tried to get some output from gdb and acquired this pice of information:

....
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7aea3f0 in XmbLookupString () from /usr/lib/libX11.so.6
(gdb) #0  0x00007ffff7aea3f0 in XmbLookupString () from /usr/lib/libX11.so.6
#1  0x00000000004021a4 in ?? ()
#2  0x00007ffff70c0291 in __libc_start_main () from /usr/lib/libc.so.6
#3  0x0000000000402969 in ?? ()
(gdb) A debugging session is active.
....

Friend told me to recompile dmenu with debugging flag, which I tried, but I wasn't sucesfull (know, lame, but I'm not HC PC skill@ so I really don't know how to do it right). I spent few hours on this issue without nothing new. Because I dont know if it's archlinux (unprobable but who knows) or libX11.so or dmenu issue I'm posting it here because I dont know how to move forward in this issue. I didn't find out anybody else who encountered this.

also with new libx version dmenu_run write error into console before it produce segfault (when libx 1.6.3 is applied no message about locale support):

[user@arch dmenuissue]$ dmenu_run
[user@arch dmenuissue]$ warning: no locale support

Currently I'm running on libx11-1.6.3 and everything works, but I think that If I'm not only one who encountered this something shoud be done, but I don't know where and if I should report this.

EDIT:
maybe another clue - tried solution from this thread https://bbs.archlinux.org/viewtopic.php?id=149198 - but it didnt help.

Code (libx11 1.6.4):

[user@arch ~]$ export LANG="en_GB.utf8"
[user@arch ~]$ dmenu_run 
[user@arch ~]$ warning: no locale support

and of course segfault in dmesg.

Last edited by 3yan (2016-10-06 19:51:48)

Trilby · 2016-10-06 13:05:36

~~libX11.so.6.3.0 does not exist in the repos (anymore)~~. Your dmenu was built against an older version of libX11, so either you are doing partial upgrades, or you've installed dmenu from the AUR or manually.

What version of dmenu do you have installed and where did you get it?

EDIT: Sorry, I was completely wrong here. Misuse of pacman -Fs - I'm used to pkgfile and still getting used to the differences.

3yan · 2016-10-06 13:32:30

Thanks for respond

LibX11.so.6.3.0 probably does not exist, but libx11 still exists in repos:

[user@arch /]$ pacman -Qo /lib/libX11.so.6.3.0
/usr/lib/libX11.so.6.3.0 is owned by libx11 1.6.4-1

[user@arch /]$ pacman -Qo /lib/libX11.so.6.3.0 
/usr/lib/libX11.so.6.3.0 is owned by libx11 1.6.3-1

I've tried two dmenu versions, both acted same. V1 - dmenu from official repositories (community/dmenu 4.6-1), V2 - dmenu which I compiled on my PC from PKGBUILD acquired online ( https://git.archlinux.org/svntogit/comm … ages/dmenu ). I compiled it when I had libX11 1.6.4 installed on my system (to get rid of possibility of compilation against older (and potentially incompatible) version of libx11).

V1:

[root@arch dmenu2]# pacman -Qi dmenu
...
Packager        : Sergej Pupykin <pupykin.s+arch@gmail.com>
Build Date      : Mon Nov 9 11:38:38 2015
Install Date    : Thu Oct 6 15:39:48 2016
...

V2:

[root@arch dmenu2]# pacman -Qi dmenu
...
Packager        : Unknown Packager
Build Date      : Thu Oct 6 15:15:35 2016
Install Date    : Thu Oct 6 15:45:56 2016
...
[root@arch dmenu2]# cat pkg/dmenu/.BUILDINFO | grep libx11
installed = lib32-libx11-1.6.4-1
installed = libx11-1.6.4-1
...

Both dmenus (V1 and V2) acted same - they worked when libx11 1.6.3 was in system, but segfaulted with 1.6.4 version of libx11 package.

I'm upgrading only by "pacman -Syu" command (if not adviced otherwise on main archlinux page in latest news) using official mirror from pacman mirrorlist.

Of course feel free to ask any additional question which could help to get to the bottom of this issue.

Last edited by 3yan (2016-10-06 13:49:55)

Trilby · 2016-10-06 13:57:15

Sorry, see my edit above - I was completely wrong, I'm not really sure what the problem might be.

seth · 2016-10-06 15:31:39

a) does this happen with *every* keystroke?
b) please post the output of

locale

locale -a

and

sudo cat /proc/`pidof Xorg`/environ | tr '\0' '\n'

Last edited by seth (2016-10-06 15:32:31)

3yan · 2016-10-06 19:51:19

thx seth, you solved the issue

my locale.conf was (still is, I'll fix it in next minutes) pretty "underconfigured" (I set up this installation two years ago, so I just forgot about that and untill now I didn't noticed anything)

hotfix (in enviroment from which I started xserver):

[user@arch ~]$ export LC_ALL=en_US.UTF8
[user@arch ~]$ startx

solved issue

Looks like libx11 v1.6.4 is more fragile in terms of underdefined variables compared to v1.6.3 . When I'll pinpoint exact variable in locale.conf I'll post it here as edit.

Marked as solved ! Thx guys !

Edit:
dmenu (new libx11 libraries respectively) does not support "unussual" locale:
LC_CTYPE=cs_CZ.UTF-8 - fails
LC_CTYPE=en_US.UTF-8 - works

Edit2:
LC_CTYPE=cs_CZ - works

Last edited by 3yan (2016-10-07 05:53:56)

markoer · 2016-10-11 20:44:21

@3yan,

For future users, it can be that you have NoExtract in /etc/pacman.conf with locale definition which can lead to issue. Depends on context of NoExtarct. Other thing is maybe you have removed them manualy or you are using localepurge aggresivly, or locale.conf is not updated correctly as in you case.

knezi · 2016-10-16 08:38:46

I still encounter issues. There's no NoExtract option set in pacman. My locale.conf should be OK (LANG=cs_CZ.utf8). I might have removed something, but I'm not sure what should I look for.
If I set in locale.conf LANG=en_GB.utf8, then everything works. If I open X server and in terminal emulator run `export LANG=cs_CZ.utf8`, then I'll get everything correctly in this one instance. But if I run this command before (that is xterm is started with already LANG var set to cs), then file names and all text get broken. Furthermore, xterm says:

Warning: locale not supported by Xlib, locale set to C

But I have generated the locale, see `locale -a`:

C
cs_CZ.utf8
en_GB.utf8
POSIX

Everything tested on my and clean user. Any thoughts?
Sorry for posting to the closed topic, but I've got the very same problem (I am getting SIGSEGV as well), so I might just not understand the solution.

seth · 2016-10-16 08:49:15

export LANG=cs_CZ.UTF-8

knezi · 2016-10-16 12:53:18

Nope, doesn't help. Still the same.

seth · 2016-10-16 16:31:09

You still get "Warning: locale not supported by Xlib, locale set to C" for that environment??

knezi · 2016-10-16 17:27:18

Yes, that's what I don't understand.

seth · 2016-10-16 17:29:36

grep cs /etc/locale.gen # ensure it's not commented or doubled
sudo locale-gen

knezi · 2016-10-16 17:40:09

I did it thousands times. Even rebooted few times. Didn't help.
Xterm does not work. Dmenu still throws SIGSEGV. Konsole does work (but it just may not use xlib??).

seth · 2016-10-16 17:49:13

konsole uses xcb, yes.
maybe some relevant locale is shadowed by an explicit (and bogus) value?

What's the output of "locale", before "export LANG=cs_CZ.UTF-8", after and after "export LC_ALL=cs_CZ.UTF-8"?

knezi · 2016-10-16 18:01:24

Ok. If I set cs_CZ.UTF-8 in `locale.conf` then (this settings does not work):

LANG=cs_CZ.UTF-8
LC_CTYPE="cs_CZ.UTF-8"
LC_NUMERIC="cs_CZ.UTF-8"
LC_TIME="cs_CZ.UTF-8"
LC_COLLATE="cs_CZ.UTF-8"
LC_MONETARY="cs_CZ.UTF-8"
LC_MESSAGES="cs_CZ.UTF-8"
LC_PAPER="cs_CZ.UTF-8"
LC_NAME="cs_CZ.UTF-8"
LC_ADDRESS="cs_CZ.UTF-8"
LC_TELEPHONE="cs_CZ.UTF-8"
LC_MEASUREMENT="cs_CZ.UTF-8"
LC_IDENTIFICATION="cs_CZ.UTF-8"
LC_ALL=

If I set en_GB.UTF-8 in `locale.conf` then (this settings works):

LANG=en_GB.UTF-8
LC_CTYPE="en_GB.UTF-8"
LC_NUMERIC="en_GB.UTF-8"
LC_TIME="en_GB.UTF-8"
LC_COLLATE="en_GB.UTF-8"
LC_MONETARY="en_GB.UTF-8"
LC_MESSAGES="en_GB.UTF-8"
LC_PAPER="en_GB.UTF-8"
LC_NAME="en_GB.UTF-8"
LC_ADDRESS="en_GB.UTF-8"
LC_TELEPHONE="en_GB.UTF-8"
LC_MEASUREMENT="en_GB.UTF-8"
LC_IDENTIFICATION="en_GB.UTF-8"
LC_ALL=

After export LANG=cs_CZ.UTF-8 (this works in current terminal, but I run run a new instance from the current terminal, then the new one does not work):

LANG=cs_CZ.UTF-8
LC_CTYPE="cs_CZ.UTF-8"
LC_NUMERIC="cs_CZ.UTF-8"
LC_TIME="cs_CZ.UTF-8"
LC_COLLATE="cs_CZ.UTF-8"
LC_MONETARY="cs_CZ.UTF-8"
LC_MESSAGES="cs_CZ.UTF-8"
LC_PAPER="cs_CZ.UTF-8"
LC_NAME="cs_CZ.UTF-8"
LC_ADDRESS="cs_CZ.UTF-8"
LC_TELEPHONE="cs_CZ.UTF-8"
LC_MEASUREMENT="cs_CZ.UTF-8"
LC_IDENTIFICATION="cs_CZ.UTF-8"
LC_ALL=

Finally export LC_ALL=cs_CZ.UTF-8 (same as the previous case):

LANG=cs_CZ.UTF-8
LC_CTYPE="cs_CZ.UTF-8"
LC_NUMERIC="cs_CZ.UTF-8"
LC_TIME="cs_CZ.UTF-8"
LC_COLLATE="cs_CZ.UTF-8"
LC_MONETARY="cs_CZ.UTF-8"
LC_MESSAGES="cs_CZ.UTF-8"
LC_PAPER="cs_CZ.UTF-8"
LC_NAME="cs_CZ.UTF-8"
LC_ADDRESS="cs_CZ.UTF-8"
LC_TELEPHONE="cs_CZ.UTF-8"
LC_MEASUREMENT="cs_CZ.UTF-8"
LC_IDENTIFICATION="cs_CZ.UTF-8"
LC_ALL=cs_CZ.UTF-8

It seems OK. I've checked all configuration files I could think of and haven't found any shadowing parameters.

seth · 2016-10-16 18:18:03

Looks good to me. I tried cs_CZ.UTF-8 w/o any trouble.
Try exporting every LC_ value one by one (ie. globally use en and override single values with cs) and see whether a specific one causes this.
I'd try with LC_COLLATE (which is good to have at "C" anyway to avoid rendering errors in ncurses programs)

knezi · 2016-10-17 08:07:44

The problem is LC_CTYPE which is supposed to be responsible for interpreting multibyte sequence. So `locale.conf`:

LANG=cs_CZ.UTF-8
LC_CTYPE=en_GB.UTF-8

works.

EDIT: I've tried about ten others locales. All but ff_SN.UTF-8 work. ff_SN-UTF-8 has the same problems.

Last edited by knezi (2016-10-17 08:23:23)

kamahl · 2016-10-20 08:15:35

I am encountering the exactly same problem with cs_CZ.UTF-8 soled with a workaround by running dmenu by:

env LC_ALL=en_US.UTF-8 dmenu_run

instead of just dmenu_run

Last edited by kamahl (2016-10-20 08:19:07)

khardix · 2016-10-26 13:07:32

It is caused by a bug in the new libX11-1.6.4. See Bug 98219 - libX11-1.6.4 cs_CZ.UTF-8 locale is bad.

I'm without access to my Arch installation at the moment, but on my Fedora 25 Beta the troubles were solved by rebuilding the libX11 packages with the line mentioned in the BZ changed as described (file nls/locale.dir.pre):

cs_CZ.UTF-8/XLC_LOCALE   cs_CZ.UTF-8

to

en_US.UTF-8/XLC_LOCALE   cs_CZ.UTF-8

tuxayo · 2016-12-14 18:02:56

I got the same issue with locale en_DK.UTF-8

Adding LC_CTYPE=en_US.UTF-8 in locale.conf mitigated the issue.

Arch Linux

#1 2016-10-06 12:24:32

[SOLVED] dmenu segfault with new libX11

#2 2016-10-06 13:05:36

Re: [SOLVED] dmenu segfault with new libX11

#3 2016-10-06 13:32:30

Re: [SOLVED] dmenu segfault with new libX11

#4 2016-10-06 13:57:15

Re: [SOLVED] dmenu segfault with new libX11

#5 2016-10-06 15:31:39

Re: [SOLVED] dmenu segfault with new libX11

#6 2016-10-06 19:51:19

Re: [SOLVED] dmenu segfault with new libX11

#7 2016-10-11 20:44:21

Re: [SOLVED] dmenu segfault with new libX11

#8 2016-10-16 08:38:46

Re: [SOLVED] dmenu segfault with new libX11

#9 2016-10-16 08:49:15

Re: [SOLVED] dmenu segfault with new libX11

#10 2016-10-16 12:53:18

Re: [SOLVED] dmenu segfault with new libX11

#11 2016-10-16 16:31:09

Re: [SOLVED] dmenu segfault with new libX11

#12 2016-10-16 17:27:18

Re: [SOLVED] dmenu segfault with new libX11

#13 2016-10-16 17:29:36

Re: [SOLVED] dmenu segfault with new libX11

#14 2016-10-16 17:40:09

Re: [SOLVED] dmenu segfault with new libX11

#15 2016-10-16 17:49:13

Re: [SOLVED] dmenu segfault with new libX11

#16 2016-10-16 18:01:24

Re: [SOLVED] dmenu segfault with new libX11

#17 2016-10-16 18:18:03

Re: [SOLVED] dmenu segfault with new libX11

#18 2016-10-17 08:07:44

Re: [SOLVED] dmenu segfault with new libX11

#19 2016-10-20 08:15:35

Re: [SOLVED] dmenu segfault with new libX11

#20 2016-10-26 13:07:32

Re: [SOLVED] dmenu segfault with new libX11

#21 2016-12-14 18:02:56

Re: [SOLVED] dmenu segfault with new libX11

Board footer