Opened 21 months ago
Closed 19 months ago
#18357 closed bug (fixed)
Deskbar leaks bitmaps with expanded windows lists
Reported by: | diver | Owned by: | jscipione |
---|---|---|---|
Priority: | normal | Milestone: | R1/beta5 |
Component: | Applications/Deskbar | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | #14694 | |
Platform: | All |
Description (last modified by )
This is hrev56911 x86_64 running in VMware.
Simply opening AboutSystem I can observe in ProcessControler increasing memory usage in app_server and also in Deskbar.
Attachments (1)
Change History (16)
comment:1 by , 21 months ago
comment:3 by , 21 months ago
Also running in VMware.
Perhaps you have some replicants that change things somehow? No idea what the other differences could be...
by , 21 months ago
Attachment: | leaking.png added |
---|
comment:5 by , 21 months ago
You may be able to set a KDL breakpoint on _user_resize_area
, which on an idle system is likely going to be used by app_server most of all, and see what turns up. Like this:
kdebug> symbol _user_resize_area 0xffff... <etc> kdebug> breakpoint 0xffff... kdebug> co
Then when KDL triggers, capture the log (text from serial, please) and paste it here. Do this a few times, if the stack traces look different then paste each one, otherwise just one will do.
comment:6 by , 21 months ago
I tried it twice and both times stack traces looked similar:
Welcome to Kernel Debugging Land... Thread 2072 "kernel_debugger" running on CPU 0 kdebug> symbol _user_resize_rea kdebug> symbol _user_resize_area 0xffffffff8012f480 7 kernel_x86_64:_user_resize_area kdebug> breakpoint 0xffffffff8012f480 kdebug> es PANIC: hit kernel breakpoint: dr6: 0xffff0ff1, dr7: 0x703 Welcome to Kernel Debugging Land... Thread 1813 "a:1787:x-vnd.Be-TSKB" running on CPU 0 stack trace for thread 1813 "a:1787:x-vnd.Be-TSKB" kernel stack: 0xffffffff8185f000 to 0xffffffff81864000 user stack: 0x00007f00011e6000 to 0x00007f0001226000 frame caller <image>:function + offset 0 ffffffff818638e8 (+ 24) ffffffff801478fc <kernel_x86_64> arch_debug_call_with_fault_handler + 0x16 1 ffffffff81863900 (+ 80) ffffffff800b0328 <kernel_x86_64> debug_call_with_fault_handler + 0x78 2 ffffffff81863950 (+ 96) ffffffff800b1993 <kernel_x86_64> kernel_debugger_loop(char const*, char const*, __va_list_tag*, int) + 0xf3 3 ffffffff818639b0 (+ 80) ffffffff800b1d2e <kernel_x86_64> kernel_debugger_internal(char const*, char const*, __va_list_tag*, int) + 0x6e 4 ffffffff81863a00 (+ 240) ffffffff800b2087 <kernel_x86_64> panic + 0xb7 5 ffffffff81863af0 (+ 872) ffffffff801490ec <kernel_x86_64> int_bottom + 0x80 kernel iframe at 0xffffffff81863e58 (end = 0xffffffff81863f20) rax 0xffffffff80190200 rbx 0x100100a18a00 rcx 0x7f0001225250 rdx 0x7f0001225250 rsi 0x21000 rdi 0x5a25 rbp 0xffffffff81863f30 r8 0x100 r9 0x0 r10 0x7f0001225250 r11 0x206 r12 0xffffffff94fe8a80 r13 0x542fbc1 r14 0xc8 r15 0x7f0001225250 rip 0xffffffff8012f480 rsp 0xffffffff81863f28 rflags 0x10246 vector: 0x1, error code: 0x0 6 ffffffff81863e58 (+ 216) ffffffff8012f480 <kernel_x86_64> _user_resize_area + 0x00 user iframe at 0xffffffff81863f30 (end = 0xffffffff81863ff8) rax 0xc8 rbx 0x100100a18a00 rcx 0x1f98c3c rdx 0x7f0001225250 rsi 0x21000 rdi 0x5a25 rbp 0x7f00012251c0 r8 0x100 r9 0x0 r10 0x7f0001225250 r11 0x206 r12 0x1001012be690 r13 0x1000 r14 0x1001000c9430 r15 0x7f0001225250 rip 0x1f98c3c rsp 0x7f0001225148 rflags 0x206 vector: 0x63, error code: 0x0 7 ffffffff81863f30 (+139640117662352) 0000000001f98c3c <libroot.so> _kern_resize_area + 0x0c 8 00007f00012251c0 (+ 80) 000000000066485e <_APP_> ClientMemoryAllocator::Allocate(unsigned long, block**, bool&) + 0x10e 9 00007f0001225210 (+ 160) 0000000000662c43 <_APP_> BitmapManager::CreateBitmap(ClientMemoryAllocator*, HWInterface&, BRect, color_space, unsigned int, int, int, unsigned char*) + 0x1c3 10 00007f00012252b0 (+2864) 0000000000685148 <_APP_> ServerApp::_DispatchMessage(int, BPrivate::LinkReceiver&) + 0x54f8 11 00007f0001225de0 (+ 208) 0000000000686a75 <_APP_> ServerApp::_MessageLooper() + 0x115 12 00007f0001225eb0 (+ 16) 000000000067916a <_APP_> MessageLooper::_message_thread(void*) + 0x0a 13 00007f0001225ec0 (+ 32) 0000000001f97b79 <libroot.so> _thread_do_exit_work (nearest) + 0x89 14 00007f0001225ee0 (+ 0) 00007f0001081258 <commpage> commpage_thread_exit + 0x00
comment:7 by , 21 months ago
It appears there is a bitmap leak, potentially in Deskbar's main thread. So this may be a Deskbar problem, not an app_server problem.
comment:8 by , 21 months ago
Component: | Servers/app_server → Applications/Deskbar |
---|---|
Description: | modified (diff) |
Owner: | changed from | to
Summary: | [app_server] memory leak triggered by AboutSystem → Deskbar leaks bitmaps with expanded windows lists |
To reproduce make sure you have at least one application window list expanded with at least one item. It doesn't have to be AboutSystem.
comment:9 by , 21 months ago
Probably of interest:
The bt of the 'Expando Window Watcher' thread is:
kdebug> bt 1458 stack trace for thread 1458 "Expando Window Watcher" kernel stack: 0xffffffff82051000 to 0xffffffff82056000 user stack: 0x00007f55e98e7000 to 0x00007f55e9927000 frame caller <image>:function + offset 0 ffffffff82055d30 (+ 112) ffffffff8009ba44 <kernel_x86_64> reschedule(int) + 0x424 1 ffffffff82055da0 (+ 48) ffffffff8008b376 <kernel_x86_64> thread_block + 0xc6 2 ffffffff82055dd0 (+ 112) ffffffff80057aeb <kernel_x86_64> ConditionVariableEntry::Wait(unsigned int, long) + 0xcb 3 ffffffff82055e40 (+ 144) ffffffff8006f0fc <kernel_x86_64> _get_port_message_info_etc + 0x11c 4 ffffffff82055ed0 (+ 80) ffffffff8007021b <kernel_x86_64> _user_port_buffer_size_etc + 0x4b 5 ffffffff82055f20 (+ 16) ffffffff801493ef <kernel_x86_64> x86_64_syscall_entry + 0xfb user iframe at 0xffffffff82055f30 (end = 0xffffffff82055ff8) rax 0xdc rbx 0x7fffffffffffffff rcx 0xba3ba4ad7c rdx 0x7fffffffffffffff rsi 0x0 rdi 0x79 rbp 0x7f55e9925d50 r8 0x0 r9 0x0 r10 0x0 r11 0x246 r12 0x0 r13 0x1038803226a0 r14 0x1038803226a0 r15 0x7f55e9925dc4 rip 0xba3ba4ad7c rsp 0x7f55e9925d28 rflags 0x246 vector: 0x63, error code: 0x0 6 ffffffff82055f30 (+140009081208352) 000000ba3ba4ad7c <libroot.so> _kern_port_buffer_size_etc + 0x0c 7 00007f55e9925d50 (+ 64) 000000c6fde97026 <libbe.so> BPrivate::LinkReceiver::ReadFromPort(long) + 0x26 8 00007f55e9925d90 (+ 32) 000000c6fde96fd9 <libbe.so> BPrivate::LinkReceiver::GetNextMessage(int&, long) + 0x69 9 00007f55e9925db0 (+ 224) 000000c6fdebb269 <libbe.so> BBitmap::_InitObject(BRect, color_space, unsigned int, int, screen_id, int, long) + 0x3f9 10 00007f55e9925e90 (+ 96) 000000c6fdebb863 <libbe.so> BBitmap::BBitmap(BRect, color_space, bool, bool) + 0xd3 11 00007f55e9925ef0 (+ 64) 000001df9121935a <_APP_> TWindowMenuItem::_FetchWindowVectorIcon(int) + 0xaa 12 00007f55e9925f30 (+ 128) 000001df91219585 <_APP_> TWindowMenuItem::_Init(char const*) + 0x1d5 13 00007f55e9925fb0 (+ 192) 000001df9120949b <_APP_> TExpandoMenuBar::monitor_team_windows(void*) + 0x2cb 14 00007f55e9926070 (+ 32) 000000ba3ba49b79 <libroot.so> _thread_do_exit_work (nearest) + 0x89 15 00007f55e9926090 (+ 0) 00007ff1adb0d258 <commpage> commpage_thread_exit + 0x00
comment:10 by , 21 months ago
Probably we should only allocate and initialize the bitmaps a single time, for efficiency's sake, instead of once per window menu item, anyway.
comment:11 by , 21 months ago
I haven't read the full thing for the details, but it seems that's how it was before the change to vectors, with the ResourceSet taking care of it, and that would be why the bitmap was not deleted on TWindowMenuItem destruction. Now the vector icon takes that place but a new bitmap is created each time and never deleted.
comment:12 by , 21 months ago
I am able to reproduce the crash, looks like it is crashing trying to grab the window icon in Switcher for some reason. The memory leak is probably caused by the window icon not being deleted properly when the window menu gets expanded and unexpanded.
Reverting for now to spare crashing and leaking while I sort this out.
comment:13 by , 21 months ago
Blocking: | 14694 added |
---|---|
Status: | new → in-progress |
comment:14 by , 21 months ago
Can you please link to such comments in commit messages when reverting, or at least a comment to explain why. There is zero context in the commit message, which is honestly really bad practice.
comment:15 by , 19 months ago
Milestone: | Unscheduled → R1/beta5 |
---|---|
Resolution: | → fixed |
Status: | in-progress → closed |
Revised change merged in hrev57017.
Cannot seem to reproduce here on hrev56912. AboutSystem open, ProcessController open, no apparent memory increase. Waited multiple minutes, app_server consumption has not moved.
I have seen app_server memory leaks recently, though: https://discuss.haiku-os.org/t/real-life-haiku-os-r1-beta4-64bit-testing-on-raw-metal/13283/21