Opened 3 years ago

Closed 15 months ago

#13108 closed bug (invalid)

[Deskbar] One week running high memory usage

Reported by: joy Owned by: nobody
Priority: normal Milestone: Unscheduled
Component: Applications/Deskbar Version: R1/Development
Keywords: Cc:
Blocked By: Blocking: #13107
Has a Patch: no Platform: x86


After one week of running Haiku 24/7, the memory usage for Deskbar goes up from 6MB to over 200MB.

Attachments (2) (12.5 KB ) - added by joy 3 years ago.
deskbar mem usage (223.8 KB ) - added by joy 3 years ago.

Download all attachments as: .zip

Change History (12)

by joy, 3 years ago

Attachment: deskbar mem usage added

comment:1 by diver, 3 years ago

Blocking: 13107 added

comment:2 by waddlesplash, 3 years ago

(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...)

comment:3 by pulkomandy, 3 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.

in reply to:  3 comment:4 by mmlr, 3 years ago

Replying to pulkomandy:

libroot_debug does not track leaks, ...

Yes it does. See the script help for how to invoke an executable with leak dumping: 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.

Last edited 3 years ago by mmlr (previous) (diff)

comment:5 by joy, 3 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 allocation: base: 0xcddfb8; size: 68; thread: 49364; alignment: 8

<> panic(char const *,...) + 0x41ae (nearest) <> panic(char const *,...) + 0x4699 (nearest) <> panic(char const *,...) + 0x5c13 (nearest) <> panic(char const *,...) + 0x5c42 (nearest) <> malloc + 0x25 <> BMessage::_InitHeader(void) + 0x27 <> BMessage::_InitCommon(bool) + 0x69 <> 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 joy, 3 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 pulkomandy, 3 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.

in reply to:  5 comment:8 by mmlr, 3 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

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 axeld, 3 years ago

Owner: changed from axeld to nobody
Status: newassigned

comment:10 by waddlesplash, 15 months ago

Resolution: invalid
Status: assignedclosed
Note: See TracTickets for help on using tickets.