Skip to main content ↑ ↓
Topic solved
This topic has been marked as solved and requires no further attention.
Topic: Openbox leaking memory? (Read 2120 times) previous topic - next topic
0 Members and 4 Guests are viewing this topic.

Openbox leaking memory?

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:

Code: [Select]
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.

Re: Openbox leaking memory?

Reply #1 –
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 ?

Re: Openbox leaking memory?

Reply #2 –
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.

Re: Openbox leaking memory?

Reply #3 –
Quote from: Penaz – on
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]

Re: Openbox leaking memory?

Reply #4 –
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.

Re: Openbox leaking memory?

Reply #5 –
Quote from: Penaz – on
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.
You wouldn't need to reset.
Just create a new user:
Code: [Select]
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
Quote
Btop shows also that at least 1 core of the CPU is stuck at 100%, but no processes are actually using that much CPU.
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.

Re: Openbox leaking memory?

Reply #6 –
Quote from: Penaz – on
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.

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.

Re: Openbox leaking memory?

Reply #7 –
Quote from: Penaz – on
My desktop is just pure openbox, with Tint2 as taskbar and a couple of Conky configurations.

I would take a closer look at the network activities.
Or do you only work with openbox, conky, tint2 and kitty?  :o
"Wer alles kann, macht nichts richtig"

Artix USE="runit openrc slim openbox lxde gtk2 qt4 qt5 qt6 conky
-gtk3 -gtk4 -adwaita{cursors,themes,icons} -gnome3 -kde -plasma -wayland "

Re: Openbox leaking memory?

Reply #8 –
Quote from: Hitman – on
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.

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.

Quote from: gripped – on
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.

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.

Quote from: lq – on
Quote from: Penaz – on
My desktop is just pure openbox, with Tint2 as taskbar and a couple of Conky configurations.

I would take a closer look at the network activities.
Or do you only work with openbox, conky, tint2 and kitty?  :o

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.

Quote from: replabrobin – on
I maintain a local AUR to build slim based on https://sourceforge.net/projects/slim-fork/ it's not in Arch AUR as yet.

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

Code: [Select]
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

Code: [Select]
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 ...]
 

Re: Openbox leaking memory?

Reply #9 –
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.

Re: Openbox leaking memory?

Reply #10 –
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.

Quote from: gripped – on
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.

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.

Re: Openbox leaking memory?

Reply #11 –
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.

Re: Openbox leaking memory?

Reply #12 –
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?

Quote
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.
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

Re: Openbox leaking memory?

Reply #13 –
Quote from: Hitman – on
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.

I checked, deleted .Xdefaults and .config/.gtk-3.0/settings.ini without result.

Quote from: Hitman – on
Do you still use Picom as compositor during this testing? Try without it, then maybe change it's backend between xrender and glx?

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!


Quote from: Hitman – on
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

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!

Re: Openbox leaking memory?

Reply #14 –
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).