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

  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?

$ 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