Valgrind produced a log file of over 1 megabyte plain text.<br>How do I even start with that one, I have no c programming experience I wouldn't know where to start looking in that file, it's huge.<br><br>most of the errors are like this one <br>
2 bytes in 1 blocks are possibly lost in loss record 2 of 2,812<br>and after a huge amount of those I get a leak summary<br>==12720== definitely lost: 0 bytes in 0 blocks<br>==12720== indirectly lost: 0 bytes in 0 blocks<br>
==12720== possibly lost: 81,333 bytes in 1,641 blocks<br>==12720== still reachable: 169,581 bytes in 1,794 blocks<br>==12720== suppressed: 0 bytes in 0 blocks<br>==12720== Reachable blocks (those to which a pointer was found) are not shown.<br>
==12720== To see them, rerun with: --leak-check=full --show-reachable=yes<br>==12720==<br>==12720== For counts of detected and suppressed errors, rerun with: -v<br>==12720== ERROR SUMMARY: 1189 errors from 1189 contexts (suppressed: 3 from 3)<br>
<br>after which I get an awfull lot of these :<br>--12720-- Warning: unhandled socketcall 0x12<br><br>interrupted by this once (I started apache here to enable mythweb)<br>==12720== Thread 18:<br>==12720== Conditional jump or move depends on uninitialised value(s)<br>
==12720== at 0x551CBAE: QTransform::fromScale(double, double) (in /usr/lib/libQtGui.so.4.6.3)<br>==12720== by 0x542ABAE: QImage::scaled(QSize const&, Qt::AspectRatioMode, Qt::TransformationMode) const (in /usr/lib/libQtGui.so.4.6.3)<br>
==12720== by 0x81431A5: ??? (in /usr/bin/mythbackend)<br>==12720== by 0x814CCD2: ??? (in /usr/bin/mythbackend)<br>==12720== by 0x4A9EC0F: HttpServer::DelegateRequest(HttpWorkerThread*, HTTPRequest*) (in /usr/lib/libmythupnp-0.23.1.so.0.23.1)<br>
==12720== by 0x4A9F288: HttpWorkerThread::ProcessWork() (in /usr/lib/libmythupnp-0.23.1.so.0.23.1)<br>==12720== by 0x4A9C287: WorkerThread::WakeForWork() (in /usr/lib/libmythupnp-0.23.1.so.0.23.1)<br>==12720== by 0x4A9C4F1: WorkerEvent::customEvent(QEvent*) (in /usr/lib/libmythupnp-0.23.1.so.0.23.1)<br>
==12720== by 0x5F3A99B: QObject::event(QEvent*) (in /usr/lib/libQtCore.so.4.6.3)<br>==12720== by 0x5F28058: QCoreApplicationPrivate::notify_helper(QObject*, QEvent*) (in /usr/lib/libQtCore.so.4.6.3)<br>==12720== by 0x5F280D7: QCoreApplication::notify(QObject*, QEvent*) (in /usr/lib/libQtCore.so.4.6.3)<br>
==12720== by 0x5F27E0D: QCoreApplication::notifyInternal(QObject*, QEvent*) (in /usr/lib/libQtCore.so.4.6.3)<br>==12720==<br><br>a lot more of these<br>--12720-- Warning: unhandled socketcall 0x12<br><br>untill it crashes at the end with this message<br>
==12720==<br>==12720== Valgrind's memory management: out of memory:<br>==12720== newSuperblock's request for 4194304 bytes failed.<br>==12720== 3034054656 bytes have already been allocated.<br>==12720== Valgrind cannot continue. Sorry.<br>
==12720==<br>==12720== There are several possible reasons for this.<br>==12720== - You have some kind of memory limit in place. Look at the<br>==12720== output of 'ulimit -a'. Is there a limit on the size of<br>
==12720== virtual memory or address space?<br>==12720== - You have run out of swap space.<br>==12720== - Valgrind has a bug. If you think this is the case or you are<br>==12720== not sure, please let us know and we'll try to fix it.<br>
==12720== Please note that programs can take substantially more memory than<br>==12720== normal when running under Valgrind tools, eg. up to twice or<br>==12720== more, depending on the tool. On a 64-bit machine, Valgrind<br>
==12720== should be able to make use of up 32GB memory. On a 32-bit<br>==12720== machine, Valgrind should be able to use all the memory available<br>==12720== to a single process, up to 4GB if that's how you have your<br>
==12720== kernel configured. Most 32-bit Linux setups allow a maximum of<br>==12720== 3GB per process.<br>==12720==<br>==12720== Whatever the reason, Valgrind cannot continue. Sorry.<br><br>For me the log file might as well be empty because I cannot make anything from it.<br>
<br>Rob Verduijn<br><br><div class="gmail_quote">2010/10/31 Brian J. Murrell <span dir="ltr"><<a href="mailto:brian@interlinx.bc.ca">brian@interlinx.bc.ca</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 class="im">On Sun, 2010-10-31 at 20:49 +0000, James Courtier-Dutton wrote:<br>
><br>
> myth does not have a memory leak here.<br>
<br>
</div>What you mean is that myth does not have a memory leak for your<br>
use-case. You cannot of course know for sure that myth doesn't have a<br>
memory leak for some use-case which does not apply to you.<br>
<div class="im"><br>
> I use the SVN version, and it is compiled with debug switched on.<br>
> It sits on about 700M of virtual memory and about 3% CPU, but I have a<br>
> fast CPU and my mythfrontend is on a different PC.<br>
<br>
</div>And again, doesn't leak for _your_use-case_. That of course doesn't<br>
mean that OP's use-case doesn't follow some different code path that is<br>
leaking memory.<br>
<div class="im"><br>
> If you want to track this down, I would try the same, get the SVN<br>
> version, compile it in debug mode.<br>
<br>
</div>Well, no. The right way to track it down has already been suggested and<br>
that's to actually audit the memory use with a tool like valgrind.<br>
Simply switching to a different tool does neither prove nor disprove<br>
that the previous tool was faulty and leaves you guessing, at best.<br>
<font color="#888888"><br>
b.<br>
<br>
</font><br>_______________________________________________<br>
mythtv-users mailing list<br>
<a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br>
<a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users" target="_blank">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users</a><br>
<br></blockquote></div><br>