Apply the fix from bug 8539 (r48796) to another function (dissect_r3_upstreamcommand_queryconfig()):
Bail out of the item length we get (which we use to increment the offset) is 0.
Otherwise the offset does not advance and we loop forever.
While we're in there: get the item length just once (there's no need to call
tvb_get_guint8() a half dozen times when one will do).
svn path=/trunk/; revision=49744
Check that the record length we got out of the file is at least as big as
stats block trailer; if not, declare the file bad.
svn path=/trunk/; revision=49739
The entity offset variable parameter uses either offset or orientation but not
both, this caused the data displayed to be skewed.
svn path=/trunk/; revision=49736
seek offset is after calling it, they can use file_tell(). (Some
routines were already assuming it returned a gboolean.)
svn path=/trunk/; revision=49733
As suggested by Jakub, don't use strlen() when g_string->len will do.
From me:
Don't assume that just because we "got_val" that the value has a length.
Checking it first eliminates this warning from Valgrind:
==11954== Invalid read of size 1
==11954== at 0x61D1466: read_prefs_file (prefs.c:3012)
==11954== by 0x61D1841: read_prefs (prefs.c:2955)
==11954== by 0x409901: main (tshark.c:1137)
==11954== Address 0xc05244f is 1 bytes before a block of size 16 alloc'd
==11954== at 0x4A08A6E: realloc (vg_replace_malloc.c:662)
==11954== by 0x3CF8C4D736: g_realloc (in /usr/lib64/libglib-2.0.so.0.3400.2)
==11954== by 0x3CF8C66226: ??? (in /usr/lib64/libglib-2.0.so.0.3400.2)
==11954== by 0x3CF8C66ACE: g_string_insert_c (in /usr/lib64/libglib-2.0.so.0.3400.2)
==11954== by 0x61D1566: read_prefs_file (gstring.h:139)
==11954== by 0x61D1841: read_prefs (prefs.c:2955)
==11954== by 0x409901: main (tshark.c:1137)
svn path=/trunk/; revision=49731
that the complaints are valid, or that simply zeroing them is the right fix
if they are, but at least it builds now. Should we be erroring if we don't
see a sliceLength header?
svn path=/trunk/; revision=49705
frame_table field to NULL before trying to allocate the frame table, so
that if we fail before we allocate the frame table, the attempt to free
the private data doesn't crash due to the frame_table field containing a
bogus pointer.
svn path=/trunk/; revision=49697
I'm stil not sure the copying of the packet_info structure is necessary (or what the consequences are), but at least it's not global anymore.
col_set_fence may be needed to prevent overwriting by PPP dissector, Caching COL_INFO (or the other columns) into it's own string was way more work than necessary and could lead to no column info on a malformed packet.
svn path=/trunk/; revision=49689
The looping logic is a bit odd, and there was a case where we were never
incrementing any of the multiple loop variables. I suspect the entire function
could be simplified, but this commit fixes the hang and is better suited to
backporting than anything complex.
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8730
svn path=/trunk/; revision=49686
Anders Broman