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

Build failure on raspberry pi: "input_value: integer too large" #5977

Closed
vicuna opened this Issue Apr 8, 2013 · 12 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link
Collaborator

vicuna commented Apr 8, 2013

Original bug ID: 5977
Reporter: gildor
Assigned to: @alainfrisch
Status: closed (set by @xavierleroy on 2015-12-11T18:18:36Z)
Resolution: fixed
Priority: normal
Severity: minor
Platform: armv6l
OS: Raspbian (aka Debian Wheezy)
OS Version: wheezy
Version: later
Category: ~DO NOT USE (was: OCaml general)
Related to: #5575 #5793 #5986
Monitored by: @dbuenzli

Bug description

When trying to build from a clean environment:

make[2]: Entering directory /home/jenkins/workspace/ocaml/label/femto/stdlib' ../boot/ocamlrun ../boot/ocamlc -strict-sequence -w +33..39 -g -warn-error A -nostdlib ./Compflags pervasives.cmi` -c pervasives.mli
Fatal error: exception Failure("input_value: integer too large")
make[2]: *** [pervasives.cmi] Error 2

Full log here:
http://deci.ovh.le-gall.net:8080/job/ocaml/label=femto/25/console

Steps to reproduce

Build from scratch on Raspbian system:
svn co
make clean || true
./configure
make world

Additional information

Feel free to contact me if you need to access the system.

File attachments

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: @alainfrisch

This problem has also been spotted on (other) 32-bit architectures. Bootstrapping the compiler (on today's trunk) on a 64-bit architecture results in bytecode executables containing 64-bit integers which cannot be read on a 32-bit machine.

This has been introduced by commit 13241 (intended to fix #5793).

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: @alainfrisch

This seems to be caused by some integer constants in stdlib/random.ml

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: @alainfrisch

See also #5575.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: @alainfrisch

I'll modify those constants to apply the "land 0x3fff..." filter to make them 32-bit friendly.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: @alainfrisch

Fixed in commit 13488 (on trunk).

Sylvain: can you check that this indeed fixes your problem as well?

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: @alainfrisch

We should find a way to avoid such problems in the future. The problem is that some hexadecimal integer constants are valid in 32-bit but result in a different integers than on 64-bit, thus making it impossible to have a proper marshaling/demarshaling round-trip between those architectures.

This is somehow similar to unprotected end-of-line in string literals, which produce different strings according to the platform. We could similarly introduce a warning in the parser to spot report such integers.

It would also be useful to introduce a new marshaling flag to prevent the marshaler from producing 64-bit integers (and maybe somehow find a way to enable this flag during bootstrap), in order to check upon marshaling that the resulting data will be readable by a 32-bit process.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: gildor

I'll check it tonight, right now my RPi jenkins slave is not up.

Although, if you want to avoid such situation, you can use my jenkins builder! I can provide you with an account and instruction to setup a svn hook that will automatically trigger build on Debian Squeeze 32/64 bits and RPi (need to setup this node as well) when you commit to trunk.

I am also planning to add Mac OS X and probably Windows (long term plan).

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: gildor

... and send a mail to the ocaml-dev list and if you really want transform the test suite into JUnit compliant test to get a nice overview of what is broken and... (feel the blank with what is need for continuous integration).

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: @alainfrisch

Are you in touch with OCamlLabs folks? My understanding is that they planned to work on continuous integration for OCaml. Let's not duplicate the effort!

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: gildor

I know they are working on something, not sure what and when it will be available. So far my understanding was that it was all about OPAM, OCaml just being the starting point. I think it is a lot more general than just OCaml...

Anyway, my proposal is just about providing a solution for today bug. It will run anyway, but with 1 day of latency (I scan the SVN of caml everyday).

Side Note: you can start with my jenkins instance and continue with OCamlLabs, half of setting up continuous integration is a matter of making your code "testable" automatically.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 9, 2013

Comment author: gildor

The compilation on the RPi now succeed on this step (but fail after due to having enough memory in camlp4).

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 10, 2013

Comment author: @alainfrisch

Thanks for the feedback. Concerning camlp4, you can disable its compilation quite simply now (./configure -no-camlp4).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.