Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ocamlopt generates segfaulting code when using [with] on recursive record with 6+ fields. #5819

vicuna opened this issue Nov 10, 2012 · 6 comments


Copy link

@vicuna vicuna commented Nov 10, 2012

Original bug ID: 5819
Reporter: jm
Assigned to: @damiendoligez
Status: closed (set by @xavierleroy on 2015-12-11T18:19:41Z)
Resolution: fixed
Priority: immediate
Severity: crash
Platform: all
OS: all
Version: 4.00.1
Target version: 4.01.0+dev
Fixed in version: 4.00.2+dev
Category: back end (clambda to assembly)
Related to: #4141
Monitored by: @hcarty

Bug description

% ocamlopt -version
% uname -m
% cat
type t =
{ self : t
; t0 : int
; t1 : int
; t2 : int
; t3 : int
; t4 : int
let rec t =
{ self = t
; t0 = 42
; t1 = 42
; t2 = 42
; t3 = 42
; t4 = 42
let () =
let rec self = { t with self=self } in
print_int self.self.t0
% ocamlopt && ./a.out
Segmentation fault

File attachments

Copy link

@vicuna vicuna commented Nov 13, 2012

Comment author: @damiendoligez

Reproduced with 4.00.2+dev1 on Mac OS X.

Copy link

@vicuna vicuna commented Nov 14, 2012

Comment author: @damiendoligez

Here is a patch. I'll get it reviewed by some back-end specialist and then I'll apply it.

Copy link

@vicuna vicuna commented Nov 16, 2012

Comment author: @alainfrisch

I'm not a back-end specialist, so I cannot really comment on the proposed patch (except that I believe Record_regular should be Types.Record_regular, etc, unless you're already on the record_disambiguation branch!). But while trying to understand the general compilation strategy for recursive bindings, I found the following lines which I don't really understand:

let rec init_blocks = function
| (id, exp, RHS_nonrec) :: rem ->
Clet (id, Cconst_int 0, init_blocks rem)

Why do we do that, instead of simply calling "init_block rem" in the RHS_nonrec case? At least, this might allow to catch earlier this kind of bugs. Or are there cases where those dummy bindings are actually needed?

Copy link

@vicuna vicuna commented Dec 4, 2012

Comment author: @damiendoligez

I have uploaded a better patch (provided by XL). I have committed it in the 4.00 branch, but not in trunk because we still need to decide whether/how to refactor this function to make it common to the byte-code and native back-ends.

Fixed in 4.00 (r 13110), but this PR stays open until we rework the code in the trunk.

I don't have an answer to frisch's question for the moment.

Copy link

@vicuna vicuna commented Jun 6, 2013

Comment author: @alainfrisch

Even if we keep this open for further cleanup/sharing, I'd suggest to ensure that the patch will be part of the next release. Unless there is something seriously wrong with it?

Copy link

@vicuna vicuna commented Jun 14, 2013

Comment author: @xavierleroy

Patch #2 was propagated to the trunk by one of Damien's big merges (commit r13699) then cloned in the 4.01 branch. So, all is as it should be. Refactoring can wait. I take the liberty of marking this PR as resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants