Wireshark-bugs: [Wireshark-bugs] [Bug 9033] wmem assertion after changing preferences before loa
Jeff Morriss
changed
bug 9033
| What |
Removed |
Added |
| CC |
|
jeff.morriss.ws@gmail.com
|
Comment # 6
on bug 9033
from Jeff Morriss
(In reply to comment #2)
> (In reply to comment #1)
> > CCing Jakub; since this doesn't happen in 1.10 I suspect his epan_new
> > changes triggered this.
>
> epan_session introduction (r50761) was very clean,
> - all cleanup_dissection() changed to epan_free()
> - all init_dissection() changed to epan_new()
>
> I'd rather suggest blaming Jeff's r51188 ;] and reverting it fix a problem.
Really? Maybe I misunderstood that change then. I made it because we were
calling epan_free() twice in a row and the 2nd one seemed redundant to me.
(In reply to comment #4)
> (In reply to comment #3)
> > The broader problem is that we unconditionally call epan_free (previously
> > cleanup_dissection) in places like cf_open (tshark.c:3806) where we don't
> > necessarily have a file open.
>
> > epan_free should be called when the old file
> > is closed, not when the new file is opened.
>
> Why? free(0) is NOP. It'd be best if epan_free(0) would be also NOP.
Sure but it also gets confusing: "OK, we're initializing! Wait, let's free
something [but why, we're initializing?]! OK, still initializing..." I mean
it's confusing for the person reading the code and trying to figure out what's
going on. And when I'm looking at the freeing code won't expect it to be
called during initialization.
You are receiving this mail because:
- You are watching all bug changes.
