bug in bytecode packing algorithm #5276
Comments
|
Comment author: @lefessan 0001-Fixed-bug-in-bytecode-packing-algorithm.patch is supposed to fix the issue (beware when applying the patch that I am working in a GIT repository where the distribution is prefixed by "inline-more", so the patch should be applied at the correct level). Note also that the bug can trigger segfaults (although my show case is purposely just displaying a bad result). |
|
Comment author: @xavierleroy Hi Fabrice, Looking at the fix, it is not clear to me why all global names containing a dot must be prefixed by the package name. Couldn't one of these dotted global names refer to something defined outside the package being built? Just curious. -X |
|
Comment author: @lefessan As far as I know, globals outside the current modules cannot contain dots, since the dotted notation X.Y is translated into a field access into the global X. Of course, it is possible that somebody used module identifiers with dots as a trick somewhere else in the compiler, but I am not aware of it. Another solution could be to force the use of -for-pack in bytecode, and directly use the final name everywhere from the beginning... |
|
Comment author: @xavierleroy You're right, "dotted" global names can only appear as temporaries when initializing a packed module. So, if ocamlc -pack sees such a global, it must come from one of the units being packed. Applied the patch (with a simplification: String.contains instead of String.index) in 3.12 bugfix branch. Will go in 3.12.1. |
Original bug ID: 5276
Reporter: @lefessan
Assigned to: @xavierleroy
Status: closed (set by @xavierleroy on 2012-09-25T18:06:17Z)
Resolution: fixed
Priority: high
Severity: major
Platform: all
OS: all
OS Version: all
Version: 3.12.0
Fixed in version: 3.12.1+dev
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @lefessan "Julien Signoles"
Bug description
The algorithm used to pack bytecode units does not work correctly with hierarchical packing. It prefixes modules with the name of their package, but it does not prefix sub-modules, i.e. modules that have already been packed.
The problem arises when a package contains a package with the same name, in which case it is not possible to distinguish between the package modules and the sub-package modules.
Steps to reproduce
See the attached archive.
1- I create a first package a/a/a.cmo containing a module X (which becomes A.X)
2- I then create a second package a/b.cmo containing the module A (X is still A.X, should have become B.A.X)
3- A module C has a reference to X.x, and prints it
4- I create a final package a.cmo, containing a/x.cmo, a/b.cmo and a/c.cmo
5- When I run that module, C displays the value of X.x found in B.A.X (2) instead of the one in A.X (1)
Additional information
To fix it, the algorithm should not only prefix the packaged modules, but also the modules packaged within those modules (it could check that they contain a dot, and immediatly prefix them).
File attachments
The text was updated successfully, but these errors were encountered: