UtkarshVerma / dwmblocks-async

An efficient, lean, and asynchronous status feed generator for dwm.
GNU General Public License v2.0
232 stars 87 forks source link

user-defined signal 1 #4

Closed apprehensions closed 3 years ago

apprehensions commented 3 years ago

clicking on statusbar/module makes dwmblocks-async crash with code 138 output: user-defined signal 1 dwmblocks

this happens when used with my modified dwm build + default dwm only patched with dwm-statuscmd-status

apprehensions commented 3 years ago

statuscmd patch i used included sending a SIGUSR1, the main statuscmd patch sends a SIGRTMIN, however dwmblocks-async only accepts SIGRTMIN.

Pyxels commented 3 years ago

I have had the same problem, where you able to fix it by just applying the other patch or do I have to completely redo dwm?

UtkarshVerma commented 3 years ago

~~Ah, I made a minor typo.😅 This is happening because I encoded the block index in the output rather than the signal. That's why clicking on the second block is sending signal 1 to dwmblocks, which kills it as it is not handled. Let me fix this up real quick.~~

As pointed by wael, this is because dwmblocks-async doesn't handle SIGUSR1. You'll need to patch dwm for handling this. dwm-flexipatch does mention something about this.

You basically update this function in dwm source. https://github.com/bakkeby/dwm-flexipatch/blob/master/patch/bar_dwmblocks.c#L29

apprehensions commented 3 years ago

@Pyxels all i had to do was change

sigqueue(dwmblockspid, SIGUSR1, sv);

to

sigqueue(dwmblockspid, SIGRTMIN+dwmblockssig, sv);

~temporary soluton~

Pyxels commented 3 years ago

Thanks that fixed the crashing bug. Though now every click is counted as two, do you have the same problem?

apprehensions commented 3 years ago

Thanks that fixed the crashing bug. Though now every click is counted as two, do you have the same problem?

no, but can i have the script used so i can see if i can produce the same problem?

~note the fix above is only a temporary solution.~

Pyxels commented 3 years ago
#!/bin/sh

case $BLOCK_BUTTON in
        1) notify-send "🖥 CPU hogs" "$(ps axch -o cmd:15,%cpu --sort=-%cpu | head)\\n(100% per core)" ;;
        2) setsid -f "$TERMINAL" -e bpytop ;;
        3) notify-send "🖥 CPU module " "\- Shows CPU temperature.
- Click to show intensive processes.
- Middle click to open bpytop." ;;
        6) "$TERMINAL" -e "$EDITOR" "$0" ;;
esac

sensors | awk '/Core 0/ {print "🌡" $3}'

This for example. ~Im also having issues with the ordering of the blocks.~ I created a new issue for that (#5) But don't waste too much time on it, I can look into it later by myself or just use the older version which worked fine for me.

UtkarshVerma commented 3 years ago

This is not a bug. dwmblocks-async assumes you've patched dwm with the statuscmd patch, as mentioned in the README, which doesn't depend on SIGUSR1. Therefore it doesn't handle SIGUSR1, which causes it to die when some process sends it that signal.

Simple solution for this is to patch dwm with the latest statuscmd patch, which doesn't use SIGUSR1.

apprehensions commented 3 years ago

is there a reason to use SIGRTMIN over SIGUSR1? currently rebuilding my whole dwm build just to fix this really dumb location issue, i tried to move around the update signals and it didn't help.