Greetings everyone.
Since a few days ago I've been running into an annoying problem. Sometimes, seemingly randomly, my Xorg session freezes and it seems that (according to "btop") openbox begins eating away at RAM.
This has happened so far in 3 instances:
- After closing a Kitty Terminal window
- Opening a new PCmanFM window
- Leaving the laptop locked using i3lock-multimonitor
Last time (a few minutes ago) I came back from lunch to my laptop's fans screaming and found out that Openbox was using 10GB (out of 16) of RAM.
Btop shows also that at least 1 core of the CPU is stuck at 100%, but no processes are actually using that much CPU.
Inxi -GSC -xx output:
System:
Host: PenazMW2 Kernel: 6.6.18-1-lts arch: x86_64 bits: 64 compiler: gcc
v: 13.2.1
Desktop: Openbox v: 3.6.1 dm: LightDM Distro: Artix base: Arch Linux
CPU:
Info: 6-core model: Intel Core i7-8750H bits: 64 type: MT MCP
arch: Coffee Lake rev: A cache: L1: 384 KiB L2: 1.5 MiB L3: 9 MiB
Speed (MHz): avg: 874 high: 900 min/max: 800/4100 cores: 1: 900 2: 800
3: 900 4: 900 5: 900 6: 800 7: 900 8: 900 9: 895 10: 900 11: 800 12: 900
bogomips: 52815
Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx
Graphics:
Device-1: AMD Baffin [Radeon Pro WX 4130/4150] vendor: Dell driver: amdgpu
v: kernel arch: GCN-4 pcie: speed: 8 GT/s lanes: 8 ports: active: eDP-1
empty: DP-1, DP-2, DP-3, HDMI-A-1 bus-ID: 01:00.0 chip-ID: 1002:67e8
temp: 51.0 C
Device-2: Realtek Integrated Webcam HD driver: uvcvideo type: USB rev: 2.0
speed: 480 Mb/s lanes: 1 bus-ID: 1-11:5 chip-ID: 0bda:568c
Display: x11 server: X.Org v: 21.1.11 with: Xwayland v: 23.2.4
compositor: Picom v: git-cc8e0 driver: X: loaded: amdgpu
unloaded: fbdev,modesetting,vesa dri: radeonsi gpu: amdgpu display-ID: :0
screens: 1
Screen-1: 0 s-res: 6160x1080 s-dpi: 96
Monitor-1: eDP-1 mapped: eDP model: AU Optronics 0x139d res: 1920x1080
dpi: 128 diag: 437mm (17.2")
API: EGL v: 1.5 platforms: device: 0 drv: radeonsi device: 1 drv: swrast
surfaceless: drv: radeonsi x11: drv: radeonsi inactive: gbm,wayland
API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 24.0.2-arch1.1
glx-v: 1.4 direct-render: yes renderer: AMD Radeon Pro WX Series (radeonsi
polaris11 LLVM 16.0.6 DRM 3.54 6.6.18-1-lts) device-ID: 1002:67e8
API: Vulkan v: 1.3.276 surfaces: xcb,xlib device: 0 type: discrete-gpu
driver: mesa radv device-ID: 1002:67e8 device: 1 type: cpu
driver: mesa llvmpipe device-ID: 10005:0000
EDIT: I also tried to kill OpenBox to recover the system, but the CPU stays 100%-ed and I'm forced to reboot.
I just installed xrestop to see if I can get to the bottom of this, but in the meantime, is there anyone experiencing the same issue?
Thank you all in advance.
Try with a clean config(backup your current settings first) /new user to see if it's particular settings causing the problem.
If it is you'd have to start adding your settings back one by one (or at least batches) to work out the setting causing the issue.
Maybe try starting X without lightdm (xorg-xinit, startx) and see if that makes any difference. Long shot but worth a try.
Consider that openbox was last updated almost 9 years ago.
What desktop are you using or is it just pure openbox ?
My desktop is just pure openbox, with Tint2 as taskbar and a couple of Conky configurations.
I never had any issue of this kind in the 14 years I've been using this kind of setup (had to switch from SLiM to LightDM).
I can't really afford to reset my current configuration at the moment (I use the laptop for my day job) but I might try at a later time.
I have been thinking about switching WM but I can't really find anything that seems to get close to openbox as functionality. I heard good things about AwesomeWM, but I'm more than open to suggestions.
[offtopic]
The father of them all is IceWM, and it's still developed to this day paradoxically, where as openbox is just maintained for a good number of years.
You need patience for awesome, i didn't get it to work just right, ended up trying wayland desktops and labwc which is kinda a clone of openbox works really well, too bad the whole thing is still not ready.
[/offtopic]
I run pretty much the same as you, but I use slim to start Xorg and use ~/.xinitrc to start the openbox session.
I have recently had some issues related to conky >=1.19.7-1. In Arch/Artix linux i saw a crash of tint2 when running with 1.19.7-2. I reverted conky to 1.19.6-1 and things seem to be calmer.
I have not seen any freezes though.
I maintain a local AUR to build slim based on https://sourceforge.net/projects/slim-fork/ it's not in Arch AUR as yet.
You wouldn't need to reset.
Just create a new user:
useradd -m test
logout
login as user test
See if the issue persists ? If it does it's most likely a system issue. If it doesn't it's a more likely to be an issue with your users settings. It's not guaranteed because it could be a default setting that gets applied.
With the lack of updates to openbox we can pretty much rule out any changes there. So if it is openbox related then it has to be something openbox relies on.
You said
You have 6C 12T. One core(thread ?) at 100% shouldn't be freezing anything except the process in question or a process that's waiting on it. Some process must be using the high cpu? Maybe try with htop or top.
Just thinking out loud. Out of ideas other than downgrading what was upgraded.
I too have Openbox/tint2 and I have not experienced any issues. I have several installations configured the same on different hardware and, so far at least, have not experienced your problem.
I would take a closer look at the network activities.
Or do you only work with openbox, conky, tint2 and kitty? :o
I may take a look at IceWM just to have something more up to date. I like customizing my system, but awesomeWM may be a bit too time consuming for me.
Yes, I confirm 6C 12T, I forgot to mention that the mouse cursor still is visible and moves (so it's not a full system freeze) and I can still access the TTYs. Not sure why it's behaving like this to be honest, but I may have a new piece of information. More on that later.
Well, I use a couple browsers: Qutebrowser (my main browser) and Firefox Developer Edition (for web dev), but most of my workflow involves Openbox, conky, tint2, kitty, neovim and Rofi.
I have been toying around with the idea of switching back to SLiM and just be done with it, but then I experimented with LabWC and I was like "Maybe this could go somewhere so I migrate away from X" and then it just never happens :D
About the news, I checked around my logs and found this, just around the time the system started bugging out this afternoon:
This comes from /var/log/errors.log
Mar 1 09:08:38 PenazMW2 kernel: xhci_hcd 0000:39:00.0: HC died; cleaning up
Mar 1 14:06:54 PenazMW2 /etc/init.d/openrc-settingsd[16710]: start-stop-daemon: no matching processes found
Mar 1 14:07:37 PenazMW2 kernel: BUG: scheduling while atomic: swapper/11/0/0x00000102
Mar 1 14:07:37 PenazMW2 kernel: bad: scheduling from the idle thread!
Mar 1 14:07:37 PenazMW2 kernel: bad: scheduling from the idle thread!
Mar 1 14:07:37 PenazMW2 kernel: bad: scheduling from the idle thread!
Mar 1 14:07:37 PenazMW2 kernel: bad: scheduling from the idle thread!
Mar 1 14:07:37 PenazMW2 kernel: bad: scheduling from the idle thread!
[...]
Mar 1 14:07:37 PenazMW2 kernel: bad: scheduling from the idle thread!
Mar 1 14:07:37 PenazMW2 kernel: bad: scheduling from the idle thread!
Mar 1 14:07:37 PenazMW2 syslog-ng[2924]: I/O error occurred while reading; fd='13', error='Broken pipe (32)'
Mar 1 14:07:37 PenazMW2 kernel: bad: scheduling from the idle thread!
Mar 1 14:07:37 PenazMW2 kernel: bad: scheduling from the idle thread!
Mar 1 14:07:37 PenazMW2 kernel: bad: scheduling from the idle thread!
[...]
This instead is from /var/log/messages.log
Mar 1 14:07:37 PenazMW2 kernel: Hardware name: Dell Inc. Precision 7730/09G96M, BIOS 1.5.2 11/01/2018
Mar 1 14:07:37 PenazMW2 kernel: Call Trace:
Mar 1 14:07:37 PenazMW2 kernel: <IRQ>
Mar 1 14:07:37 PenazMW2 kernel: dump_stack_lvl+0x47/0x60
Mar 1 14:07:37 PenazMW2 kernel: dequeue_task_idle+0x29/0x40
Mar 1 14:07:37 PenazMW2 kernel: __schedule+0x5b3/0x1410
Mar 1 14:07:37 PenazMW2 kernel: ? get_nohz_timer_target+0x108/0x1a0
Mar 1 14:07:37 PenazMW2 kernel: ? __mod_timer+0x11f/0x370
Mar 1 14:07:37 PenazMW2 kernel: schedule+0x5e/0xd0
Mar 1 14:07:37 PenazMW2 kernel: schedule_timeout+0x98/0x160
Mar 1 14:07:37 PenazMW2 kernel: ? __pfx_process_timeout+0x10/0x10
Mar 1 14:07:37 PenazMW2 kernel: ath10k_wmi_cmd_send+0x1c6/0x200 [ath10k_core 343e553f1ad8d119f597f99eb3bf86498dd3d1a0]
Mar 1 14:07:37 PenazMW2 kernel: ? __pfx_autoremove_wake_function+0x10/0x10
Mar 1 14:07:37 PenazMW2 kernel: ath10k_mac_rfkill_enable_radio+0x6b/0xc0 [ath10k_core 343e553f1ad8d119f597f99eb3bf86498dd3d1a0]
Mar 1 14:07:37 PenazMW2 kernel: ath10k_wmi_tlv_op_rx+0x5a8/0xe40 [ath10k_core 343e553f1ad8d119f597f99eb3bf86498dd3d1a0]
Mar 1 14:07:37 PenazMW2 kernel: ath10k_htc_rx_completion_handler+0xd7/0x250 [ath10k_core 343e553f1ad8d119f597f99eb3bf86498dd3d1a0]
Mar 1 14:07:37 PenazMW2 kernel: ath10k_pci_process_rx_cb+0x16b/0x200 [ath10k_pci 4fe4a3aaf6116457f733aea545bcf3d664650a0a]
Mar 1 14:07:37 PenazMW2 kernel: ? __pfx_ath10k_htc_rx_completion_handler+0x10/0x10 [ath10k_core 343e553f1ad8d119f597f99eb3bf86498dd3d1a0]
Mar 1 14:07:37 PenazMW2 kernel: ath10k_ce_per_engine_service+0x5c/0x90 [ath10k_core 343e553f1ad8d119f597f99eb3bf86498dd3d1a0]
Mar 1 14:07:37 PenazMW2 kernel: ath10k_ce_per_engine_service_any+0x8d/0xa0 [ath10k_core 343e553f1ad8d119f597f99eb3bf86498dd3d1a0]
Mar 1 14:07:37 PenazMW2 kernel: ath10k_pci_napi_poll+0x47/0x120 [ath10k_pci 4fe4a3aaf6116457f733aea545bcf3d664650a0a]
Mar 1 14:07:37 PenazMW2 kernel: __napi_poll+0x28/0x1b0
Mar 1 14:07:37 PenazMW2 kernel: net_rx_action+0x2b5/0x370
Mar 1 14:07:37 PenazMW2 kernel: __do_softirq+0xd1/0x2c8
Mar 1 14:07:37 PenazMW2 kernel: __irq_exit_rcu+0xa3/0xc0
Mar 1 14:07:37 PenazMW2 kernel: common_interrupt+0x86/0xa0
Mar 1 14:07:37 PenazMW2 kernel: </IRQ>
Mar 1 14:07:37 PenazMW2 kernel: <TASK>
Mar 1 14:07:37 PenazMW2 kernel: asm_common_interrupt+0x26/0x40
Mar 1 14:07:37 PenazMW2 kernel: RIP: 0010:cpuidle_enter_state+0xcc/0x440
Mar 1 14:07:37 PenazMW2 kernel: Code: 0a a5 38 ff e8 d5 f3 ff ff 8b 53 04 49 89 c5 0f 1f 44 00 00 31 ff e8 d3 a5 37 ff 45 84 ff 0f 85 56 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 85 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d
Mar 1 14:07:37 PenazMW2 kernel: RSP: 0018:ffffb04740183e90 EFLAGS: 00000246
Mar 1 14:07:37 PenazMW2 kernel: RAX: ffff8f5c4bcf41c0 RBX: ffff8f5c4bcff700 RCX: 000000000000001f
Mar 1 14:07:37 PenazMW2 kernel: RDX: 000000000000000b RSI: 0000000039f897d9 RDI: 0000000000000000
Mar 1 14:07:37 PenazMW2 kernel: RBP: 0000000000000004 R08: 0000000000000004 R09: 0000000000000054
Mar 1 14:07:37 PenazMW2 kernel: R10: 0000000000000018 R11: ffff8f5c4bcf2ba4 R12: ffffffffafb47ea0
Mar 1 14:07:37 PenazMW2 kernel: R13: 000000026d9e7734 R14: 0000000000000004 R15: 0000000000000000
Mar 1 14:07:37 PenazMW2 kernel: cpuidle_enter+0x2d/0x40
Mar 1 14:07:37 PenazMW2 kernel: do_idle+0x1d8/0x230
Mar 1 14:07:37 PenazMW2 kernel: cpu_startup_entry+0x2a/0x30
Mar 1 14:07:37 PenazMW2 kernel: start_secondary+0x11e/0x140
Mar 1 14:07:37 PenazMW2 kernel: secondary_startup_64_no_verify+0x18f/0x19b
Mar 1 14:07:37 PenazMW2 kernel: </TASK>
Mar 1 14:07:37 PenazMW2 kernel: CPU: 11 PID: 0 Comm: swapper/11 Tainted: G W OE 6.6.18-1-lts #1 bac52aa5d746aa3a1fe953238d3b30a64dd2c24d
Mar 1 14:07:37 PenazMW2 kernel: Hardware name: Dell Inc. Precision 7730/09G96M, BIOS 1.5.2 11/01/2018
Mar 1 14:07:37 PenazMW2 kernel: Call Trace:
Mar 1 14:07:37 PenazMW2 kernel: <IRQ>
Mar 1 14:07:37 PenazMW2 kernel: dump_stack_lvl+0x47/0x60
Mar 1 14:07:37 PenazMW2 kernel: dequeue_task_idle+0x29/0x40
Mar 1 14:07:37 PenazMW2 kernel: __schedule+0x5b3/0x1410
Mar 1 14:07:37 PenazMW2 kernel: ? get_nohz_timer_target+0x108/0x1a0
Mar 1 14:07:37 PenazMW2 kernel: ? __mod_timer+0x11f/0x370
Mar 1 14:07:37 PenazMW2 kernel: schedule+0x5e/0xd0
Mar 1 14:07:37 PenazMW2 kernel: schedule_timeout+0x98/0x160
Mar 1 14:07:37 PenazMW2 kernel: ? __pfx_process_timeout+0x10/0x10
[... repeats ...]
Three days ago linux-lts was updated to linux-lts-6.6.18-1 from linux-lts-6.6.16-1
This seem to tie in with when you started experiencing issues. Try downgrading.
Today the issue arose again. I'm not even sure it's a scheduling problem, since there were no errors like last time. (Maybe the error were a red herring?)
I tried recovering the system from TTY by restarting LightDM, but instead of restarting it just stopped. (I checked my command history to make sure I used
/etc/init.d/lightdm restart).
After using the start command (since lightdm stopped instead of restarting) it seems the system recovered successfully from its weird "memory hungry" state.
Other updates:
- I thought maybe something was happening with the fact that I use dinit as a process supervisor for some stuff like pipewire or conky (which lately felt like crashing more than usual). Using
dinitctl shutdown didn't help the situation.
- During the malfunction, I could still use the window I was in (which was a Kitty Terminal Emulator window) but the mouse cursor disappeared and I couldn't switch windows with Alt-Tab. This is different from last time, where the cursor was the only thing working.
I think I was experiencing issues with 6.6.16 too, probably once (I remember thinking something along the lines of "Oh, they already updated the Kernel, maybe my problem was already reported"). The biggest issue for me is that I can't seem to be able to reproduce the issue "on command". Yesterday and Saturday everything worked smoothly, today it happened instead.
At this point I think the problem is on the user side, so either OpenBox (maybe some Xorg library updates happened), LightDM or my user files are broken in some way. If I manage to cut myself some time off work, I'll try and change login manager (since this one failed to restart for some reason) and eventually make a new user if that doesn't work.
Thank you all for your kind help.
Yet another update! I found a way to reliably reproduce the issue: using lxappearance to change my mouse pointer theme.
That brings an immediate freeze on OpenBox and the memory hogging starts immediately.
I have been really lucky on this, because when I tried lxdm as display manager, I noticed the mouse cursor was changed from my default, so I tried to restore it. That's how I found out about this way to reproduce the issue.
Cursor handling has indeed been strange for me too recently, but anyway so what lxappearance does is change the gtk config files (you should look at the structure of the .config/gtk* folders) and the .Xdefaults file (try to simply delete it). Check if you also have .Xresources maybe.
Do you still use Picom as compositor during this testing? Try without it, then maybe change it's backend between xrender and glx?
If you go for IceWM here are some good themes for it: https://themes.ice-wm.org
Or in the aur package icewm-extra-themes
I checked, deleted .Xdefaults and .config/.gtk-3.0/settings.ini without result.
I checked both with and without Picom active. The problem persists, so I went for the nuclear option: stop every non-vital process except for OpenBox and... it's Conky. Again. (Had some issues with it lately, it was crashing as I moved the mouse cursor and, in the past, it was the cause of my audio stuttering issue, for which I asked for help in this very forum).
It seems that there is something in my conky configuration that triggers the issue. Time for some binary search!
Thank you very much, if I can find something similar to my current theme (Adapta-Nokto) and it's as easy to configure as OpenBox, I might give it a serious thought!
Here's an update: it seems that the problem is Conky itself.
I tried bisecting my own configuration to no avail. After trying with the default configuration, the problem persists.
I'm opening an issue on their GitHub for this. It seems that the latest versions have issues with mouse tracking (version 1.19.7-1 used to crash when the cursor moved).
I had issues with conky-1.19.7-1 myself. Allegedly 1.19.7-2 is a fix, but I think I had problems with that version because my attempts to fix the issues made me change to double_buffer = false, I had some problems after updating to 1.19.7-2 including a tint2 crash.
EDIT: I tried again with conky-1.19.7-2 and it causes a segfault in tint2 somehow
/home/robin/.config/openbox/autostart.sh: line 10: 604 Segmentation fault (core dumped) /bin/tint2
reverting to conky-1.19.6-1 seems to make things better.
Not sure if this is of any use
EDIT: seems upstream has this report (https://github.com/brndnmtthws/conky/issues/1767)
I did a Git Bisect (so much compiling!) and it seems I may have found the commit that introduced the bug. I'm waiting on a response.
Upstream issue at: https://github.com/brndnmtthws/conky/issues/1771
Small update: I haven't received any response yet on the issue, so I did some further testing.
Another Git Bisect was completely inconclusive (the commit that "introduced the bug" was one where only the version in the CmakeFile was changed) and I checked if IceWM had the same issue with the "cursor change test".
There was no issue, so it may be an interaction issue with OpenBox and Conky instead of being just a "Conky problem".
Well I think it depends on your point of view. I'm running conky on Arch linux and Artix. I see the problem occurs when I update conky from 1.19.6-1 to either of 1.19.7-1 or 1.19.7-2. Whatever conky is doing it is affecting tint2 (for me). A change in one breaks another. I think the change is responsible.
That is absolutely true, but I think that also other things should be considered: Openbox and Tint2 are officially unmaintained, thus they're not keeping up with the latest (possible) changes in the protocols (maybe used to fix bugs) or make use of workarounds that are just not there anymore.
That obviously doesn't exonerate Conky, as this issue may be symptom of a deeper problem that may, at the very minimum, warrant a look at.
Since wayland devs complain that xorg is unmaintained I doubt that any protocols have changed recently.
If a protocol change external to openbox/tint2 has changed then it's probable that it would already have started to affect tint2 with an earlier version of comky.
As conky development is attempting to provide a wayland version its more likely that a protocol assumption or change in conky has caused this problem. Also the conky devs could easily simulate this problem and just say what they regard as the real problem ie tint2 ignores x etc etc.
Source ?
Doesn't look unmaintained.
https://gitlab.freedesktop.org/xorg/xserver/-/commits/master
I didn't say X.Org was, but that's one of the assertions made by those pushing wayland and this (https://www.phoronix.com/news/XServer-2022-Development-Pace) article suggests there may be something in their claim.
X11 was released in 1984 and X.Org in 2004 if wikipedia is correct. After such a long time I think it's unlikely that they are changing anything fundamental.
However, it's so large that conky might be doing something perfectly legal, but which has an adverse effect on another app. The lack of isolation is another item on the wayland complaints list.
Sorry to be pedantic but when something was released has no bearing on whether something fundamental can still change. Linux was released in 1991.
Commits (just xserver) since the article you posted
Anyone of which has the potential to introduce a bug or regression.
I'm not saying that Xorg is the cause. Just that I think your logic ruling it out is flawed.
You are quite correct. I suppose I should check if conky-1.19.7 works with much older xorg-server.
Xorg is not without defects, for instance it has two different helper librarie sets: Xlib and XCB. One is dated, the other is not-that-well-documented. (I'm oversimplifying).
The Client/Server model may seem outdated (although I personally have no issue with it, from an architectural point of view).
But Wayland is being pushed too hard and too quickly in my humble opinion (I don't really like the fact that each app has to render its own content, I fear we'll end up having one way of rendering windows for each graphical toolkit in existence). But that's off-topic.
It seems to me that the origin of both mine and replarobin's bugs are rooted in the new mouse event management:
- Seems that tint2 crashes (according to the github issue) when the mouse goes over Conky
- Seems that my OpenBox session starts getting really mad when I change my mouse cursor (and other random times that may be related to mouse events?)
There have been a lot of changes happening, both on Conky, Tint2 and Xorg. I don't think Xorg can be excluded, being a some kind of "mediator between everything", just yet.
It stands to reason that my issue happens only with OpenBox and not FluxBox or IceWM, which means it's limited to 3 components: Xorg, OpenBox and Conky. I can't remove Xorg, but if I remove either of the other 2, the issue disappears.
I will try a new bisect soon and see if I get to the same result as the last one.
Followed the excellent advice of gripped above and decided to check what happens with an older xserver I set the archive date at 21//12/2023 (day before the conky-1.19.6-1 release). Then installed the xserver & conky-1.19.7-2 packages and restarted. I still see the tint2 crash with these, but it seems to take a bit longer to excite it.
robin@minikat:~
$ packer -Qs xorg-server
local/xorg-server 21.1.10-1 (xorg)
Xorg X server
local/xorg-server-common 21.1.10-1 (xorg)
Xorg server common files
local/xorg-server-utils 7.6-4
Transition package depending on xorg server utilities
local/xorg-server-xvfb 21.1.10-1 (xorg)
Virtual framebuffer X server
robin@minikat:~
$ packer -Qs conky
local/conky 1.19.7-2
Light-weight system monitor for X, Wayland, and other things, too
lol,
it would be far better to rebuild tint2.
Easy to say, but I'm not a real expert. I think the code that fails is
Area *find_area_under_mouse(void *root, int x, int y)
{
Area *result = root;
Area *new_result = result;
do {
result = new_result;
// EDIT: I inserted here if(!result) break;
GList *it = result->children;
while (it) {
Area *a = (Area *)it->data;
if (area_is_under_mouse(a, x, y)) {
new_result = a;
break;
}
it = it->next;
}
} while (new_result != result);
return result;
}
the failure for me is a segfault so I assume that one of the -> ops fails. I think that must be the result->children ie result has become NULL. I will try returning result if result is NULL.
[EDIT:] I inserted if(!result) break; At line 2 of the do {} while loop. I installed that version of tint2 and it seemed to be OK with conky-1.19.6-1 and also has not crashed with conky-1.19.7-2. I'm just not sure if that is patching a bug in conky or if the original tint2 code is making a wrong assumption.
EDIT 2: if the tint2 fix is thought to be a good thing how should we/I proceed? I assume the PKGBUILD is originally in Arch so a patch needs to be added there as tint2 is now considered finished (The final release of tint2 is 17.0.2.The code is frozen and no more feature requests are accepted.) so should I submit a patch to the Arch maintainer?
EDIT 3: sadly after two days I again see a crash in tint2 when running with conky-1.19.7-2. The SEGV happens in something in tint2 called from handle_x_events. It's whackamole time :(
Hi everyone. I have solved this issue (as good as it gets for now).
The problem isn't exactly with Conky or (openbox from this thread), because it's Tint2 that's crashing (from what I have gathered).
This fix is only for Tint2 crashing, Conky is working fine for me.
This line will fix the problem int tint2
if((e->type==4 || e->type==5 || e->type==6) && e->xproperty.window==server.root_win)
return;
Insert it after line 420 in main.c (source of tint2 from github) to modify the handle_x_event function.
You will have to ofcourse compile and install tint2 again.
I hope it helps
As for the explanation of the problem and fix (I will try my best here)
For whatever reason that I have not fully investigated yet, hovering or clicking on Conky on your desktop triggers a certain kind of event in tint2 which gets poorly handled.
Normally in tint2 the Desktop events are handled fine as they have a different "type" assigned to them, but conky triggers them with type 4 or 5 or 6 (hover, press and release) and window id of the root window. The segfault happens with a null panel is returned and the event handler tries to iterate on it.
My code will make tint2 ignore these events involving conky
My suspicion is that the real problem might be elsewhere like in Conky or Xlib because other widgets on my desktop don't trigger the event in the same way. I have a weather widget and notes widget on my desktop that don't cause tint2 to crash.
This may also have something to do with the settings in conkyrc, mine has the settings
own_window yes
own_window_type 'desktop'
For various reasons like appearance tastes, my conky rc settings let conky blend into the desktop and doesn't show up in the taskbar.
Sine I don't want to change my conky appearance preferences, this will patch the problems with tint2
Let me know if it works out for you guys.
Thanks
I'll give this a try. I have already patched a few places where NULL has been seen in tint2. I will try your fix as well.
One of the Devs on GitHub also suggested an alternative solution that might work as well
" you can build conky with BUILD_XINPUT disabled (cmake -D BUILD_MOUSE_EVENTS=OFF) which will disable related event code in conky."
I can confirm that my fix of tint2 works on several window managers that I have tested (Will probably work on any window manager). It's not the most efficient/elegant solution, but it's a hack that works.
So, it seems there has been some confusion in this thread and it was marked as "Solved" erroneously.
This thread has begun with an issue specifically involving the interaction between Conky and OpenBox (Tint2 has been put out of the equation in my tests, since I used only startx and openbox, without starting Tint2).
It seems that with my issue, another issue (in the same release of Conky) has appeared that made Tint2 crash. (In hindsight, a dedicated thread would have been better). I think it's better to leave Tint2 aside or the thread may become really messy.
There is a patch upstream, as mentioned in the Conky repo issue https://github.com/brndnmtthws/conky/issues/1771, which should stop propagating messages that are not strictly related to input events.
I haven't tested this patch yet, thus I think marking this thread as "solved" is a bit premature.
Yes, in hindsight this thread got a bit confusing. I ended up here though a google search because I wanted to post my fix for tint2 to anyone experiencing the problem. I did not see the whole thread or the topic lol.
I just saw the bits about tint2 and conky.
Well at least one issue is solved now.
Please do try my fix of tint2. It will stop tint2 from crashing when hovering or clicking on conky
Also have you tried this fix? " you can build conky with BUILD_XINPUT disabled (cmake -D BUILD_MOUSE_EVENTS=OFF) which will disable related event code in conky." ~ Github conky issue
I don't know what else is happening with openbox and conky, but disabling input events for conky (which is normally doesnt need anyway) seems like a good idea.
It does seem like Conky was causing problems by forwarding events and what not, some changes have been made to conky source regarding input events so perhaps installing conky from git again will solve your openbox issues. Particularly building it without Mouse events.
Update: There's a New Tint2 package in the Arch and Artix repos now. Tint2 doesn't crash with conky anymore.
hopefully the patch fix is better than my own attempts
I've been testing the git version of Conky for a couple days and it seems the patch solves both the Tint2 crashing and OpenBox memory issues.
The Tint2 patch will make doubly sure that the panel doesn't crash, which is always a good thing.
I think we can mark this thread as solved, since we just need to wait for a new release of Conky.
Thank you everyone for your patience and help.
You might have to update conky from git one more time. There's another small tweak with event propagation in there.
Other than that, it's all solved.
The thought of changing your entire Desktop setup from openbox, conky, tint2 must have been a dark prospect, i've been there.
It's always hard having to change your usual flow.