On 9/28/05, Reggie Braswell <[EMAIL PROTECTED]> wrote:
Axel - by copy FYI I am using 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)
==3529== by 0x9859CD: clone (in /lib/libc-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)
==3529== by 0xB14541: pthread_create@@GLIBC_2.1 (in /lib/libpthread-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
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
Shawn Asmussen
_______________________________________________ mythtv-users mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
