Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004080OCamlOCaml generalpublic2006-08-08 16:152014-09-14 21:45
Reporterfrisch 
Assigned To 
PrioritynormalSeverityminorReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target Versionafter-4.02.1Fixed in Version 
Summary0004080: segfault avec ocamlopt -pack
DescriptionUn nouveau bug avec ocamlopt -pack:

buzet ~/bug $ cat sub/a.ml
let f x = x + 1

buzet ~/bug $ cat b.ml
let () = Printf.printf "%i\n" (A.A.f 2)

buzet ~/bug $ make opt
ocamlopt -c -for-pack A sub/a.ml
ocamlopt -pack -o a.cmx -I sub/ sub/a.cmx
ocamlopt -c b.ml
ocamlopt -o b a.cmx b.cmx

buzet ~/bug $ ./b
zsh: segmentation fault ./b


Le lambda-code produit par -pack crée une structure récursive, parce que les
noms globaux A et A ne sont pas distingués. Le premier champ du module packé A, qui devrait pointer sur le module A contenant une fonction, se retrouve en fait à pointer sur le module packé A lui-même.


Note: il y a dans la distribution une instance d'un -pack avec comme nom de module inclus le nom du module crée (c'est Camlp4Top); ça ne pose apparemment pas de problème parce que c'est du bytecode.
Tagspatch
Attached Files? file icon patch_pack [^] (19,359 bytes) 2006-08-09 15:41 [Show Content]

- Relationships
has duplicate 0005333closedprotz ocamlopt -pack leads to segfaulting code when packed and packing modules have the same name. 
related to 0006537acknowledged Stack overflow of ocamlopt while linking a pack with name clashes 

-  Notes
(0003729)
frisch (developer)
2006-08-08 18:03

Avec l'aide de Nicolas, je propose un correctif en deux coups, qui corrige aussi le problème que je signalais dans le bug 3827 (il faut donner les -I pour retouver les .cmx au moment du -pack, alors qu'on donne déjà leur chemin complet).

Premier coup:
- changer targetname en "#CURRENT#" dans Ampackager.make_package_object;
- changer modulename en "#CURRENT#" dans l'appel à Translmod.transl_store_implementation, dans Optcompile.implementation;
- changer current_unit.ui_name en "#CURRENT#" dans Compilenv.get_global_info.

Ceci a pour effet de faire que le lambda-code généré considère que l'unité courante a le nom #CURRENT#, et c'est au moment de faire le lien entre nom global et unit_infos (en particulier ui_symbol) que l'on détecte ce nom spécial.

Le problème est que dans l'exemple qui j'ai donné pour illustrer le bug, après une première fois où tout se passe bien, il y a un nouveau fichier a.cmx qui apparaît. Donc au moment de compiler de nouveau le lambda-code pour le -pack, Compilenv va chercher le a.cmx dans !load_path. On a beau lui donner le chemin complet pour sub/a.cmx et mettre -I sub, il va quand même chercher a.cmx dans le répertoire courant d'abord. À mon avis c'est dommage (cf bug 3827): si on donne le chemin pour les .cmx explicitement, il n'y a pas de raison d'aller les chercher ailleurs.

Pour corriger ça, je propose d'ajouter dans Compilenv une table qui garde la trace des .cmx déjà chargés:

    let cmx_filenames = Hashtbl.create 17

On rajoute alors dans read_unit_info la ligne:

    Hashtbl.add cmx_filenames ui.ui_name filename;

Et on remplace dans get_global_info l'appel à find_in_path_uncap par:

    try Hashtbl.find cmx_filenames modname
    with Not_found -> find_in_path_uncap !load_path (modname ^ ".cmx")
(0003731)
frisch (developer)
2006-08-09 15:45

Autre solution (implementée dans le patch en pièce jointe): faire la traduction identificateur global -> symbole assembleur à la génération du lambda-code, et non plus à la génération du ulambda-code. Le patch traite aussi le bug 3827; de plus il ajoute un warning lorsqu'ocamlopt ne trouve pas de .cmx pour un module référencé (car ça casse si ce module a été compilé avec -for-pack, et de toute manière, ça empêche les optimisations inter-modules).

C'est un petit peu plus intrusif que l'autre solution (mais peut-être plus robuste).
(0005641)
doligez (administrator)
2010-08-20 12:22

Ce bug a ete re-signale sur la Caml List le 2010-05-23 par Goswin von Brederlow. Il existe encore en 3.12.0.
(0009674)
doligez (administrator)
2013-07-02 16:32

still present in 4.01+dev

- Issue History
Date Modified Username Field Change
2006-08-08 16:15 frisch New Issue
2006-08-08 18:03 frisch Note Added: 0003729
2006-08-09 15:41 frisch File Added: patch_pack
2006-08-09 15:45 frisch Note Added: 0003731
2006-08-29 16:40 doligez Severity crash => minor
2006-08-29 16:40 doligez Status new => acknowledged
2010-08-20 12:22 doligez Note Added: 0005641
2011-12-21 15:01 protz Relationship added has duplicate 0005333
2012-07-11 16:26 doligez Target Version => 4.01.0+dev
2012-07-31 13:37 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-14 23:30 doligez Target Version 4.00.1+dev => 4.00.2+dev
2013-07-02 16:32 doligez Note Added: 0009674
2013-07-02 16:32 doligez Target Version 4.00.2+dev => 4.01.0+dev
2013-07-24 12:07 doligez Target Version 4.01.0+dev => 4.01.1+dev
2013-09-03 17:21 doligez Tag Attached: patch
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-08-18 17:57 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-04 00:35 doligez Relationship added related to 0006537
2014-09-14 21:45 doligez Target Version undecided => after-4.02.1


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker