Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test suite doesn't pass using latest compiler #7227

Closed
vicuna opened this issue Apr 15, 2016 · 20 comments
Closed

Test suite doesn't pass using latest compiler #7227

vicuna opened this issue Apr 15, 2016 · 20 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Apr 15, 2016

Original bug ID: 7227
Reporter: RichN
Status: resolved (set by @xavierleroy on 2017-02-16T08:15:36Z)
Resolution: unable to duplicate
Priority: normal
Severity: minor
Platform: ARMv6-hf
OS: NetBSD
OS Version: 7.0
Category: ~DO NOT USE (was: OCaml general)
Tags: arm

Bug description

Back in November, I contributed patches to get the compiler to build and work on a RaspberryPi running NetBSD 7.0. It passed all the tests. Recently, I built the compiler again, but this time specifying "-flambda". One test fails:

Running tests from 'tests/float-unboxing' ...
... testing with ocamlc ocamlopt Fatal error: exception Failure("float and int64 record; alloc = 56000")
=> failed

I'm building the sources from commit 7924ec5 (from GitHub.) Building the compiler suite on the RaspberryPi takes a long time, so if anyone has an educated guess as to where to try to rebuild (using a git commit hash) I won't mind rebuilding from that point and reporting the results.

Steps to reproduce

Run the tests after building the compiler suite.

@vicuna
Copy link
Author

vicuna commented Apr 15, 2016

Comment author: @gasche

Last February, the compiler development was split into two branch:

  • 4.03, which is being stabilized in preparation for the upcoming 4.03.0 release
  • trunk, which contains less stable changes that will not be part of the upcoming release

You seem to be using the trunk branch. I would highly recommend trying from the 4.03 branch, which is supposed to be stable and is under testing in preparation for the release. In particular, testsuite failures under 4.03 are even more interesting to report, as they are sign of things that should be fixed quickly before the release (planned in the following weeks).

A testsuite failure on trunk is of course already helpful and will be investigated as well. Thanks!

@vicuna
Copy link
Author

vicuna commented Apr 15, 2016

Comment author: @gasche

It was not clear in my previous message, but I think that it is likely that the cause for the regression is a change to the unboxing strategy present in trunk but not in 4.03. (There were also important compiler changes when flambda was merged, so there may still be regressions in 4.03 compared to your tests in November, before flambda.)

@vicuna
Copy link
Author

vicuna commented Apr 15, 2016

Comment author: RichN

I'll switch to the 4.03 branch and report the results. Thanks!

@vicuna
Copy link
Author

vicuna commented Apr 15, 2016

Comment author: @alainfrisch

Well, the part of the test which is failing has been added to test the new unboxing strategy (post 4.03), and it is flambda-specific (it's a case where flambda allows the unboxer to be more precise). I'm pretty sure this does not happen 4.03.

@vicuna
Copy link
Author

vicuna commented Apr 15, 2016

Comment author: RichN

Okay. I'm currently testing 'classic' on the RPi. When it completes, I'll rebuild with 'flambda' and test again. I'll post both results. Thanks, everyone, for the help and information.

@vicuna
Copy link
Author

vicuna commented Apr 15, 2016

Comment author: @chambart

The problem comes from int64 not being unboxed on 32bit systems. I will fix the test by simply replacing int64 by int32.

@vicuna
Copy link
Author

vicuna commented Apr 15, 2016

Comment author: @chambart

I pushed a patch to fix the test: afdbd62

The real fix would be to allow unboxing of int64 on 32bit.

@vicuna
Copy link
Author

vicuna commented Apr 15, 2016

Comment author: @gasche

Just to clarify, you are saying that RichN should be able to go back to compiling trunk if they want to.

@vicuna
Copy link
Author

vicuna commented Apr 16, 2016

Comment author: RichN

4.03 branch. Classic tested fine. Tests using flambda:

Summary:
591 tests passed
7 tests skipped
1 tests failed
0 unexpected errors
599 tests considered

List of failed tests:
tests/lib-scanf-2

List of skipped tests:
tests/lib-bigarray-2
tests/unwind
tests/lib-dynlink-csharp
tests/runtime-errors/stackoverflow.native

Something failed. Exiting with error status.

@vicuna
Copy link
Author

vicuna commented Apr 16, 2016

Comment author: RichN

The flambda build had one failure in the tests.

@vicuna
Copy link
Author

vicuna commented Apr 18, 2016

Comment author: RichN

NetBSD/arm failed the "tests/lib-scanf-2" test under flambda.

Building and testing on NetBSD/i386 (which is the 32-bit Intel port) completes successfully.

@vicuna
Copy link
Author

vicuna commented Apr 18, 2016

Comment author: @gasche

It seems to me that there are still issues, so I'm reopening the bug and marking it for 4.03+dev to make sure it doesn't escape the release QA. chambart, do you have an idea of what is going on with the scanf test?

@vicuna
Copy link
Author

vicuna commented Apr 18, 2016

Comment author: RichN

Unfortunately the only output (on NetBSD/arm) is:

Running tests from 'tests/lib-scanf-2' ...
... testing with ocamlc ocamlopt => failed

@vicuna
Copy link
Author

vicuna commented Apr 18, 2016

Comment author: @gasche

From the root repository of the OCaml project, you could go to

testsuite/tests/lib-scanf-2

after the test has run, this file should contain files

result.byte
result.native
reference

The latter is the reference result of the test. Could you report the content of the two result files?

Also, running

make

in this directory (after maybe running "make lib" in testsuite/) may produce more informative failure messages.

@vicuna
Copy link
Author

vicuna commented Apr 18, 2016

Comment author: RichN

This may be a subtle shell issue on NetBSD (although my x86 system built fine.) reference, result.byte, and result.native all contain:

Ping-pong Ping-pong Ping-pong Ping-pong Ping-pong Ping-pong Ping-pong Ping-pong!
Test OK.

And, indeed, diff reports they are identical. I ran the tests like you requested:

rpi$ cd testsuite/tests/lib-scanf-2/
rpi$ gmake
gmake[1]: Entering directory '/home/rich/ocaml/testsuite/tests/lib-scanf-2'
gmake[2]: Entering directory '/home/rich/ocaml/testsuite/tests/lib-scanf-2'
gmake[2]: 'tscanf2_io.cmx' is up to date.
gmake[2]: Leaving directory '/home/rich/ocaml/testsuite/tests/lib-scanf-2'
gmake[1]: Leaving directory '/home/rich/ocaml/testsuite/tests/lib-scanf-2'
gmake[1]: Entering directory '/home/rich/ocaml/testsuite/tests/lib-scanf-2'
... testing with ocamlc ocamlopt => passed
gmake[1]: Leaving directory '/home/rich/ocaml/testsuite/tests/lib-scanf-2'

I re-ran 'make tests' from the project's top directory and it succeeded! Yet three time now, after building the compiler and running the tests, it fails in the scanf-2 test. I recommend closing this issue out since it seems to be something subtle on NetBSD 7.0/arm using GNUMake. The affected audience is me, so I don't want to hold things up.

I'll submit a PR if I can determine why that system has problems the first time it runs the tests. Thank you for your help and suggestions.

@vicuna
Copy link
Author

vicuna commented Apr 19, 2016

Comment author: @damiendoligez

Let's keep the PR open, but I'm setting the target to 4.04 to avoid holding up the 4.03.0 release.

@vicuna
Copy link
Author

vicuna commented Sep 8, 2016

Comment author: @mshinwell

RichN: I'm going to defer this to the 4.05 release, but if you can come up with a patch quickly, we could fix it in 4.04 too.

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @mshinwell

RichN: have you had any time to investigate this further (e.g. with the 4.04 release)?

@vicuna
Copy link
Author

vicuna commented Dec 13, 2016

Comment author: RichN

During the 4.04 development phase, I took the time to install 'git' on my RPi and cloned OCaml on it (up to then, I was 'rsync'ing the source from my x86 box to the RPi.) When I build it from the locally cloned repo, I can't reproduce the problem. I would have thought that 'git clone' and 'rsync' would end up with the same source tree but, apparently, something was subtly different.

Earlier this month, my RPi's SD card died and I haven't had time to restore the machine, so I can't run another test.

I think we should just close this issue since it was only seen in this one, unique configuration.

@vicuna
Copy link
Author

vicuna commented Feb 16, 2017

Comment author: @xavierleroy

Suspending as suggested by reporter.

@vicuna vicuna closed this as completed Feb 16, 2017
@vicuna vicuna added the bug label Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant