Wireshark-bugs: [Wireshark-bugs] [Bug 2407] wshark crashes expert info composite
Date: Thu, 3 Apr 2008 15:08:48 +0000 (GMT)
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2407


Jim Young <jyoung@xxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jyoung@xxxxxxx




--- Comment #2 from Jim Young <jyoung@xxxxxxx>  2008-04-03 15:08:45 GMT ---
Hello Patrick,

I don't think it's the fact that you have more than 40'000 packets that
triggers this particular bug.  It's probably more to do with what is
specifically within one or more of those 40'000 packets.   

I could NOT replicate this bug using several different trace files on a Windows
XP machine running the standard win32 Wireshark v1.0.0.  These trace files had
between 140'000 and 190'000 frames.   In my tests the trace files were composed
primarily of UDP (bootp) and ICMP packets. (But I intend to try replicating
this bug using trace files with more typical type data.)

Couple of ideas... 

If you haven't already tried, could you try splitting one of the greater than
40'000 packet files into several smaller parts and seeing if one of those
smaller trace files stills triggers the bug?   You can easily split a big trace
into subset files with Wireshark's "editcap" command line utility, e.g.:

   > editcap -c 10000 bigtrace.pcap littletrace

The command above would generate one or more trace files with the naming
convention of littletrace-00001, littletrace-00002, etc.  All but the last
trace file will have 10'000 frames.

If you CAN replicate the bug with a particular subset file, you can then easily
repeat this process on the subset file and perhaps get the bug trigger down to
a specific frame.

But if you can NOT replicate the bug with the subset files (and if nobody else
can replicate the bug with their own traces) it will probably be useful if you
could attach the problem trace file to this bug report.  Before uploading the
trace file you might want to compress the file with gzip.  If the trace file
contains "sensitive" data you will probably need one of the core developers to
first flag this bug as private before you upload the trace file.

I hope this helps.

Jim Y.



-- 
Configure bugmail: http://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.