Bug ID |
9527
|
Summary |
TShark and Wireshark hang reading a particular MPEG-2 TS file
|
Classification |
Unclassified
|
Product |
Wireshark
|
Version |
SVN
|
Hardware |
x86
|
OS |
Mac OS X 10.8
|
Status |
UNCONFIRMED
|
Severity |
Major
|
Priority |
Low
|
Component |
Dissection engine (libwireshark)
|
Assignee |
[email protected]
|
Reporter |
[email protected]
|
Build Information:
TShark 1.11.3 (SVN Rev 53841 from /trunk)
Copyright 1998-2013 Gerald Combs <[email protected]> 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 (64-bit) with GLib 2.36.0, with libpcap, with libz 1.2.5, without
POSIX
capabilities, with SMI 0.4.8, without c-ares, without ADNS, with Lua 5.1,
without Python, with GnuTLS 2.12.19, with Gcrypt 1.5.0, with MIT Kerberos, with
GeoIP.
Running on Mac OS X 10.8.5, build 12F45 (Darwin 12.5.0), with locale
en_US.UTF-8, with libpcap version 1.1.1, with libz 1.2.5.
Intel(R) Core(TM) i7-3820QM CPU @ 2.70GHz
Built using llvm-gcc 4.2.1 (Based on Apple Inc. build 5658) (LLVM build
2336.11.00).
--
If I try reading the file from
http://www.aktiv-verlag.com/~webvideos/testvideos/2010/panasonic/Panasonic_HDC_TM_700_P_50i.MTS
(which is also part of the Wireshark menagerie, so it might be attached to some
other bug) in TShark or reading it in Wireshark, it appears to get stuck,
spending lots of time in
static void
LINK_FRAG(fragment_head *fd_head,fragment_item *fd)
{
fragment_item *fd_i;
/* add fragment to list, keep list sorted */
for(fd_i= fd_head; fd_i->next;fd_i=fd_i->next) {
if (fd->offset < fd_i->next->offset )
break;
}
fd->next=fd_i->next;
fd_i->next=fd;
}
Some debugging printouts seem to indicate that there's a list of fragments with
at least two sequential fragments having a fragment offset of 0.
You are receiving this mail because:
- You are watching all bug changes.