[haiku-bugs] Re: [Haiku] #9458: Memory leak in BMediaFile -> BMediaTrack

  • From: "Haiku" <trac@xxxxxxxxxxxx>
  • To: undisclosed-recipients: ;
  • Date: Thu, 22 Dec 2022 14:13:29 -0000

#9458: Memory leak in BMediaFile -> BMediaTrack
--------------------------+------------------------------------------------
  Reporter:  Robert S.    |      Owner:  leavengood
      Type:  bug          |     Status:  assigned
  Priority:  normal       |  Milestone:  R1
 Component:  Kits/Media   |    Version:  R1/Development
  Kit                     |
Resolution:               |   Keywords:  BMediaFile BMediaTrack memory leak
Blocked By:               |   Blocking:  18160
  Platform:  All          |
--------------------------+------------------------------------------------
Comment (by pulkomandy):

 I am on a 64 bit install now so ffmpeg backtraces seem to be working. And
 the leak reproduces here as well.

 I have made a simple test consisting of one single loop of the provided
 test program, and I have added manual dumps of the heap before and after,
 using the heap_debug_dump_allocations function.

 This way it's easy to see the leaked memory, there are 8 differences:

 - Two allocations of 104 bytes
 - Two allocations of 40 bytes
 - Three allocations of 1064 bytes
 - One allocation of 10792 bytes

 After each repeptition, the allocations of 104 and 40 bytes do not
 reappear, but the other ones do:

 - Three allocations of 1064 bytes
 - One allocation of 10792 bytes

 So, this is our leak. Now to identify which structure or buffer these
 sizes correspond to.

 I have set a breakpoint in mosix_memalign and I am checking the rdx
 register to compare it to the size of these leaked allocations. I found
 the 10792 bytes one is from _Setup in AVCodecEncoder, which always re-
 inits a new ffmpeg context without releasing the previous one. But it can
 be called multiple times, for example in SetQuality. So I have simply
 added code to free that context at the start of the function and that leak
 is gone.

 I found also a possible set of smaller leaks caused by dynamically loadd
 libraries, but I am not sure if it is a big problem or not. For example,
 libgomp has a pthread_attr_init and I'm not sure if the corresponding
 pthread_attr_destroy is being called. I'll have to check more closely
 after I have fixed the larger leaks.
-- 
Ticket URL: <https://dev.haiku-os.org/ticket/9458#comment:17>
Haiku <https://dev.haiku-os.org>
The Haiku operating system.

Other related posts: