From: "Dr. Uwe Girlich
Sent: Tuesday, November 19, 2002 9:48 PM
Subject: [Ethereal-dev] valgrind results
> Hello!
>
> > Anyone who wants to test: build and install valgrind (trivial!).
> > Run it (I think I posted the command line parameters I used back then)
> > against any traces you happen to have.
> > Report back in case you find something.
> I got with valgrind ./tethereal -r crash.trace file some problems in DCE.
> 10 times I get blocks like:
>
> ==23444== Conditional jump or move depends on uninitialised value(s)
> ==23444== at 0x80B0741: srvsvc_dissect_SERVER_INFO_UNION
(packet-dcerpc-srvsvc.c:5165)
> ==23444== by 0x8089F8A: dissect_deferred_pointers (packet-dcerpc.c:976)
> ==23444== by 0x808A4D7: dissect_ndr_pointer (packet-dcerpc.c:1304)
> ==23444== by 0x80B100E: srvsvc_dissect_netrservergetinfo_reply
(packet-dcerpc-srvsvc.c:5616)
> I suspect, there are cases, where dissect_ndr_uint32() does not put
anything in
> the &level address.
>
> One of the summary line at the end reads:
> ==23444== malloc/free: in use at exit: 1429768 bytes in 7116 blocks.
>
> Should we try to reduce this number or is it not so important?
>
Yes definitely. This would be very useful for those that use ethereal on
large captures.
AFAIK there should not be any state kept between captures, but if a capture
is currently loaded
there might be state remaining when ehterela exists.
Could you create one minimal capture file only containing one single packet.
Load the tiny capture.
1) Make if possible a fingerprint of what data had been allocated.
Load a huge capture.
2) Make a fingerprint of what allocations have been made.
Load the tiny capture again.
3) See which allocations between 1 and 2 that is still allocated.
AFAIK state should be nulled whenever a capture is loaded.
If there are lots of state/memory allocated between 1 and 2 which have not
been freed in 3 this might point to a memory leak.
Could you find where those blocks were allocated?