Deskbar leaks bitmaps with expanded windows lists

[diver]

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.

[waddlesplash]

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

[diver]

Reproducible here in vmware in hrev56912 after a fresh reboot.

[waddlesplash]

Also running in VMware.

Perhaps you have some replicants that change things somehow? No idea what the other differences could be...

[diver]

I quit all of the replicants and even Tracker - same thing.

[waddlesplash]

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.

[diver]

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

[waddlesplash]

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.

[madmax]

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.

[madmax]

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

[waddlesplash]

Probably we should only allocate and initialize the bitmaps a single time, for efficiency's sake, instead of once per window menu item, anyway.

[madmax]

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.

[jscipione]

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.

[jessicah]

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.

[waddlesplash]

Revised change merged in hrev57017.