Roundtrip error under am64

[GoogleCodeExporter]

A user reported invalid roundtrip results for the Perl interface under Ubuntu 
amd64. I was able to able to reproduce using Virtualbox with the plain C 
library. The error is not present when compiling as a 32-bit executable with 
-m32.

Attached are the c program I used and the input file.

$ uname -a
Linux ubuntu 3.0.0-12-server #20-Ubuntu SMP Fri Oct 7 16:36:30 UTC 2011 x86_64 
x86_64 x86_64 GNU/Linux

Original issue reported on code.google.com by g...@cpan.org on 17 Mar 2012 at 12:39

[GoogleCodeExporter]

Original comment by g...@cpan.org on 17 Mar 2012 at 12:41

Attachments:

• roundtrip.c
• input.txt

[GoogleCodeExporter]

I will look into it.

Original comment by yann.col...@gmail.com on 17 Mar 2012 at 9:04

• Changed state: Accepted

[GoogleCodeExporter]

For some reason, i was unable to reproduce the issue using the file input.txt 
provided here.

The test is done in a vmWare Ubuntu64 11.10 VM, host CPU is Core 2 Duo. The 
binary compiled is a 64-bit one (provided in attached file). I made 3 
verification tests, using your program (roundtrip), a comparison script (cmp) 
and internal checksum (-b). All seem to work so far on input.txt.

Original comment by yann.col...@gmail.com on 17 Mar 2012 at 9:27

Attachments:

• graytest64

[GoogleCodeExporter]

After paying closer attention to your Makefile, I see the difference. Within 
roundtrip.c, I am including the c file instead of the header file and simply 
compiling like so 'gcc roundtrip.c'. This has worked fine for me in the past 
with other libraries. When I switch to how you're doing it with multiple c 
files (include the header file instead of the c file and compile with 'gcc 
lz4.c rountrip.c') the problem disappears. I'm not fluent enough in C to 
understand why it matters in this particular case, but as long as I see a 
resolution, we can call this issue closed.

Original comment by g...@cpan.org on 17 Mar 2012 at 10:23

[GoogleCodeExporter]

OK.
It's strange, because i've compiled graytest64 using your methodology 
(including lz4.c), and it did not advertised any issue.

Using separated lz4.h/lz4.c is necessary in case LZ4 functions are called in 
several places of the code. Otherwise, including several times lz4.c would 
generate duplicate, and linking stage would fail.

But in this particular situation, there is only one single file, so it should 
work the same...

Well, anyway, as long as you've got a solution... Let's call it closed, for now.

Original comment by yann.col...@gmail.com on 17 Mar 2012 at 11:06

[GoogleCodeExporter]

Original comment by yann.col...@gmail.com on 17 Mar 2012 at 11:07

• Changed state: Fixed