Detail: [#171] "data error" / segfault when fiddling with the underlying in_channel value

[#171] "data error" / segfault when fiddling with the underlying in_channel value

Date:
2009-02-24 10:50 Priority:
3

State:
Open

Submitted by:
Stefano Zacchiroli (zack-admin) Assigned to:
Nobody (None)

Operating System:
None Severity:
None

Resolution:
None

URL:

Version:
0.6.0

Summary:
"data error" / segfault when fiddling with the underlying in_channel value

Detailed description
Fiddling with the in_channel value over which bzip2 input channel has been create confuses the bzip2 bindings. As an example, asking for the in_channel length using Pervasives.in_channel_length seems to have the side effect of lseek-ing the underlying file descriptor to the file end (see in_channel_length implementation in byterun/io.c). Further attempt to read bzip-ed data will raise Data_error, or segfaults. The attached patch for examples/bunzip2.ml showcases the problem.

Message
Date: 2009-03-11 20:35 Sender: Olivier Andrieu Right, the channel structure stores the offset in the file. in_channel_length seeks to the end then re-seeks the descriptor to the stored offset. But that value is stale since bzip2 has been reading the file ... The Pervasives.in_channel in the camlbz2 API is simply a convenient way to access the underlying file descriptor without linking with the Unix library. Mind that the Pervasives.in_channel can be closed as soon as the Bz2.in_channel has been created (the fd is dup'ed).

Attachments:

bzip2-crash.patch

Field	Old Value	Date	By
summary	"data error" / segfault when fiddling with the underlying in_channel value	2009-03-11 20:35	oandrieu
File Added	32: bzip2-crash.patch	2009-02-24 10:50	zack-admin