[mythtv-users] Re: Transcode memory leak in FC4

[Shawn Asmussen]

On 9/28/05, Reggie Braswell <reggman at gmail.com> wrote:
>
> Axel - by copy FYI I am using transcode-1.0.0-18.rhfc4.at<http://transcode-1.0.0-18.rhfc4.at/>
>
> More on the this issue. Not sure if this is a bug with Fedora, Transcode
> or Axel's rpm. Two machines both scratch installs of FC4 - both not freeing
> memory after job completion.
>
> Free before job=
> total used free shared buffers cached
> Mem: 1034276 329188 705088 0 15564 164096
> -/+ buffers/cache: 149528 884748
> Swap: 2032212 0 2032212
>
> valgrind output for transcode job =
> ==3529==
> ==3529== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 30 from 1)
> ==3529== malloc/free: in use at exit: 797 bytes in 13 blocks.
> ==3529== malloc/free: 356935 allocs, 356922 frees, 54619173 bytes
> allocated.
> ==3529== For counts of detected errors, rerun with: -v
> ==3529== searching for pointers to 13 not-freed blocks.
> ==3529== checked 31638172 bytes.
> ==3529==
> ==3529== 5 bytes in 1 blocks are definitely lost in loss record 1 of 11
> ==3529== at 0x1B909222: malloc (vg_replace_malloc.c:130)
> ==3529== by 0x1E4C5505: ???
> ==3529== by 0x1E4C75A4: ???
> ==3529== by 0x805ED23: tcv_export (in /usr/bin/transcode)
> ==3529== by 0x805DFC7: encoder_stop (in /usr/bin/transcode)
> ==3529== by 0x805A6B0: main (in /usr/bin/transcode)
> ==3529==
> ==3529==
> ==3529== 60 bytes in 1 blocks are definitely lost in loss record 6 of 11
> ==3529== at 0x1B909222: malloc (vg_replace_malloc.c:130)
> ==3529== by 0x8078747: new_fc_time (in /usr/bin/transcode)
> ==3529== by 0x8057F45: main (in /usr/bin/transcode)
> ==3529==
> ==3529==
> ==3529== 64 (20 direct, 44 indirect) bytes in 1 blocks are definitely lost
> in loss record 7 of 11
> ==3529== at 0x1B909222: malloc (vg_replace_malloc.c:130)
> ==3529== by 0x1E4A971D: ???
> ==3529== by 0x1E4A8E79: ???
> ==3529== by 0xB14B7F: start_thread (in /lib/libpthread- 2.3.5.so<http://2.3.5.so/>
> )
> ==3529== by 0x9859CD: clone (in /lib/libc-2.3.5.so <http://2.3.5.so/>)
> ==3529==
> ==3529==
> ==3529== 408 bytes in 3 blocks are possibly lost in loss record 11 of 11
> ==3529== at 0x1B909B71: calloc (vg_replace_malloc.c:175)
> ==3529== by 0x1B8F4831: _dl_allocate_tls (in /lib/ld- 2.3.5.so<http://2.3.5.so/>
> )
> ==3529== by 0xB14541: pthread_create@@GLIBC_2.1 (in /lib/libpthread-
> 2.3.5.so <http://2.3.5.so/>)
> ==3529== by 0x8051C1B: main (in /usr/bin/transcode)
> ==3529==
> ==3529== LEAK SUMMARY:
> ==3529== definitely lost: 85 bytes in 3 blocks.
> ==3529== indirectly lost: 44 bytes in 1 blocks.
> ==3529== possibly lost: 408 bytes in 3 blocks.
> ==3529== still reachable: 260 bytes in 6 blocks.
> ==3529== suppressed: 0 bytes in 0 blocks.
> ==3529== Reachable blocks (those to which a pointer was found) are not
> shown.
> ==3529== To see them, rerun with: --show-reachable=yes

 Although the transcode binary apparently fails to free a few bytes that it
allocated, not freeing malloc'd memory usually only generally matters for
programs that run as daemons, where memory is repeatedly malloc'd and not
free'd, thus slowly eating up any and all available memory on the system. It
doesn't really matter in this case, because when the program exits, the
allocated memory is reclaimed whether it was explicitly free'd by the
program or not. At any rate, even if it wasn't being reclaimed when the
program exitted, the LEAK SUMMARY from valgrind shown above shows less than
1K lost, which you wouldn't really be able to notice using the free command
anyway.

free output after job completion:
> total used free shared buffers cached
> Mem: 1034276 1017780 16496 0 3220 839700
> -/+ buffers/cache: 174860 859416
> Swap: 2032212 988 2031224

  Most of the memory used in this second execution of the free command is
accounted for by the increase in the 'cached' column. This memory has just
been used as disk cache by the Linux kernel, which normally tries to keep
the actual 'free' memory fairly low by using as much free memory as possible
for caching. However, for practical purposes this memory is still available,
because the Linux kernel can and will throw out as much of its disk cache as
it needs to in order to fulfil actual requests for allocation of memory.

Next steps are possibly rolling back to FC3 and using Dags or possible
> scratch and compile from source.
> Anyone else out there seen this issue?
>
> Thanks Regg
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>
>
>
 Shawn Asmussen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20050928/e346dfa8/attachment.htm