[Bug]: polybar freezes on i3 when running certain modules #3017
Labels
Comments
|
Thanks for the detailed report. There is nothing obvious sticking out right now. I'll need to reproduce this myself. Just a few followup questions for that:
|
I've been on-an-off removing modules and testing the bars without them, and it seems the issues stop when these are removed. I haven't made any tests with only these modules isolated yet since reproducing it is really random and it's terrible to have no functional bars while I wait for crashes. If it helps, I have a music script that used to cause the same issue, so they both seem to trigger it. It was just easier to spot with the dualshock modules. I can try isolating the bar and running some tests, but I'll probably still keep the i3 modules to make it easier to detect the freeze.
I keep at least the i3 module so I have an easy way to detect the issue when workspaces are not updating any more
Yeah, I'm running two bars for each monitor, one on top and one on the bottom of the screen. |
|
Quick update: I was able to replicate it more consistently with the following modules: Here's how the remaining modules are structured: And I've also been running my main bar together with this one, which contains a ton of modules, including the ncspot music modules, but does not include the dualshock modules. This bar has not crashed on me for as long as I remember starting these experiments. I still have no idea what causes the issue as freezes are pretty random in my system, but they often occur hourly/semi-hourly. If there's any more missing context that could be of help, please let me know! |
|
Just a quick update as I'm still dealing with the issues at hand. The presence of modules such as Also, I've run strace to see if I could get more info, but found nothing that could be of help (when the bar crashes, some syscall outputs are just left dangling). Really wish I could help more, but it is pretty hard to reproduce this on demand. |
|
Since I don't have dualshock controllers, this will be hard for me to reproduce. But what would be immensely helpful is a full thread dump of all the bars when they are hanging, this way we should see where/why they are stuck. # Maintainer: Patrick Ziegler <[email protected]>
_pkgname=polybar
pkgname="${_pkgname}-git"
pkgver=3.7.1
pkgrel=1
pkgdesc="A fast and easy-to-use status bar"
# aarch64 is not officially supported by polybar, it is only listed here for convenience
arch=("i686" "x86_64" "aarch64")
url="https://github.com/polybar/polybar"
license=("MIT")
depends=("libuv" "cairo" "xcb-util-image" "xcb-util-wm" "xcb-util-xrm"
"xcb-util-cursor" "alsa-lib" "libpulse" "libmpdclient" "libnl"
"jsoncpp" "curl")
optdepends=("i3-wm: i3 module support")
makedepends=("cmake" "git" "python" "pkg-config" "python-sphinx"
"python-packaging" "i3-wm")
backup=("etc/polybar/config.ini")
provides=("polybar")
conflicts=("polybar")
source=("${_pkgname}::git+${url}.git")
sha256sums=("SKIP")
options=(debug !strip)
pkgver() {
git -C "${_pkgname}" describe --long --tags | sed "s/-/.r/;s/-/./g"
}
prepare() {
git -C "${_pkgname}" submodule update --init --recursive
mkdir -p "${_pkgname}/build"
}
build() {
cd "${_pkgname}/build" || exit 1
# Force cmake to use system python (to detect xcbgen)
cmake -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=Debug -DPYTHON_EXECUTABLE=/usr/bin/python3 ..
cmake --build .
}
package() {
cmake --build "${_pkgname}/build" --target install -- DESTDIR="${pkgdir}"
install -Dm644 "${_pkgname}/LICENSE" "${pkgdir}/usr/share/licenses/${_pkgname}/LICENSE"
}With this, any debugging you do on the process should give you proper file names and line numbers. The command output that would be most interesting for me is the following: You can run polybar as you normally would, and once it freezes, you run the gdb command above to get the debug info. The command does the following:
|
|
Thank you for the detailed guide! Just to clarify, the issue is not exclusive to the dualshock modules. It is increasingly more common while either Anyways, here's the gdb output, as requested: |
|
Thanks :) Now we know where the bar is stuck. For some reason, the The ipc module doesn't have the best design, but I don't see anything there that could cause this. Your ipc hooks are very simple commands and I really don't see how it could get stuck there. I wanted to rewrite how the ipc module reads script output anyway. Maybe I'll just have to do that. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Checklist
Steps to reproduce
polybar -r simplepsshows zombie child processesMinimal config
Polybar log
Expected behavior
Polybar should work as expected, updating and being responsive
Actual behavior
Total freeze, modules do not respond anymore, the bar is virtually hanging forever. The only solution is to kill the bar and start it again
Window Manager and Version
i3 version 4.22 (2023-01-02)
Linux Distribution
Arch kernel 6.5.5-arch1-1
Polybar version
Additional Context / Screenshots
If it is of any help, I'm starting polybar from i3 using a simple script:
Per testing, the responsible module(s) is/are
battery-dualshock4-iconandbattery-dualshock4Here's the script called by the module:
Also, here's
ps --forestoutput for good measure:The text was updated successfully, but these errors were encountered: