High CPU use / program doesn't open

[hylyh]

Hello, I'm using j4-dmenu-desktop-git from the AUR in Openbox and I'm noticing that after I've been logged in for a few minutes, I can no longer open programs through dmenu (it works for a little bit before this starts happening), and when I try to, my CPU load shoots up to above 100% until I go and kill the process (it's either the 'j4-dmenu-desktop' command or the /bin/bash -i -c 'program name' command that's showing high cpu).

This happens no matter what program I try to open, even on small programs like gnome-calculator. I can only replicate the issue when I use the openbox keybinding to use dmenu, when I run the command in the terminal the error doesn't show and programs start up fine.

The command I'm running is j4-dmenu-desktop --dmenu='dmenu -i -nb "#3D3D3D"' --term="gnome-terminal"

I can't get any output when I try to redirect stdout or stderr from the keybinding command, so I'm completely in the dark about why this would be happening. I'll try to update with more information when I find it, but any ideas would be a big help.

[enkore]

Try to somehow check the locale of the openbox process environment. Many programs (including this one) can be heavily confused by wrong locale information.

You could also try to attach with gdb to the CPU hogging process, something like this:

$ gdb attach <PID>
(gdb) thread apply all bt
# stuff

This might need root privileges.

[hylyh]

I've checked my locale and LANG and all LC_* are set to en_US.UTF-8 as expected. If it is a locale problem I don't see why it would work for a few minutes after logging in and then suddenly stop.

Here's two times I ran the gdb attach to the hanging process and got different output:

[jluke@Null ~]$ sudo gdb attach 12359
GNU gdb (GDB) 7.9.1
...
Attaching to process 12359
Reading symbols from /usr/bin/bash...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libreadline.so.6...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libncursesw.so.5...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libdl.so.2...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libc.so.6...(no debugging symbols found)...done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libnss_files.so.2...(no debugging symbols found)...done.
0x00007f9c51298477 in ioctl () from /usr/lib/libc.so.6
(gdb) thread apply all bt

Thread 1 (process 12359):
#0  0x00007f9c51298477 in ioctl () from /usr/lib/libc.so.6
#1  0x00007f9c51297d25 in tcgetpgrp () from /usr/lib/libc.so.6
#2  0x000000000044149b in initialize_job_control ()
#3  0x0000000000417cb2 in ?? ()
#4  0x0000000000418de9 in main ()

[jluke@Null ~]$ sudo gdb attach 27783
GNU gdb (GDB) 7.9.1
...
Attaching to process 27783
Reading symbols from /usr/bin/bash...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libreadline.so.6...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libncursesw.so.5...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libdl.so.2...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libc.so.6...(no debugging symbols found)...done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libnss_files.so.2...(no debugging symbols found)...done.
0x00007f2d86103867 in kill () from /usr/lib/libc.so.6
(gdb) thread apply all bt

Thread 1 (process 27783):
#0  0x00007f2d86103867 in kill () from /usr/lib/libc.so.6
#1  0x00000000004414cf in initialize_job_control ()
#2  0x0000000000417cb2 in ?? ()
#3  0x0000000000418de9 in main ()

[hylyh]

Also I'm not sure how helpful it is but I can't replicate the problem using plain dmenu_run

[cdonati]

I ran into this issue as well. I ended up removing the -i shell flag (https://github.com/cdonati/j4-dmenu-desktop/commit/6fde3c38b3b1ea68393f7950b0edf3c38b15af26) and recompiling. It seems to work fine now.

I don't know why this works or what I'm losing by not having that flag, but I'm leaving this here in case someone else has this issue.

[enkore]

Hm, probably something in the .<$SHELL>rc. The -i -c stuff was to work around some issue, not sure anymore which one though.

Introducer: 7ef1674 => #11, the -i flag has the shell interpret aliases

[jfrankenau]

What about providing an option to remove the -i flag? Or simply not adding it at all and instead documenting it in case someone prefers to start an interactive shell to interpret aliases?

[ghost]

I've the same problem, j4-dmenu-desktop won't open anything. I had to switch back to i3-dmenu-desktop.

[enkore]

Can you verify if it's the same issue?

1. Remove "-i" here
2. Recompile
3. Check if problem persists

Since this seems to affect a few people for some reason I guess this will be removed in the next release.

[ghost]

Won't even open without the -i flag :crying_cat_face:

[enkore]

Can you use it in a console and paste the output here?

[ghost]

manu@X220 ~> cd /tmp/j4-dmenu-desktop/                                                                                                        12:15:41
manu@X220 /t/j4-dmenu-desktop> ./j4-dmenu-desktop                                                                                             12:15:44
Read 157 .desktop files, found 97 apps.
User input is: File Manager PCManFM 
pcmanfm 
/bin/bash -c 'pcmanfm '
manu@X220 /t/j4-dmenu-desktop> ./j4-dmenu-desktop                                                                                             12:15:49
Read 157 .desktop files, found 97 apps.
User input is: Thunar File Manager 
thunar 
/bin/bash -c 'thunar '

[ghost]

Oh wait, I removed the -i from the wrong line. Now it works without the -i!

[zopieux]

Removing -i fixes the non-launching bug here too. Would it be possible to get a release with that fix?