Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000061OCamlOCaml generalpublic2000-03-18 20:392000-03-30 19:41
Reporteradministrator 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000061: linker bug?
DescriptionFull_Name: Markus Mottl
Version: 2.99+12
OS: Digital Unix 4.0e / Alpha
Submission from: alford.dai.ed.ac.uk (129.215.25.74)


Hello,

there seems to be a strange bug with the linker, which effects
at least ocamlmktop and ocamlopt.opt (seems to be ok with ocamlc.opt
- I have not tried the byte code versions):

The following program (makes use of my PCRE-lib - works with
OCaml 2.99):

  open Unix;;
  let f () = Pcre.version

behaves strangely when I try to link it (native code) or when I want
to have it interpreted (independent of the specific PCRE-function).

When I link it with ocamlopt.opt, I get the following:

  ocamlopt.opt -I {longlibpath} -ccopt -L {longlibpath} -cclib -lpcre pcre.cmxa
-o bla bla.cmx
  ld:
  Can't open: pcre_intf.o (No such file or directory)

I have not linked in the unix library here (line even longer),
but the result is the same and also then when I leave away
the line containing "open Unix". But...

When I try to interpret it with "mocaml", which I have created
with "ocamlmktop" (also always worked), I get the following
message:

  Uncaught exception: Invalid_argument("String.get")

However, if I *delete* the line containing "open Unix" and
interpret the file with the same toplevel, it works! - It
also runs fine, when the program really does something
interesting with the PCRE-library (as long as I do not
reference the Unix-library somehow)...

Furthermore, when I compile the file with "ocamlc.opt",
the resulting executable works either way (with or without
the "open Unix"-line). Only when I really use a function
from "Unix" do I have to link in the unix-library, which
also works as expected.

So in short: everything (as far as I could see) works fine
with "ocamlc.opt" - but I get an unexpected link error from
ocamlopt.opt and "ocamlmktop" generates a toplevel that
does not behave correctly.

Here, there is another interesting aspect to note:

I normally link in many libraries into "mocaml". When I
leave some of them away, it may be that the above example
immediately works, behaves as before, or issues another
error message like:

  File "bla.ml", line 2, characters 11-23:
  Unbound value Pcre.version

I have not found out, how the linkage order really
influences behaviour: this seems pretty non-deterministic.
It also seems that the strange behaviour with the toplevel
only appears when I use "open Unix" - not when I leave it
away or open another library (e.g. Str).

That's all I can say so far. I have built my PCRE-library
twice and made sure that its files are where they normally
reside, but the problem did not disappear - maybe
I have overlooked something trivial?

In case you need it for finding the bug (or otherwise ;-),
here the link to my pcre-distribution:

  http://miss.wu-wien.ac.at/~mottl/ocaml_sources/intro.html [^]

and take "pcre_ocaml.tar.gz"...

Ah, before I forget: I had to modify a Makefile during the
build process of ocaml (should be independent of upper problem):
the labltk-library (otherlibs/labltk/support) linked with the
option "-label". Since I luckily read the mailing list, I knew
that this should mean "-modern" and changed it appropriately
(the change has obviously not yet made it into the distribution)...

Best regards,
Markus Mottl

TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0000332)
administrator (administrator)
2000-03-29 18:53

> there seems to be a strange bug with the linker, which effects
> at least ocamlmktop and ocamlopt.opt (seems to be ok with ocamlc.opt
> - I have not tried the byte code versions):
> The following program (makes use of my PCRE-lib - works with
> OCaml 2.99):
> open Unix;;
> let f () = Pcre.version
> behaves strangely when I try to link it (native code) or when I want
> to have it interpreted (independent of the specific PCRE-function).
> When I link it with ocamlopt.opt, I get the following:
> ocamlopt.opt -I {longlibpath} -ccopt -L {longlibpath} -cclib -lpcre pcre.cmxa
> -o bla bla.cmx
> ld:
> Can't open: pcre_intf.o (No such file or directory)

I can explain this one. The behavior of ocamlc -a and ocamlopt -a
changed recently, so as to "remember" the -custom flag, as well as C
libraries and options specified on the command line, in the library
file created. Those flags are then automatically added when linking
with that library file. In other terms, you can now do

        ocamlc -a -o mylib.cma -custom -cclib -lmylib mylib.cmo
and later
        ocamlc mylib.cma <other .cmo and .cma files>

instead of, as before,

        ocamlc -a -o mylib.cma mylib.cmo
and later
        ocamlc -custom mylib.cma <other .cmo and .cma files> -cclib -lmylib

This should simplify Makefiles quite a lot, as well as making the
transition to dynamic loading of C libraries easier in a future
release.

Now, your pcre.cmxa library is created with

        ocamlopt -a -I ../pcre-C pcre_intf.o -o pcre.cmxa pcre.cmx
        
Before, pcre_intf.o was simply ignored. Now, it's remembered in the
pcre.cmxa file and added at every link involving that library, which
causes the error you saw.

> When I try to interpret it with "mocaml", which I have created
> with "ocamlmktop" (also always worked), I get the following
> message:
> Uncaught exception: Invalid_argument("String.get")

I haven't been able to reproduce this behavior. How do you create mocaml?
I created it with ocamlmktop unix.cma pcre.cma ... Then,
mocaml bla.ml worked OK.

Best regards,

- Xavier Leroy

(0000333)
administrator (administrator)
2000-03-30 19:40

> Unfortunately, this problem still persists. Here more details on it - I
> managed to find an example that should more clearly demonstrate its
> weirdness:

OK, we were able to reproduce the problem and (after a couple of hours
under gdb) understand it. You've uncovered a rather subtle GC bug in the
Obj.truncate function, which the OCaml toplevel uses to shorten the
argument vector when interpreting a script. Congratulations for
(unwillingly) finding it!

However, we found an (unrelated) error in your PCRE wrappers: in
function pcre_firstchar_wrapper, you allocate a variant with argument
as follows:

      v_firstchar = alloc_small(1, 748194550);
      Field(v_firstchar, 1) = Val_int(firstchar);

which should be:

      v_firstchar = alloc_small(2, 0);
      Field(v_firstchar, 0) = Val_int(748194550);
      Field(v_firstchar, 1) = Val_int(firstchar);

I'll see with Jacques if we can provide a macro in mlvalues.h that
computes the hash value of a variant tag. If that cannot be done, I'd
recommend registering variants from Caml and extract the tags from C,
so that you don't have to hard-wire their hash values.

Yet another remark: in your first call to alloc_final, the 1 / 10
ratio seem a bit low. It's not a bug, but it means that the major GC
is going to work unnecessarily hard: you're forcing the major GC to do
a full cycle at least every 10 regexps allocated. You may consider
using a ratio of 1 / 100 or less. However, had you not forced the
major GC to work that hard, you probably wouldn't have uncovered the
GC bug...

Keep up finding those subtle bugs!

All the best,

- Xavier Leroy and Damien Doligez

(0000334)
administrator (administrator)
2000-03-30 19:41

J'ai fixe le probleme avec -label / -modern -- Damien.
Premier probleme OK (changement de semantique de ocamlopt -a) -- Xavier
Second probleme corrige 2000-03-30 -- Xavier & Damien

- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker