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

testsuite/tests/lib-threads/socketsbuf.ml fails sometimes #7366

Closed
vicuna opened this issue Sep 22, 2016 · 1 comment
Closed

testsuite/tests/lib-threads/socketsbuf.ml fails sometimes #7366

vicuna opened this issue Sep 22, 2016 · 1 comment

Comments

@vicuna
Copy link

vicuna commented Sep 22, 2016

Original bug ID: 7366
Reporter: pmetras
Status: resolved (set by @xavierleroy on 2017-02-16T08:53:43Z)
Resolution: not a bug
Priority: normal
Severity: minor
Platform: i386
OS: Minix3
OS Version: 3.4.0
Category: otherlibs
Monitored by: @gasche

Bug description

The testsuite fails for some tests in lib-threads but I was unable to find the reason. This is related to the generated byte code. For instance, the test testsuite/tests/lib-threads/socketsbuf.ml fails, when executed with the just generated from sources OCaml version. But it passes if the same OCaml version is installed in /usr/local! The same bug occurs for testsuite/tests/lib-threads/fileio.ml.

$ ../byterun/ocamlrun -b -I ../stdlib -I ../otherlibs/threads -I ../otherlibs/unix ./program
Thread 2 killed on uncaught exception Sys_blocked_io
Raised by primitive operation at file "pervasives.ml", line 415, characters 4-749
Called from file "socketsbuf.ml", line 26, characters 10-23
Called from file "thread.ml", line 131, characters 8-14
Fatal error: exception Sys_blocked_io
Raised by primitive operation at file "pervasives.ml", line 415, characters 4-749
Called from file "socketsbuf.ml", line 26, characters 10-23
Called from file "socketsbuf.ml", line 46, characters 2-30

For people interested in system debugging, the exception occurs in byterun/unix.c, in function caml_read_fd.

The problem is in the generated code and the location of stdlib.

Steps to reproduce

To reproduce the bug it:

  1. Compile the full OCaml distribution
  2. Run the test socketsbuf.ml from the testsuite: it fails...
  3. Compile it with "../byterun/ocamlrun ../ocamlc -g -I ../stdlib -w a -vmthread -I ../otherlibs/threads -I ../otherlibs/unix unix.cma threads.cma tests/lib-threads/socketsbuf.ml -o program". The testsuite version uses "-nostdlib -I ../testsuite/lib" parameters that does not affect the result and that we removed.
  4. Run it with "../byterun/ocamlrun -b -I ../stdlib -I ../otherlibs/threads -I ../otherlibs/unix ./program". It fails again...
  5. Become root and install the Ocaml distribution
  6. Run again the program, but now you don't need all the includes as you use the system OCaml: "./program". It still fails...
  7. Compile it with the system ocaml compiler: "ocamlc -g -w a -vmthread unix.cma threads.cma socketsbuf.ml -o program"
  8. Run it: "./program". IT WORKS!
  9. Delete the system OCaml installation in /usr/local.
  10. Check you've done the job correctly: "./program" should print "./program: not found".
  11. Run it again with "../byterun/ocamlrun -b -I ../stdlib -I ../otherlibs/threads -I ../otherlibs/unix ./program". IT STILL WORKS NOW!!!

You can see that the good and the bad programs have different sizes but I haven't seen an option to extract the generated bytecode and find the differences.

When the OCaml distribution is installed on the system, the shortest way to see the bug is:

  1. Program generated by "ocamlc -g -w a -vmthread -I ../stdlib/ unix.cma threads.cma socketsbuf.ml -o program" fails
  2. Program generated by "ocamlc -g -w a -vmthread unix.cma threads.cma socketsbuf.ml -o program" executes successfully

Additional information

Minix3 does not have system threads and I've adapted the testsuite to use VM threads instead.

@vicuna
Copy link
Author

vicuna commented Feb 16, 2017

Comment author: @xavierleroy

Thanks for the repro instructions, which enabled me to reproduce the exception on a Linux system. This is actually normal behavior, although it took me a while to understand why.

VMthreads come with their own version of the stdlib, which in particular changes I/O functions to use nonblocking mode. By compiling with "-vmthreads", the correct, VMthread-aware version of the stdlib is selected. By compiling with "-vmthreads -I ../../../stdlib", the normal, non-VMthread-aware version of the stdlib is selected.

For this reason and others, tests/lib-threads should not be used with VMthreads, because they have not been designed to.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant