Test failure on PowerPC

[Keith Harry]

Library version 1.4.1
Cross compiled for ppc_85xx

I have a simple test application that compresses some IPv4/UDP packets and then decompresses them. When the application is run on a powerpc platform the decompress will get CRC errors for some of the packets.

It appears that this is an endian issue in c_generic.c where there are a couple of places that declare an id as a unsigned int but treat it as a short for a memcpy which results in zeros being copied instead of the desired value.

I've attached the patch that makes my test application run without errors.

[Didier Barvaux (didier-barvaux)]

Hi,

Thank for your bug report, and for the patch!

I prefer using uint16_t instead of unsigned short, so I modified your patch a little bit. Could you please confirm me that your application runs without error with this new patch?

Version 1.3.3 is also affected (same code as 1.4.1), but it seems that trunk is not. Could you please test the trunk on your PowerPC 85xx board? If you do not known how to retrieve trunk sources, see http://rohc-lib.org/wiki/doku.php?id=library-hacking#get_source_code_with_bazaar

Regards,
Didier

[Keith Harry (keith-harry)]

Trunk seems to work fine.

There seems to be another issue if you allocate the compressor with LARGE_CID_MAX you will get decompress CRC errors
[ERROR] [d_generic.c:7329 check_ir_crc()] CRC failure (computed = 0xb3, packet = 0xb7)
[ERROR] [d_generic.c:3019 decode_ir()] CRC detected a transmission failure for IR packet
[ERROR] [rohc_decomp.c:702 d_decode_header()] failed to decompress IR packet (code = -4)

I haven't really had time to dig into it and I don't need to use large CIDs. Suspect it is a similar endian issue. You might want to look at that code, maybe you can spot something.

[Didier Barvaux (didier-barvaux)]

> Trunk seems to work fine.

Cool!

Does the patch with uint16_t works as expected for 1.4.1?

> There seems to be another issue if you allocate the compressor with LARGE_CID_MAX you will get decompress CRC errors

I will look at this problem. On what branch did you test large CIDs? trunk or 1.4.x?

Regards,
Didier

[Keith Harry (keith-harry)]

Yes the uint16_t works as expected.

The issue with large CIDs has been observed on both trunk and 1.4.1. The error output I provided came from trunk.

[Didier Barvaux (didier-barvaux)]

OK. I committed the patch on 1.3.x and 1.4.x branches. See http://bazaar.launchpad.net/~didier-barvaux/rohc/1.3.x/revision/202 and http://bazaar.launchpad.net/~didier-barvaux/rohc/1.4.x/revision/348

I'll look at the large CID problem tomorrow.

[Didier Barvaux (didier-barvaux)]

I setup a test environment for PowerPC:
 - a powerpc-softfloat-linux-gnu cross-compiler to build the libraries and binaries from sources,
 - qemu-ppc to run the tests on my x86 development system.

The sources build fine, however several non-regression tests fail with the trunk:
http://buildbot.rohc-lib.org:8011/builders/rohc-library-main-ppc_on_x86-gcc45/builds/4

[Didier Barvaux (didier-barvaux)]

To FWX: as you had problems with PowerPC some time ago, you might be interested by this bug.

[Didier Barvaux (didier-barvaux)]

Fix comitted in trunk. The SN bits in the FEEDBACK-2 code was not correctly handled wrt endianness.

See http://bazaar.launchpad.net/~didier-barvaux/rohc/main/revision/524

[Didier Barvaux (didier-barvaux)]

Keith: could please test again the trunk with revision >= 524?

[Didier Barvaux (didier-barvaux)]

Won't fix the bug in the 1.4.x releases in order not to break the compatibility with previous 1.4.x releases. See http://bazaar.launchpad.net/~didier-barvaux/rohc/1.4.x/revision/349.

[Didier Barvaux (didier-barvaux)]

Won't fix the bug in the 1.3.x releases in order not to break the compatibility with previous 1.3.x releases. See http://bazaar.launchpad.net/~didier-barvaux/rohc/1.3.x/revision/203.