#13108 closed bug (invalid)
[Deskbar] One week running high memory usage
Reported by: | joy | Owned by: | nobody |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Applications/Deskbar | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #13107 | |
Platform: | x86 |
Description
After one week of running Haiku 24/7, the memory usage for Deskbar goes up from 6MB to over 200MB.
Attachments (2)
Change History (13)
by , 8 years ago
Attachment: | Deskbar-518-debug-11-12-2016-21-21-00.report added |
---|
by , 8 years ago
Attachment: | deskbar mem usage added |
---|
comment:1 by , 8 years ago
Blocking: | 13107 added |
---|
comment:2 by , 8 years ago
follow-up: 4 comment:3 by , 8 years ago
libroot_debug does not track leaks, only use-after-free. It's possible to use it to get some memory use stats, but that needs to be manually enabled in the source of the debugged app:
extern void heap_debug_dump_allocations(bool statsOnly, thread_id thread);
It would at least help to identify the thread responsible for the leak.
A list of replicants (tray icons) you have in deskbar is also relevant, as one of them may be at fault.
comment:4 by , 8 years ago
Replying to pulkomandy:
libroot_debug does not track leaks, ...
Yes it does. See the leak_analyser.sh script help for how to invoke an executable with leak dumping:
LD_PRELOAD=libroot_debug.so MALLOC_DEBUG=ges50 program > file
The 'e' switch of the MALLOC_DEBUG env enables allocation dumping on exit, while 'g' enables the guarded heap (needed to have the info collected) and 's' enabling/lengthening the allocation vs. deallocation stacktrace.
Run it through the script to filter out common false positives and get some stats. Either of these outputs can be attached here.
follow-up: 8 comment:5 by , 8 years ago
I have not manage to run LD_PRELOAD with Deskbar, it only starts the prefernce for Deskbar and output a 220KB file...
But from that run i get this leak when i parce the output threw leak_analyser.sh: allocation: base: 0xcddfb8; size: 68; thread: 49364; alignment: 8
<libroot.so> panic(char const *,...) + 0x41ae (nearest) <libroot.so> panic(char const *,...) + 0x4699 (nearest) <libroot.so> panic(char const *,...) + 0x5c13 (nearest) <libroot.so> panic(char const *,...) + 0x5c42 (nearest) <libroot.so> malloc + 0x25 <libbe.so> BMessage::_InitHeader(void) + 0x27 <libbe.so> BMessage::_InitCommon(bool) + 0x69 <libbe.so> BMessage::BMessage(unsigned long) + 0x33 <_APP_> main + 0x51 <_APP_> _start + 0x5b 0x1924cf2 (lookup failed: Invalid Argument) 0x61230250 (lookup failed: Invalid Argument)
total leaks: 1
comment:6 by , 8 years ago
But i think i found the source of the leak.
When i have qBittorrent runing, Deskbars memory usage rizes and stops when i exit qBittorrent.
Right now i have been runing Haiku for 14 days. Deskbar "only" got to 173MB, but qBittorrent has only been runing for a total of 8 day(For trying to testing this leak)
comment:7 by , 8 years ago
In that case it could be a bug in qsystray (the helper app that allows getting Qt apps to put icons in the deskbar) or the QBitTorrent system tray icon. That would mean there is nothing we can do about it on Haiku side, it has to be fixed in the Qt port.
comment:8 by , 8 years ago
Replying to joy:
I have not manage to run LD_PRELOAD with Deskbar, it only starts the prefernce for Deskbar and output a 220KB file...
That is because /system/preferences
, where the Deskbar preferences reside, is in the $PATH while /system
, where the Deskbar itself resides for legacy reasons, is not. Hence invoking just Deskbar
will hit the preferences, not the actual Deskbar (the prefs will also run the Deskbar though). You have to use the full path /system/Deskbar
instead for it to work. Also you'll have to stop the running Deskbar (and prevent the launch_daemon from automatically restarting it) via launch_roster stop x-vnd.be-tskb
.
Since the problem seems to be in either qsystray or QBitTorrent (or their respective ports), this report should be closed. Still getting the leak check output might be useful as a basis for opening a bugreport with the project at fault (or rather HaikuPorts?), as it might already show what's going on.
comment:9 by , 8 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:10 by , 6 years ago
Resolution: | → invalid |
---|---|
Status: | assigned → closed |
comment:11 by , 5 years ago
Milestone: | Unscheduled |
---|
Remove milestone for tickets with status = closed and resolution != fixed
(For anyone trying to open the "deskbar mem usage file" anywhere but Haiku: It's a WonderBrush image.)
I don't get any obvious output after a few minutes of running Deskbar under libroot_debug and using it normally (opening/closing apps, settings, menu, Death Grip, etc.) which would seem to imply it's not a memory leak - or else it isn't occuring on my machine.
Do you know how to use libroot_debug, and if so, could you please do so to see if there's some difference on your end? (It might be caused by a replicant, etc...)