Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007552OCamlmiddle end (typedtree to clambda)public2017-06-04 20:142017-09-30 18:06
Assigned To 
PlatformOSOS Version
Product Version4.04.1 
Target VersionFixed in Version4.06.0 +dev/beta1/beta2/rc1 
Summary0007552: unsafely assumes all modules called Bigarray are the same
DescriptionThe following program will segfault:

  module Alias = struct module Bigarray = Bigarray end

  module Bigarray : sig

    type int_elt

    val x : (float, int_elt, Bigarray.c_layout) Bigarray.Array1.t

  end = struct

    type int_elt = Bigarray.float32_elt

    let x = Bigarray.Array1.create Bigarray.Float32 Bigarray.C_layout 2


  let x = Bigarray.x

  open Alias

  let f = x.{0}

  let () = Printf.printf "%f\n%!" f

The issue is that assumes that the [int_elt] type from the [Bigarray] submodule is the same as the normal [Bigarray.int_elt] and so incorrectly optimises the array access.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
gasche (administrator)
2017-06-04 20:39

This comes from bytecomp/

  let bigarray_decode_type env ty tbl dfl =
    match scrape env ty with
    | Tconstr(Pdot(Pident mod_id, type_name, _), [], _)
      when mod_id = "Bigarray" ->
        begin try List.assoc type_name tbl with Not_found -> dfl end
    | _ ->

In trunk (as opposed to 4.05) "CamlinternalBigarray" is used instead, but the test is still purely syntactic so the same trick would work.
gasche (administrator)
2017-06-04 21:00

I don't know how to fix this without adding the kind types to typing/Predef, which (if I understand correctly) are the only ones that the compiler can reason about using absolute (non-shadowable) names.
frisch (developer)
2017-06-08 10:47

This is perhaps naive, but couldn't we check [ mod_id]? It would still not protect against shadowing the global bigarray.cmi (which requires linking without the stdlib), but that would reduce the problem quite a bit.
lpw25 (developer)
2017-06-08 10:57

I think Gabriel's suggestion is the correct solution: the compiler should really only be reasoning about abstract types it defined. I agree that Alain's suggestion would make it less of a problem, and we should probably do that in the short term if no one has time to do the right thing at the moment.
frisch (developer)
2017-06-08 11:21

The compiler also does name-based lookups on CamlinternalOO and CamlinternalMod during code generation. Linking against a "non-standard" stdlib is already unsafe for this reason, I believe.
xleroy (administrator)
2017-09-30 18:06

In 4.06 and up the example works fine because the crucial type definitions are now in CamlinternalBigarray. That name is enough protection against accidental shadowing, in my opinion. Malicious users can still shadown the various Camlinternal* modules with their own concotions, but there are much easier ways to cause an OCaml program to segfault.

As to "the right thing" being to predefine more things within the compiler,I don't think it's sustainable. It might work here because only types are involved but would not work for the other Camlinternal* modules that also define functions and values. I'd be more interested in lightweight ways to "bless" a module as being the standard library module the compiler expects.

- Issue History
Date Modified Username Field Change
2017-06-04 20:14 lpw25 New Issue
2017-06-04 20:39 gasche Note Added: 0017840
2017-06-04 21:00 gasche Note Added: 0017841
2017-06-08 10:47 frisch Note Added: 0017851
2017-06-08 10:57 lpw25 Note Added: 0017853
2017-06-08 11:21 frisch Note Added: 0017854
2017-09-30 18:06 xleroy Note Added: 0018423
2017-09-30 18:06 xleroy Status new => resolved
2017-09-30 18:06 xleroy Resolution open => fixed
2017-09-30 18:06 xleroy Fixed in Version => 4.06.0 +dev/beta1/beta2/rc1

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker