Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 5802] Rewrite&cleanup wiretap/file_wrappers

Date: Sun, 10 Apr 2011 10:17:44 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5802

--- Comment #36 from Jakub Zawadzki <darkjames@xxxxxxxxxxxxxxxx> 2011-04-10 10:17:38 PDT ---
Created an attachment (id=6153)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=6153)
Some debug code

(In reply to comment #35)
> When doing the sequential read, the calls to raw_read() are, with the offsets
> into the compressed file at the time raw_read() is called being:
> 
> 265203712
> [cut]
> 265535488
> 
> with the call at the last offset returning 0 bytes, causing an EOF while
> inflating.
> 
> The random reads after that start with a fast seek to an offset of 265260508,
> followed by raw_read() calls with offsets of:
> 
> 265260508
> [cut]
> 265534940
> 
> with the call at the last offset returning 0 bytes, causing an EOF while
> inflating.

How did you get these offsets? ->raw_pos or lseek(..., 0, SEEK_CUR)?

> It did several other raw_read() calls at the same offset, as it's trying to get
> the contents of the other packets; they all got 0 bytes back.
> 
> The problem isn't that it's getting a premature EOF; the problem is that the
> random reads are aborting with a premature EOF when they're trying to read
> packets for which it *didn't* get a premature EOF in the sequential read pass.

Can you get output from this patch?
I really can't think of anything else other than wrongly set eof mark or
incorrect raw_pos.

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