Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#15489 closed bug (fixed)

BMessenger Memory Leak in kernel_team

Reported by: AGMS Owned by: waddlesplash
Priority: normal Milestone: R1/beta2
Component: System/Kernel Version: R1/Development
Keywords: BMessenger Kernel Memory Leak Cc: agmsmith@…, ttcoder
Blocked By: Blocking:
Platform: All

Description

Using BMessengers to send messages to multiple applications seems to leak kernel memory. Shutting down the test application and the target applications doesn't release the memory either. This isn't a problem in BeOS.

To test, use ProcessController to watch the kernel_team memory usage, and run the attached test program. It uses around 10KB of memory per second, which adds up after a few days.

Attachments (1)

KernelLeaker.cpp (3.9 KB ) - added by AGMS 5 years ago.
Program to recreate the BMessenger kernel_team memory leak.

Download all attachments as: .zip

Change History (10)

by AGMS, 5 years ago

Attachment: KernelLeaker.cpp added

Program to recreate the BMessenger kernel_team memory leak.

comment:1 by AGMS, 5 years ago

Another possibility is that sending a BMessage to a dead BLooper uses up memory (there are some in that example program - turn in the print statement to see them). Though quitting the target programs would supposedly release that memory.

comment:2 by ttcoder, 5 years ago

Cc: ttcoder added

CC5 was making massive use of BMessengers to communicate with SoundPlay, so it would have been the primary victim of this bug at the time. CC6 has its own audio engine, I wonder if that means it's less affected by that bug, i.e. does kernel memory go up (and remain high even after quitting CC6) or not.

comment:3 by waddlesplash, 5 years ago

Owner: changed from nobody to waddlesplash
Status: newin-progress

Yep, I found the bug; it was introduced as part of the fix for #8007 in 2013. :)

comment:4 by waddlesplash, 5 years ago

Resolution: fixed
Status: in-progressclosed

Fixed in hrev53595. Thanks for the excellent test-case!

comment:5 by AGMS, 5 years ago

Glad that test case helped. It took a day to figure out what was triggering the leak (at least it was easy to see the memory use ticking up), then an hour to extract code and make a sample program.

comment:6 by ttcoder, 5 years ago

Holy cow I remember 8007, even by its ticket ID alone.

Kudos to you AGMS! And to you waddlesplash, considering the non trivial size of the BMessage/BMessenger/ports code it must have taken a wee bit of time (!) to track the leak down as being caused by ports, and further track down the port heap leak as a reference problem. Thanks.

comment:7 by waddlesplash, 5 years ago

Actually, not really. Once I has the test case I just turned on kernel allocations logging, and then saw the only allocations occuring while running the test case and nothing else was the kernel port heap. Then it was a simple jump from there to see that port objects were never getting freed, etc. Probably took under an hour in total. Easy testcases make a the difference :)

comment:8 by ttcoder, 5 years ago

So "work smarter, not harder", then, good on you! I love me some state-of-the-art tracing too, esp. in complex apps.

comment:9 by nielx, 5 years ago

Milestone: UnscheduledR1/beta2

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone

Note: See TracTickets for help on using tickets.