You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 1497 Reporter: administrator Status: closed Resolution: fixed Priority: normal Severity: minor Category: -for Caml light use https://github.com/camllight/camllight/issues
I am a newcomer to the Caml light system. I found a weird example
that went through the typing process of the system but got stuck
by a segmentation fault error in running, as follows:
$ cat nil.ml
type T = MyC of T * T * T * T * T * T
| YourC ;;
let rec x =
let (MyC (z1,z2,z3,z4,z5,z))=x in
MyC(x,z,z1,z2,z3,z4);;
$ camllight
Caml Light version 0.75
#load "nil.ml";;
Type T defined.
File "nil.ml", line 6-7, characters 2-60:
.let (MyC (z1,z2,z3,z4,z5,z))=x in
MyC(x,z,z1,z2,z3,z4)..
Warning: this matching is not exhaustive.
Segmentation fault
In order to examine this behavior further, I looked into the
ZINC bytecode for the caml code. I am not sure but the ZINC
bytecode seems to be strange.
DUMMY allocates one empty block with a tag 0.
SWITCH interprets this empty block as a block with the
constructor MyC, since the caml compiler happens to assign
0 to the tag of the constructor. Obviously, there is no
field yet in the block allocated by DUMMY.
GETFIELD(n), however, tries to access the non-existing fields.
I am not sure that those ZINC instructions are the very
culprit for the segmentation fault error. However, even if this
is not the case, the generated ZINC bytecodes looks very strange to
me anyway. Shouldn't we make the tag of the empty block to be
different from those tags of the constructors? Or, shouldn't
we raise an exception saying that an infinite loop is detected?
I am a newcomer to the Caml light system. I found a weird example
that went through the typing process of the system but got stuck
by a segmentation fault error in running, as follows:
[...]
let rec x =
let (MyC (z1,z2,z3,z4,z5,z))=x in
MyC(x,z,z1,z2,z3,z4);;
The problem here is that the type-checking should reject this
expression, because it cannot be compiled correctly by the
compiler back-end.
Unfortunately, we are not working on Caml Light any more, because
we are concentrating on Objective Caml, so I don't know whether or
when this bug will be fixed.
To avoid the bug, you should never use a destructuring let within
a let rec (you can use simple let with a variable as the left-hand
side).
Original bug ID: 1497
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: -for Caml light use https://github.com/camllight/camllight/issues
Bug description
Full_Name: Kwanghoon Choi
Version: Caml light 0.75
OS: SunOS 5.8
Submission from: dol.kaist.ac.kr (143.248.135.109)
Hi,
I am a newcomer to the Caml light system. I found a weird example
that went through the typing process of the system but got stuck
by a segmentation fault error in running, as follows:
$ cat nil.ml
type T = MyC of T * T * T * T * T * T
| YourC ;;
let rec x =
let (MyC (z1,z2,z3,z4,z5,z))=x in
MyC(x,z,z1,z2,z3,z4);;
$ camllight
#load "nil.ml";;
Type T defined.
File "nil.ml", line 6-7, characters 2-60:
Warning: this matching is not exhaustive.
Segmentation fault
In order to examine this behavior further, I looked into the
ZINC bytecode for the caml code. I am not sure but the ZINC
bytecode seems to be strange.
constructor MyC, since the caml compiler happens to assign
0 to the tag of the constructor. Obviously, there is no
field yet in the block allocated by DUMMY.
I am not sure that those ZINC instructions are the very
culprit for the segmentation fault error. However, even if this
is not the case, the generated ZINC bytecodes looks very strange to
me anyway. Shouldn't we make the tag of the empty block to be
different from those tags of the constructors? Or, shouldn't
we raise an exception saying that an infinite loop is detected?
$ camlc nil.ml
$ dumpobj nil.zo
File nil.zo
Offset 4, length 56, impure
0 DUMMY 6 <=======
2 SETGLOBAL 0
5 GETGLOBAL 0
8 LET
9 ACC0
10 TAGOF
11 SWITCH 19, 46, 46, <=======
19 ACC0
20 GETFIELD3 <=======
21 PUSH
22 ACC0
23 GETFIELD2 <=======
24 PUSH
25 ACC0
26 GETFIELD1 <=======
27 PUSH
28 ACC0
29 GETFIELD0 <=======
30 PUSH
31 ACC0
32 GETFIELD 5 <=======
34 PUSH
35 GETGLOBAL 0
38 MAKEBLOCK 6144
43 BRANCH 50
46 GETGLOBAL 0
49 RAISE
50 ENDLET1
51 PUSH
52 GETGLOBAL 0
55 UPDATE
3 provide nil__x
6 require nil__x
36 require nil__x
47 const
53 require nil__x
Please, reply to me directly. I didn't subscribe to the
mailing lists yet.
Thank you for your attention.
Kwanghoon Choi
The text was updated successfully, but these errors were encountered: