#9945: BMediaFile leaks ca. 100 KB ------------------------------------+---------------------------- Reporter: ttcoder | Owner: nobody Type: bug | Status: new Priority: normal | Milestone: R1 Component: Audio & Video/Codecs | Version: R1/Development Resolution: | Keywords: ffmpeg Blocked By: | Blocking: Has a Patch: 0 | Platform: All ------------------------------------+---------------------------- Changes (by ttcoder): * priority: high => normal Comment: @korli: Roxors! kudos to you. The leak went down dramatically from 100KB (in multiple allocs) to 2072 bytes (in one alloc): {{{ src_plugins> LD_PRELOAD=libroot_debug.so ./BMediaFile-leak (....) total allocations: 824; total bytes: 196008 total allocations: 826; total bytes: 200152 total allocations: 827; total bytes: 202224 total allocations: 828; total bytes: 204296 total allocations: 829; total bytes: 206368 total allocations: 830; total bytes: 208440 total allocations: 831; total bytes: 210512 total allocations: 832; total bytes: 212584 total allocations: 833; total bytes: 214656 }}} Leaking 50 times more slowly than before, a station could go on for close to a year before even needing an app restart. Bug's 99% fixed and no longer urgent in my mind at all. @anevilyak: no matter how many times I run the above .cpp from Terminal, its {{{new BMediaFile}}} constructor call always allocates the object at the same address, as is the embedded mp3 codec (see below); I probably misunderstand what ASLR is about though, that would be odd if my simple test case had uncovered a kernel problem of any sort. This is with hrev46033 retrieved just now. Run 1: {{{ src_plugins> LD_PRELOAD=libroot_debug.so ./BMediaFile-leak [mp3 @ 0x18092800] max_analyze_duration 5000000 reached at 5015510 ... }}} Run 2: {{{ src_plugins> LD_PRELOAD=libroot_debug.so ./BMediaFile-leak [mp3 @ 0x18092800] max_analyze_duration 5000000 reached at 5015510 ... }}} -- Ticket URL: <http://dev.haiku-os.org/ticket/9945#comment:7> Haiku <http://dev.haiku-os.org> Haiku - the operating system.