Original bug ID: 7718
Reporter: @chambart
Status: new
Resolution: open
Priority: normal
Severity: minor
Version: 4.06.0
Category: typing
Monitored by: @yallop

Bug description

There are many kind of expressions that can't be preallocated, but are considered as having a 'Static' size by Typecore.classify_expression. For instance 'new' or 'while'.

Those cases are compiled by two let bindings, one bound to 0, the second to the real value. This should be correct only when those 0 bindings can't be reached. I didn't find any example of any value classified as static size, that can't be preallocated, but that can contain a pointer to another value from the let-rec bound variables. (without using the #7706 bug). I might have stopped looking too early.

Yet that pointer can be reached. The GC can traverse it. For instance

class a =
let () = Gc.full_major () in
object
end

let rec b =
let x = (b,b) in
let v = new a in
let y = (x, x) in
v

The critical part being compiled to:

(let
(b/1008 0
b/1008
(let
(x/1009 (alloc block-hdr(2048) b/1008 b/1008)
v/1010
(let fun/1060 (load_mut val (load_mut val "camlNew"))
(app (load_mut val fun/1060) 1a fun/1060 val))
y/1011 (alloc block-hdr(2048) x/1009 x/1009))
v/1010))

The block x/1009 contains values '0' which can't be scanned in no-naked-pointer
mode and can lead to segfaults.

In that specific case, the problem is hidden by another, but assuming that #7706
is fixed, this one remains. I just needed to let bind the new to ensure that x is
alive across the call.

One could argue that this 0 should be replaced by something that the gc can scan,
like 1. But I would argue that this should rather be rejected.

If 'new' was considered as non-static sized (which it's clearly isn't since the
value is built by a function application) this would be rejected because this
expression depends on b which is invalid at that point. And I consider that to
be the true problem here.

Also I suggest renaming 'Static' to 'Can_be_preallocated'.