|Anonymous | Login | Signup for a new account||2015-10-10 11:00 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005276||OCaml||OCaml general||public||2011-05-23 15:12||2012-09-25 20:06|
|Target Version||Fixed in Version||3.12.1+dev|
|Summary||0005276: bug in bytecode packing algorithm|
|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).|
|Tags||No tags attached.|
|Attached Files|| bug-pack-bytecode.tar.gz [^] (468 bytes) 2011-05-23 15:12|
0001-Fixed-bug-in-bytecode-packing-algorithm.patch [^] (4,231 bytes) 2011-05-23 15:37 [Show Content]
edited on: 2011-05-23 15:39
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.
|2011-05-23 15:12||lefessan||New Issue|
|2011-05-23 15:12||lefessan||File Added: bug-pack-bytecode.tar.gz|
|2011-05-23 15:37||lefessan||File Added: 0001-Fixed-bug-in-bytecode-packing-algorithm.patch|
|2011-05-23 15:38||lefessan||Note Added: 0005927|
|2011-05-23 15:39||lefessan||Note Edited: 0005927|
|2011-06-01 23:41||doligez||Status||new => acknowledged|
|2011-06-10 18:07||xleroy||Note Added: 0005999|
|2011-06-10 18:07||xleroy||Status||acknowledged => feedback|
|2011-06-10 18:13||lefessan||Note Added: 0006000|
|2011-06-11 09:30||xleroy||Note Added: 0006001|
|2011-06-11 09:30||xleroy||Status||feedback => resolved|
|2011-06-11 09:30||xleroy||Resolution||open => fixed|
|2011-06-11 09:30||xleroy||Fixed in Version||=> 3.12.1+dev|
|2011-06-11 09:31||xleroy||Assigned To||=> xleroy|
|2012-09-25 20:06||xleroy||Status||resolved => closed|
|Copyright © 2000 - 2011 MantisBT Group|