Evan Huus
changed
bug 9033
| What |
Removed |
Added |
| Status |
CONFIRMED
|
RESOLVED
|
| Resolution |
---
|
FIXED
|
Comment # 3
on bug 9033
from Evan Huus
(In reply to comment #2)
> > There are probably two issues here:
> > - rescan_packets should bail because there is no file open
> > - if it doesn't bail, it should clean up the epan it creates so that wmem
> > leaves file scope
>
> - wmem shouldn't do stupid assertions.
These are the kind of weird bugs that those assertions are meant to catch. If
it hadn't asserted there is the possibility of all sorts of bizarre subtle
errors.
> > 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.
>
> Hot potato...
Interesting - this seems also related to the XXX comment at wmem_scopes.c:109.
The root problem seems to be that our scope management is horribly inconsistent
:/
I have fixed this particular bug in r51327 by not rescanning packets if there
is no file open (and doing it before any epan session is created, so there is
no leak).
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. Rescan_packets has an 'excuse' in that
it can reasonably expect to only be called if there is a file open.
You are receiving this mail because:
- You are watching all bug changes.