Comment # 15
on bug 8089
from Evan Huus
(In reply to comment #14)
> (In reply to comment #11)
>
> Evan, Thanks so much for your continued help with this, it means alot!
>
> > Regarding the memory leak, an extra thank you for pointing out your source -
> > it looks like packet-synphasor also leaks, so somebody will have to fix that
> > :)
>
> Cool, glad to help point out other existing stuff that I probably shouldn't
> have used as reference material. :)
>
> > I can't point to any precise examples off the top of my head, but in general
> > it looks like you're implementing conversation management, in which case I
> > would point you to section 2.2 of README.developer. Note the use wmem memory
> > in the example (section 2.2.3) such that the memory doesn't have to be
> > manually freed, nor does it need to be specially protected in the case of an
> > exception - the library handles everything for you when the capture file is
> > closed.
>
> I looked at 2.2.3 and it seems pretty clear that the memory allocation
> behind the pointer to the fm_config_frame structure is where the memory leak
> could occur. I took a first-pass try at implementing the wmem library in
> the dissector at Line 1904. I'm not sure that wmem should still be used
> with the other G* memory functions but the modifications still seem to
> functional operate the same when compiled?
No, wmem should not be used with other glib memory functions, as wmem memory is
not necessarily allocated via glib. The reason it continues to work is that
you're never actually using it - you allocate wmem memory correctly and then
immediately (on the very next line) reassign that variable to the result of
fmconfig_frame_fast, whose memory comes from glib still.
I expect most of the wmem work will be in fmconfig_frame_fast - all the calls
to g_slice_new and g_array_* in that function should be replaced with similar
or equivalent wmem calls. If wmem doesn't provide an exact equivalent it should
be pretty easy to mimic with regular wmem_alloc() calls, or I can take a stab
at adding to the wmem arsenal.
> > Also, GCC (the linux compiler) still has some issues with the file that are
> > worth fixing:
> >
>
> Thanks for pointing those additional warnings out, this darn MSVC compiler
> isn't quite as picky as the GCC one (go figure) so it's nice to get those
> possible issues cleaned up! I ended up modifying all the proto_items and
> proto_trees to be initialized as NULL, just to avoid any possible
> uninitialized use of them.
http://cppcheck.sourceforge.net/ is a cross-platform analyzer that will catch
most of the same issues GCC will but can still be run on Windows. If you have a
cygwin environment set up you can even use the tools/cppcheck/cppcheck.sh
script in SVN to run it configured specially for use with wireshark.
You are receiving this mail because:
- You are watching all bug changes.
