<div class="gmail_quote">2011/1/10 Douglas Kosovic <span dir="ltr"><<a href="mailto:doug@uq.edu.au" target="_blank">doug@uq.edu.au</a>></span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div link="blue" vlink="purple" lang="EN-AU"><div><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">Hi Andrew,</span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">Regarding why the headers now get installed into ‘uclmmbase’ instead of ‘common’, I decided to mimic what the numerous Linux and BSD distributions that currently ship an old uclmmbase package do. I think it also makes sense for consistency as the corresponding library was renamed to uclmmbase over 10 years ago. I was hoping to submit package update requests and patches for Debian/Ubuntu, FreeBSD and NetBSD once the new tarballs for common, vic and rat were released.</span></p>
</div></div></blockquote><div><br>That's fine - certainly better than calling the whole thing just 'common' :) - I just wanted to point out that any previous testing of VPMedia against UCL common would have been incomplete without accounting for that.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-AU"><div><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> Regarding the static libraries, there were a number of applications and utilities looking for the static libraries in common/src, so didn’t want to break them, plus the Linux and BSD distributions didn’t ship static libraries with their existing uclmmbase packages.</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">In Sumover SVN, config_unix.h and config_win32.h have:</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> #ifdef HAVE_CONFIG_H </span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> #include "uclconf.h" </span></p>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> #endif</span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">For config_win32.h, I had to add the HAVE_CONFIG_H pre-processor conditional for VisualStudio which doesn’t use uclconf.h after Andrew Rowley added mingw support. I honestly can’t remember why I added it to config_unix.h, but HAVE_CONFIG_H is automatically defined by the configure script and adds -DHAVE_CONFIG_H to the @DEFS variable in the Makefile.in. I guess the pre-processor conditional could be removed from config_unix.h.</span></p>
</div></div></blockquote><div><br>That seems fine for the lib itself, but -DHAVE_CONFIG_H doesn't get propagated to client apps/libs like VPMedia (should it be added manually in certain cases?), hence the necessity to include uclconf.h manually in VPMedia as it stands. I'm not sure what the best practices are in this case. Are there any cases in which uclconf.h definitely should not be included? (A Visual Studio build on Windows?)<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-AU"><div>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> Sorry I’m not sure about the memory leak issue.</span></p></div></div></blockquote><div><br>I think I fixed this - properly doing xfree on the packet data in the RX_RTP handling in VPMedia's RTP callback function seems to fix the problem (though valgrind complains about the memory freed being a different size than the allocated block? I couldn't quite make sense of that, I'll have to look into that more); I'm just not sure whether it's necessary for the other cases (RX_SDES, RX_BYE, etc.). Can anyone confirm that?<br>
<br>--Andrew<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div link="blue" vlink="purple" lang="EN-AU"><div><p class="MsoNormal">
<span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">Cheers,</span></p>
<p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);">Doug</span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125);"> </span></p><div style="border-width: medium medium medium 1.5pt; border-style: none none none solid; border-color: -moz-use-text-color -moz-use-text-color -moz-use-text-color blue; padding: 0cm 0cm 0cm 4pt;">
<div><div style="border-width: 1pt medium medium; border-style: solid none none; border-color: rgb(181, 196, 223) -moz-use-text-color -moz-use-text-color; padding: 3pt 0cm 0cm;"><p class="MsoNormal"><b><span style="font-size: 10pt;" lang="EN-US">From:</span></b><span style="font-size: 10pt;" lang="EN-US"> <a href="mailto:adhesionmusic@gmail.com" target="_blank">adhesionmusic@gmail.com</a> [mailto:<a href="mailto:adhesionmusic@gmail.com" target="_blank">adhesionmusic@gmail.com</a>] <b>On Behalf Of </b>Andrew Ford<br>
<b>Sent:</b> Tuesday, 11 January 2011 6:44 AM<br><b>To:</b> sumover-dev<br><b>Cc:</b> Piers O'Hanlon; Douglas Kosovic; Rhys Hawkins<br><b>Subject:</b> Re: Possibly memory leak in UCL common/compiling VPMedia against UCL common</span></p>
</div></div><div><div></div><div><p class="MsoNormal"> </p><p class="MsoNormal" style="margin-bottom: 12pt;">On a deeper look (re:the memory leak), it just looks like VPMedia isn't freeing the packet in the RTP callback. I'm not sure why this didn't happen with the if-media version of the common library - it doesn't look like anything related (like RTP_OPT_REUSE_PACKET_BUFS) was changed.<br>
Is it safe to say that the RTP callback should always free that packet regardless of what type it is?<br><br>--Andrew</p><div><p class="MsoNormal">2011/1/10 Andrew Ford <<a href="mailto:andrew.ford@rit.edu" target="_blank">andrew.ford@rit.edu</a>></p>
<p class="MsoNormal">Hi,<br><br>I've been having some issues (on Linux, Ubuntu 10.10) with my video app that relies on VPMedia & the common library. There's a massive memory leak when I tried to switch from using the if-media library to the UCL library - based on some quick valgrind runs it seems to be in rtp_recv. I'm not totally sure yet whether this is actually a problem in the UCL library or if something in VPMedia needs to be changed, I'll be investigating this a bit deeper soon.<br>
<br>I thought I saw some reference in the VPMedia SVN log to compiling against UCL common, but I'm not sure if that was fully tested, since on a normal install, the if-media include files (assuming prefix is /usr/local) actually installs to /usr/local/include/common whereas the UCL version goes to /usr/local/include/uclmmbase, and VPMedia includes files from common/. I changed the includes to point to the right spot before confirming my tests above, so that's not the problem.<br>
<br>Side note - should client apps now directly include uclconf.h? It seems like the if-media version had an #ifdef to include it in certain cases (via config_unix or config_win32) but the most recent UCL code doesn't, so I had to add that manually to VPMedia or else it would complain about things like a #def for endianness not being set.<br>
<br>Also, it looks like the make install target in UCL common doesn't actually copy the static version of the lib (.a), even if static is enabled and it has been built. I haven't checked the specifics in the makefile yet.<br>
<span style="color: rgb(136, 136, 136);"><br>--Andrew</span></p></div><p class="MsoNormal"> </p></div></div></div></div></div></blockquote></div><br>