Tests are failing for mips64el on Debian

[Deni90]

The build of ocaml-ctypes is failing for mips64el on Debian with the following message:

=============================================================================
Error: Higher-order tests:1:test_higher_order_basic (stubs).

File "/«PKGBUILDDIR»/_build/oUnit-Higher-order tests-mipsel-sil-01#00.log", line 26, characters 1-1:
Error: Higher-order tests:1:test_higher_order_basic (stubs) (in the log).

(Program not linked with -g, cannot print stack backtrace)

not equal
------------------------------------------------------------------------------
==============================================================================
Error: Higher-order tests:0:test_higher_order_basic (foreign).

File "/«PKGBUILDDIR»/_build/oUnit-Higher-order tests-mipsel-sil-01#00.log", line 20, characters 1-1:
Error: Higher-order tests:0:test_higher_order_basic (foreign) (in the log).

(Program not linked with -g, cannot print stack backtrace)

not equal
------------------------------------------------------------------------------

full log: https://buildd.debian.org/status/fetch.php?pkg=ocaml-ctypes&arch=mips64el&ver=0.7.0-1&stamp=1470056946

Test is failing on:
assert_equal 1 (higher_order_1 min (-3) 0)

After debugging I have found the following:
higher_order_1 function from tests/clib/test_functions.c is returning 0 for callback(0, -3) == 0 + (-3)
In this test case the callback is min.
The comparison between min(0, -3) and 0 + (-3) equals 0 because callback(0, -3) is returning a positive number.
I compared min(0, -3) with zero to check is it positive or negative.

I did the same thing on mipsel and the result was negative as expected. All tests are passing.
This bug shows up only for mips64el.

Do you have any idea why is this happening?

I was able to fix this issue by modifying the function.

int higher_order_1(intfun *callback, int x, int y)
{
  int z = callback(x, y)
  return z == x + y;
}

With this workaround the package still fails on testing. It is failing on test-cstdlib (qsort and bsearch).

Any advice will be useful.

[yallop]

Thank you for the report. I'd like to track down the problem, but don't have access to a suitable machine, and using qemu is painfully slow.

[Deni90]

I compared the generated files from mips64el with files from other architectures (amd64, arm64, mipsel) and they are same. It seems to that the generated bindings and stubs are architecture independent.

ocaml-ctypes is compiled with ocamlc 4.02.3 which is about one year old.
Is it possible that the problem is in ocaml and not in ocaml-ctypes?

I have access to mips boards, so, if you have any idea I am willing to try.
I am running out of ideas.

[yallop]

Yes, the generated files are architecture-independent.

I suspect the problem lies in a wrong libffi-related assumption -- either an assumption in libffi itself, or an assumption about libffi in ctypes (most probably the latter). If I were debugging it I'd probably start with some of the following:

• compile everything with debug info (make DEBUG=true -k all tests) and run the tests with valgrind (by changing the run-% in Makefile.tests)
• instrument the relevant test code (in clib/test_functions.c) with printf calls.
• run the failing test in a debugger, set breakpoints/watchpoints in both the test code and in the ctypes code that handles callbacks (e.g. callback_handler_with_lock and other functions in src/ctypes-foreign-base/ffi_call_stubs.c)

[yallop]

@Deni90: @fdopen's patch in #456 (now merged into master) should fix this issue. Can you confirm that it's fixed for you?

[Deni90]

It is fixed. Thanks.
Until new version is released I will send a patch to Debian to fix the build for mips64el.

[yallop]

There are new releases out now (e.g. 0.10.1) with the fix.