https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5284
--- Comment #22 from Evan Huus <eapache@xxxxxxxxx> 2012-04-25 14:57:03 PDT ---
(In reply to comment #21)
> (In reply to comment #20)
> > The original option (per-edt memory pools) works correctly in all the cases
> > I've been able to come up with.
>
> Will it really?
> > ep_dissect_new(edt1)
> > ...
> > ep_dissect_new(edt2)
> Stuff with edt1 allocating ep_mamory from pool2?
> > ...
> > ep_dissect_cleanup(edt2)
> pool 2 cleared
> > ...
> > ep_dissect_new(edt3)
> all ep allocs from pool3
> > ...
> > ep_dissect_cleanup(edt3)
> > ...
> > ep_dissect_cleanup(edt1)
> >
>
> Or am I missing something? the refcounting solution might bloat the memory
> usage somewhat but it seems safe(er). on the plus side is also that it shouldn't
> give any performance hit.
My understanding is that even if edt's get nested, the nesting happens outside
of epan_dissect_run() where the key is actually important. So something like:
01 ep_dissect_new(edt1) key = NULL
02 ..ep_dissect_run(edt1) key = edt1
03 ....ep_alloc() .
04 ..ep_dissect_new(edt2) .
05 ....ep_dissect_run(edt2) key = edt2
06 ......ep_alloc() .
07 ..ep_dissect_cleanup(edt2) .
08 ..ep_dissect_new(edt3) .
09 ....ep_dissect_run(edt3) key = edt3
10 ......ep_alloc() .
11 ..ep_dissect_cleanup(edt3) .
12 ep_dissect_cleanup(edt1) .
So that even though we're sort of back in scope for edt1 at line 12 with
key=edt3, no more ep_allocs() happen because the ep_dissect_run() for that edt
(line 02) has already returned.
I could be wrong.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.