https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3725
Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jeff.morriss.ws@xxxxxxxxx
--- Comment #4 from Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 2010-08-02 08:25:00 PDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > That in itself is not a problem. As long as there's a free for every
> > allocation. Sometimes you can assure that easily, sometimes not. That's where
> > ep_/se_ memory comes in.
>
> What happens if memory is allocated then the packet is malformed before the
> free occurs? Or what happens if memory is allocated, but the packet is
> truncated due to the snaplen and dissection is aborted before the memory can be
> freed?
This memory is then leaked. This is one of the major reasons ep_ and se_
memory exist: exceptions may prevent the freeing of memory.
> I haven't looked at all the instances of g_malloc and g_new that grep found, so
> maybe there really isn't a problem for all those other dissectors, even in the
> case of malformed and/or truncated packets. But I suspect there are potential
> dangers lurking. The results of grep also show a small trend of increasing use
> of g_malloc, so new or modified dissectors that had previously not had a memory
> allocation problem might now have one. You guys are the experts, not me, so I
> don't want to definitively claim there are problems here, but I just thought
> I'd mention it in case. Thanks.
Personally I think one needs a very good reason to use non-ep or non-se
allocated memory... (I think there are some places where we need new ep_ or
se_ APIs to make this easier.)
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.