Wireshark-bugs: [Wireshark-bugs] [Bug 4450] New: Intermittant crash in http dissector if reassem
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4450
Summary: Intermittant crash in http dissector if reassemble
http headers is enabled
Product: Wireshark
Version: SVN
Platform: x86
OS/Version: Windows XP
Status: NEW
Severity: Major
Priority: High
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: jyoung@xxxxxxx
Build Information:
Version 1.3.3 (SVN Rev 31765 from /trunk)
Copyright 1998-2010 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.18.5, with GLib 2.22.3, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, without libpcre, with SMI 0.4.8,
with c-ares 1.7.0, with Lua 5.1, without Python, with GnuTLS 2.8.5, with Gcrypt
1.4.5, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built Feb 1
2010), with AirPcap, with new_packet_list.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.1
(packet.dll version 4.1.0.1753), based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 2.8.5, Gcrypt 1.4.5, with AirPcap 4.1.0 build 1622.
Built using Microsoft Visual C++ 9.0 build 30729
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
Hello,
In the current development version of Wireshark I see intermittant crashes when
opening traces files that contain http packets. This occurs both with Windows
x86 Buildbot versions and Windows x86 version I build locally.
When the crash occurs I will see a message similar to the following in the
debug console window:
20:17:02 Warn Dissector bug, protocol HTTP, in packet 14986:
STATUS_ACCESS_VIOLATION: dissector accessed an invalid memory address
The actual packet # that is reported can change from crash to crash even though
I open the same trace file.
I can generally trigger the crash with one particular large trace file (~213MB
400318 frames). The crash generally will _NOT_ occur when I first open the
file but when I open the file a second time.
Steps to reproduce (with my large http trace file) assuming that the "problem"
file had been opened successsfully in the past:
1. Open Wireshark.
2. Use the "one click" option to open the large trace file (1st file on list).
3. Wait for file to load.
4. Use the File | Open Recent menu option to select the problem file (1st on
list).
5. The transient "Loading" dialog will appear.
6. After a few seconds Wireshark will crash triggering the Windows' "Wireshark
has encountered a problem and needs to close." dialog.
I can't trigger the crash if I disable (uncheck) the HTTP preference:
"Reassemble HTTP headers spanning multiple TCP segments"
I believe the underlying problem has been present for quite some time. I tested
a number of older SVN versions. With changes made around SVN 30488 the crash
became much more likely to occur. But the problem predates SVN 30488. For
example with 30487 I can occasionally trigger this crash. But with an older
buildbot version (SVN 30378) I was unable to reproduce this problem. As
expected, removing the changes applied to epan/emem.c with SVN 30488 did _NOT_
make this problem go away.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
