Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006108OCaml~DO NOT USE (was: OCaml general)public2013-07-30 21:002017-02-16 15:18
Assigned To 
Platformx86_64OSLinuxOS VersionUbuntu 12.10
Product Version4.00.1 
Target Version4.03.0+dev / +beta1Fixed in Version4.03.0+dev / +beta1 
Summary0006108: Crash toplevel by using compiler-libs
DescriptionI load compiler-libs into toplevel using topfind:

# #require "compiler-libs.toplevel";;
/home/mike/.opam/4.00.1/lib/ocaml/threads: added to search path
/home/mike/.opam/4.00.1/lib/ocaml/compiler-libs: added to search path
/home/mike/.opam/4.00.1/lib/ocaml/compiler-libs/ocamlcommon.cma: loaded
/home/mike/.opam/4.00.1/lib/ocaml/compiler-libs/ocamlbytecomp.cma: loaded
/home/mike/.opam/4.00.1/lib/ocaml/compiler-libs/ocamltoplevel.cma: loaded

I can then parse a string:

# Parse.implementation (Lexing.from_string "1 :: []") ;;

However, if I try to make a function out of this...

# let parse_string s = s |> Lexing.from_string |> Parse.implementation ;;
>> Fatal error: parse_string unbound at toplevel
Fatal error: exception Misc.Fatal_error
Steps To ReproduceSee description
Additional InformationI can repro this using utop, and ocaml toplevel, with and without topfind.
TagsNo tags attached.
Attached Files

- Relationships
duplicate of 0006802closed unix and nums can not be Dynlinked together (Assert_failure in bytecomp/ 

-  Notes
gasche (developer)
2013-07-30 21:36

You don't need compiler-libs.toplevel to get a working lexer and parser from the OCaml compiler. You can use compiler-libs.common, which doesn't link the weird stuff from *.toplevel that provokes the failure here.

(I don't really know what happens, but I suppose the toplevel implementation is not re-entrant, and linking some modules from compiler-libs.toplevel affects the global state of the current toplevel. This is not documented nor supported, and I don't really know why you would want to do that.)
doligez (administrator)
2013-08-02 16:29

The toplevel implementation is definitely not re-entrant.
meyer (developer)
2013-08-03 00:37

This definitely needs to be in manual, I might prepare a patch for it myself.

I think it's not well known yet how to use compilelibs, usually it's easier to document tools, howver the great premise of compilerlibs, is that they will make such tasks easier. If it comes additionaly with examples, (for -ppx rewriter for instance) then it's great.
erwan (reporter)
2015-02-24 16:54
edited on: 2015-02-24 16:55

Can this bug impact the behavior of ocamlmktop? I have a segv too, and I'd like to know if it can be due to the same origin.

doligez (administrator)
2015-02-24 22:26

Do you mean ocamlmktop itself is segfaulting, or the generated toplevel? I don't think the problem described here can happen to a statically-linked program.
erwan (reporter)
2015-02-25 09:52

In the generated toplevel.

Unfortunately, it's difficult to provide a small example that exhibits the problem as my program is quite big, and the segv occurs seldomly. I should try to load my libs from a standard toplevel to see if segv still occurs.
erwan (reporter)
2015-03-02 10:04

Ok, i've tried as I said to load my libs from a basic toplevel, and now I got an assert failure in bytecomp/ line 110.
erwan (reporter)
2015-03-02 11:00

I was able to reproduce that dll assert pb as follows (it is so
simple that I hope I haven't missed something evident):

let be an empty file.

$ ocamlc -a -o empty.cma nums.cma

$ ocaml

#use "topfind";;
#require "dynlink";;
#require "unix";; (* works without this #require *)

let _ =
  Dynlink.allow_unsafe_modules true; (* nums requires this *)
  Dynlink.loadfile "empty.cma"

ps : I am using ocaml 4.02.1+PIC on a amd64 running debian
i may should report that in a separate issue ?
erwan (reporter)
2015-03-02 13:59

Even simpler (sorry for the bombing):

#use "topfind";;
#require "dynlink";;
#require "unix";; (* works without this #require *)
Dynlink.allow_unsafe_modules true;; (* nums requires this *)
Dynlink.loadfile "./.opam/4.02.1+PIC/lib/ocaml/nums.cma";;

tried also on 4.00.0, and 3.12.0 + on 32 arch
erwan (reporter)
2015-03-03 16:18

I've reported that as a separate issue there : [^]
xleroy (administrator)
2015-12-05 11:05

Well, the toplevel loop and the Dynlink library (or: two copies of the toplevel, which is what you get after loading compiler-libs.toplevel) both manipulate the (shared) table of globals of the bytecode interpreter, but in an unsynchronized manner. Hence, they overwrite each other's additions to the table of globals, leading to the crashes observed.

Is there a really compelling use case for Dynlink under the toplevel? If not, I'm tempted to just check !Sys.interactive = false within Dynlink, and fail with an explanation otherwise. If the check is put into Symtable rather than Dynlink, it would also trigger if compiler-libs.toplevel is loaded inside the toplevel.
erwan (reporter)
2015-12-05 15:09

I'm not the initial reporter of this one, but since I've been bitten too I may answer: indeed I've realized recently I don't really need Dynlink.

The check+the explanation you propose seems like the rigth thing to do.
xleroy (administrator)
2015-12-06 13:01

Commit [trunk 8e6606d] causes ocamltoplevel.cma to fail cleanly if loaded from the toplevel loop.

- Issue History
Date Modified Username Field Change
2013-07-30 21:00 mcclurmc New Issue
2013-07-30 21:36 gasche Note Added: 0010023
2013-08-02 16:29 doligez Note Added: 0010081
2013-08-02 16:29 doligez Status new => confirmed
2013-08-02 16:29 doligez Target Version => 4.01.1+dev
2013-08-03 00:37 meyer Note Added: 0010085
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-07-24 22:54 doligez Target Version 4.02.0+dev => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-24 00:04 doligez Target Version undecided => 4.02.2+dev / +rc1
2015-02-24 16:54 erwan Note Added: 0013332
2015-02-24 16:55 erwan Note Edited: 0013332 View Revisions
2015-02-24 22:26 doligez Note Added: 0013337
2015-02-24 22:26 doligez Target Version 4.02.2+dev / +rc1 => 4.02.3+dev
2015-02-25 09:52 erwan Note Added: 0013344
2015-03-02 10:04 erwan Note Added: 0013366
2015-03-02 11:00 erwan Note Added: 0013367
2015-03-02 13:59 erwan Note Added: 0013368
2015-03-03 16:18 erwan Note Added: 0013371
2015-07-10 19:06 doligez Target Version 4.02.3+dev => 4.03.0+dev / +beta1
2015-12-05 10:58 xleroy Relationship added duplicate of 0006802
2015-12-05 11:05 xleroy Note Added: 0015044
2015-12-05 15:09 erwan Note Added: 0015049
2015-12-06 13:01 xleroy Note Added: 0015052
2015-12-06 13:01 xleroy Status confirmed => resolved
2015-12-06 13:01 xleroy Resolution open => fixed
2015-12-06 13:01 xleroy Fixed in Version => 4.03.0+dev / +beta1
2017-02-16 15:18 xleroy Status resolved => closed
2017-02-23 16:36 doligez Category OCaml general => -OCaml general
2017-03-03 17:55 doligez Category -OCaml general => -(deprecated) general
2017-03-03 18:01 doligez Category -(deprecated) general => ~deprecated (was: OCaml general)
2017-03-06 17:04 doligez Category ~deprecated (was: OCaml general) => ~DO NOT USE (was: OCaml general)

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker