BMediaFile leak (or leakS)

[ttcoder]

Three leaks (two confirmed) (I'm currently in hrev48619):

• easily confirmed 196 bytes leak in the ctor, using the ten-line test-case .cpp in #9945
• easily confirmed 196 bytes leak in BMediaFile::Track(), using the same (with some semi-random speculation in ticket:9945#comment:9 that the leak might have been introduced e.g. in the low r47000s range)
• got word that our build of SoundPlay used with December hrevs consumes up to 0.6 MB per hour or more (there's a case of 150 MB in a couple days) whereas the same build didn't leak at all when run on early PM builds or 46104 (last non-PM build), but we're still trying to confirm that one. That would be something bigger than a leaked thread of 196 bytes if true, so might be in the media-kit instead of libroot in this third case.. Got to collect more data and confirm, since other variables have changed (the plugins loaded into SP for one).

Tentatively setting above-average priority since this has a significant impact on our users.

[ttcoder]

Didn't test 47198 yet but found a somewhat old install with hrev48168 and it has the exact same leak I initially found in hrev48619.

To find the (big) remainder of the leak I tried adding calls to BMediaFile's TrackAt(), and BMediaTrack's CountFrames(), DecodedFormat() and ReadFrames() to my test case from #9945 but that has no additional impact on memory usage. I must be missing something.. Also awaiting real-world test data from dsuden, that should help lots.

[Barrett]

Have you got any detailed info about the third leak? Also which method you mean for BMediaFile::Track()? I think you missed something.

[ttcoder]

More general leak, affecting even the deskbar (will file another ticket)

[ttcoder]

Thanks for looking at this Barrett

The sample code in 9945 is indeed only half the story; if I didn't mess up finding the right files in my archive, the missing bit looks like this:

		BMediaTrack * mediaTrack = mediaFile->TrackAt(0);  // will be Release()d in dtor
		
		media_format decodedmediaformat;
		memset( &decodedmediaformat, 0, sizeof(decodedmediaformat) );
		decodedmediaformat.type = B_MEDIA_RAW_AUDIO;
		ret = mediaTrack->DecodedFormat( &decodedmediaformat );
		
		for( ;; )
		{
			char buf[8192] = { 0 };
			int64 numread = 0;
			ret = mediaTrack->ReadFrames(buf,&numread);
	//		printf( "got %Ld frames.. ", numread );
	//heap_debug_dump_allocations( true, find_thread(NULL));// fflush(stdout);
			
			if( ret < 0 )
				break;
		}

As to the third leak, dsuden's latest data (see above) shows it's not related to media_kit, it's more general in nature (even the Deskbar gets high mem usage after 10 days, north of 78 MB!) so I'll file another ticket for that one. And this one should be downgraded to normal priority by someone who has ticket edit privileges I suppose.

Just gotta find the time to keep a computer up for 10 days, or find a better way to replicate what dsuden is seeing on our shipped systems..

EDIT - note to self: to take into account axel's comment below, I should be careful to note in the upcoming ticket, the difference (if any) there was between when we shipped early PM builds, versus more recent ones now.

[axeld]

Please note that all tray add-ons end up in Deskbar's memory pool, too, so to be sure one would have to check it in several ways (without add-ons, with just one of each that were activated, etc.).

There is also a fair chance that we are talking about many different leaks here.

[Barrett]

Just to get out another idea, since it seems those leaks are common to the whole system, it may be possible that it's a mixture of fragmentation and page not released by the hoard allocator?

[ttcoder]

Dario let's move the discussion about the third, difficult to diagnose, suspected leak to #11941 ; see if you can Cc yourself there (does not work for me but not needed anyway for me in that case :-)

Edit: also someone with edit privileges might want to rename this ticket to simply "BMediafile leak", singular)

[ttcoder]

Please close. :-)

Ran the test again here and both 196 bytes leaks are gone now (maybe due to mmlr's hrev49018 ..etc ?)

~/Desktop/leak 11752> gcc -g BMediaFile-leak.cpp -lbe -lmedia -lroot_debug
~/Desktop/leak 11752> uname -a
Haiku shredder 1 hrev49041 Apr 16 2015 05:27:29 BePC x86 Haiku
~/Desktop/leak 11752> LD_PRELOAD=libroot_debug.so ./BMediaFile-leak
total allocations: 353; total bytes: 64721
[wav @ 0x1808b800] max_analyze_duration 5000000 reached at 5015510
total allocations: 1687; total bytes: 1305574
total allocations: 1219; total bytes: 277043
(..)
[wav @ 0x1808b800] max_analyze_duration 5000000 reached at 5015510
total allocations: 1687; total bytes: 1305574
total allocations: 1219; total bytes: 277043
[wav @ 0x1808b800] max_analyze_duration 5000000 reached at 5015510
total allocations: 1687; total bytes: 1305574
total allocations: 1219; total bytes: 277043