OCaml Forge
SCM

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

Bugs: Browse | Download .csv | Monitor

[#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)
Resolution:
None
Severity:
None
Operating System:
None
Version:
0.6.0
URL:
 
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.

Followup

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).

Attached Files:

Attachments:
bzip2-crash.patch

Changes:

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