You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
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).
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
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...
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: