test failures on big endian systems about zstd

[Cyan4973]

Hi Kevin

Thanks for notification.
It should work, so I hope to get them supported.

Is there a way to get some detailed log, rather than just the result ?
It's difficult to debug with so little information.

Rgds

[kdm9]

Hi Yann,

Thanks for trying to fix this. The build logs are available from the links in the right of the table in the link above (the buildd status page). An example (from powerpc) is https://buildd.debian.org/status/fetch.php?pkg=libzstd&arch=powerpc&ver=0.4.7-1&stamp=1454594505

The buildd status page interface could do with a refresh, apologies there is no better way. I don't have access to machines of any of these archs to do any further testing, so I can't offer any help there.

It could be doable with qemu or similar visualisation tools, but I've never done that.

Cheers,
K

[Cyan4973]

Thanks, got it, by clicking on the arrow link.

Compressed 18000000 bytes into 2561849 bytes ==> 14.23%
Completed in 46.52 sec 
Files tmp1 and tmp2 differ

It's a pretty late test, which means compression / decompression round trip worked quite a few times before that point, hence it's not a too trivial endianess problem (would have failed much sooner).

Let's have a look into this issue.

I'm supposed to have a Qemu PPC emulator available. Hopefully, it can reproduce this issue.

[Edit] : follow up : problem can be reproduced on a Qemu PPC emulator. Seems to start at compression levels >= 16. Likely an issue within the Binary tree code.

[Cyan4973]

I suspect I got it.
There was a big-endian-specific error in a compression sub-routine, which, in most circumstances, would just translate in a slightly lower compression ratio for big-endian. But in the case of binary tree (levels >= 16), it would degenerate into a corruption error.

This will be fixed into v0.5.1

Regards

[kdm9]

Hi Yann,

Beautiful! Thanks for a very speedy investigation and fix.

I'll upload the fix shortly after it's posted.

Cheers,
K

[Cyan4973]

Fixed within v0.5.1