Hi!
I'm using bzip2 v0.6.1 with libbzip2-rs in my project cryptcrypt. It loads chunks of 1 MBytes (1024 * 1024 bytes) from a file, compresses and encrypts them. Compression works fine for most input files. Unfortunately with one input file I get the following exception:
libbzip2-rs: internal error number 1002.
This is a bug in libbzip2-rs, 1.1.0-libbz2-rs-sys-0.2.4.
The full backtrace is in bzip_backtrace.txt
I could narrow down the input file to a 1-MB-chunk showing the issue. It is in data_input_bzip_err.dmp (it is actually a binary chunk
of a macOS .dmg file).
Compression is called in my code in compress_buffer() (My analysis was done on branch compresslen)
I rolled back the libbzip2-rs versions and found, the issue first occurred with
libbz2-rs-sys v0.2.3
Further rolling back the (most appropriate) commits from there resulted in this commit first reproducing the issue:
8b6d794 - Apr 7 - use count_ones
It seems, the replacement of the while-loop with count_ones() caused the issue in libbz2-rs-sys/src/blocksort.rs.
For my better understanding I printed in the line below count_ones():
println!("{:#x} {}", bbSize, shifts);
For the failure, the print output ends with
0x9092 0
0x1a804 1
0x20136 1
Then I replaced the count_ones() with the original while-loop replaced by commit 8b6d794
and the successful compression shows this print output at the end:
0x9092 0
0x1a804 1
0x20136 2
0x20357 2
As far as I understand it, please correct me if I'm wrong, the while loop was not counting the ones, but was looking for the relative location of the highest one (above 0xFFFF).
In the nightly-only experimental API of std there is a i32::highest_one() which might fit here in the future, when it is stable. In the meantime you might need the old while loop or something similar.
Please let me know if I can help with more information or anything else.
Hi!
I'm using bzip2 v0.6.1 with libbzip2-rs in my project cryptcrypt. It loads chunks of 1 MBytes (1024 * 1024 bytes) from a file, compresses and encrypts them. Compression works fine for most input files. Unfortunately with one input file I get the following exception:
The full backtrace is in bzip_backtrace.txt
I could narrow down the input file to a 1-MB-chunk showing the issue. It is in data_input_bzip_err.dmp (it is actually a binary chunk
of a macOS .dmg file).
Compression is called in my code in compress_buffer() (My analysis was done on branch compresslen)
I rolled back the libbzip2-rs versions and found, the issue first occurred with
libbz2-rs-sys v0.2.3
Further rolling back the (most appropriate) commits from there resulted in this commit first reproducing the issue:
8b6d794 - Apr 7 - use
count_onesIt seems, the replacement of the while-loop with count_ones() caused the issue in
libbz2-rs-sys/src/blocksort.rs.For my better understanding I printed in the line below count_ones():
println!("{:#x} {}", bbSize, shifts);
For the failure, the print output ends with
0x9092 0
0x1a804 1
0x20136 1
Then I replaced the count_ones() with the original while-loop replaced by commit 8b6d794
and the successful compression shows this print output at the end:
0x9092 0
0x1a804 1
0x20136 2
0x20357 2
As far as I understand it, please correct me if I'm wrong, the while loop was not counting the ones, but was looking for the relative location of the highest one (above 0xFFFF).
In the nightly-only experimental API of std there is a i32::highest_one() which might fit here in the future, when it is stable. In the meantime you might need the old while loop or something similar.
Please let me know if I can help with more information or anything else.