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

A not detected loop -> seg fault #5291

Closed
vicuna opened this issue Jun 17, 2011 · 7 comments
Closed

A not detected loop -> seg fault #5291

vicuna opened this issue Jun 17, 2011 · 7 comments
Assignees
Labels

Comments

@vicuna
Copy link

vicuna commented Jun 17, 2011

Original bug ID: 5291
Reporter: gio
Assigned to: @garrigue
Status: closed (set by @garrigue on 2012-06-01T04:49:38Z)
Resolution: fixed
Priority: normal
Severity: crash
Fixed in version: 4.00.0+dev
Category: ~DO NOT USE (was: OCaml general)
Monitored by: mehdi @ygrek "Julien Signoles" @Chris00

Bug description

Try this code:

class a = let _ = new b in object end
and b = let _ = new a in object end

and you'll find your daily segfault :)

(I've used OCaml 3.12.0 and the svn trunk version)

@vicuna
Copy link
Author

vicuna commented May 31, 2012

Comment author: @alainfrisch

Even simpler:

class a = let _ = new a in object end
->
segfault

@vicuna
Copy link
Author

vicuna commented May 31, 2012

Comment author: @alainfrisch

Note: segfault is at execution time.

@vicuna
Copy link
Author

vicuna commented May 31, 2012

Comment author: @alainfrisch

Local let-binding in a class declaration are currently executed when the class declaration is evaluated, not when the object is created. I'm tempted to consider it is a design bug that:

class c = let () = print_endline "XXX" in object end

writes "XXX". With this current semantics, one should indeed restrict references to the class being defined. I.e. in

class c = let p = e in ....

the class c should not be visible in e. But I'd prefer fixing the semantics of let bindings...

@vicuna
Copy link
Author

vicuna commented Jun 1, 2012

Comment author: @garrigue

This evaluation order is intentional.
It allows you to define values in an environment where class types are available.
Example:

class c =
let r = ref [] in
object (self) method friends = !r initializer r := (self :> c) :: !r end

If you put "let r = ref []" this definition goes through, but something strange
happens to your types...

If you want side-effects at object creation time, then your class should
take an argument, or should put them into a field.

@vicuna
Copy link
Author

vicuna commented Jun 1, 2012

Comment author: @alainfrisch

If you want side-effects at object creation time, then your class should
take an argument, or should put them into a field.

.. or an initializer

So, we want the class to be available as a type, but not as a "value", i.e. we should disallow "new c" and "inherit c" in the body of let-binding, right?

@vicuna
Copy link
Author

vicuna commented Jun 1, 2012

Comment author: @garrigue

Yes, I'm working on it now.
Seems I broke this with my changes in ocaml 3.08...

@vicuna
Copy link
Author

vicuna commented Jun 1, 2012

Comment author: @garrigue

Fixed in trunk and 4.00, inside transclass.ml, revisions 12531 and 12532

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants