BMessenger Memory Leak in kernel_team

[AGMS]

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.

[AGMS]

Program to recreate the BMessenger kernel_team memory leak.

[AGMS]

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.

[ttcoder]

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.

[waddlesplash]

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

[waddlesplash]

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

[AGMS]

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.

[ttcoder]

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.

[waddlesplash]

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 :)

[ttcoder]

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

[nielx]

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