Wireshark-bugs: [Wireshark-bugs] [Bug 3737] Wireshark crash when attempting to display frame wit
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3737
Bill Meier <wmeier@xxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
Summary|out of memory on version |Wireshark crash when
|1.2.0 when loading 13MB |attempting to display frame
|capture file |with multiple large
| |byteview tabs
--- Comment #18 from Bill Meier <wmeier@xxxxxxxxxxx> 2011-12-20 15:56:38 EST ---
I've determined that this bug (at least as manifested by the
PERF8_wireshark_OOM capture file attached to this bug) is related to an issue
with Gtk 2.16 (and presumably earlier ?).
Specifically, a crash occurs (with the PERF8_wireshark_OOM capture file) when
selecting frame 4659 which results in the attempted display of several very
large byteview tabs.
The crash is not an "out of memory" crash, but is actually due to memory
corruption which occurs only when a "delayed progress bar" is displayed while
creating a byteview tab. The memory corruption is not a Wireshark bug but seems
to be caused by the Gtk GtkTextView/GtkTextBuffer code itself.
The crash does not occur after updating to Gtk 2.22.
So: I'm marking this bug as fixed.
I'm also updating the summary to reflect the actual problem seen.
(It's certainly possible that the original problem was "out of memory" for the
file mentioned in Comment #1. However, as noted, the crash which occurs for the
file attached as "tcpdump trace causing as OOM" is something different.
Additional notes:
My tests were done on Windows.
HTTP dechunking itself is working OK (although I did commit a fix to speed up
dechunking).
All of the tests I've done on both of the attached capture files did not
actually shown any "out of memory" issues.
The tests do show *extremely* slow CPU-intensive display of frames with detail
panes containing many many thousands of nodes and containing multiple
multi-megabyte sized byteview tabs.
So: The capture files do provide a good Wireshark stress test and could very
well be used to help investigate Wireshark performance.
(I'll open a new "improve performance" enhancement request pointing to the
capture files in this bug).
--
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.
