`make-pathname' causes a segfault when given a list of non-strings as first argument

[Mario Domenech Goulart]

$ csi -R files -n

CHICKEN
(c)2008-2011 The Chicken Team
(c)2000-2007 Felix L. Winkelmann
Version 4.7.5 (rev bd1d0fc)
linux-unix-gnu-x86 [ manyargs dload ptables ]
compiled 2012-05-23 on hd-t1179cl (Linux)

; loading salmonella-master/chicken/lib/chicken/6/files.import.so ...
; loading library files ...
#;1> (make-pathname (list #f) "foo")
Segmentation fault (core dumped)

[Jim Ursetto]

Confirmed here. Does not segfault on 4.7.0 or 4.7.0.5-st though.

[Christian Kellermann]

I have sent a patch to chicken-hackers

[Mario Domenech Goulart]

Fixed by dd18d957edaccd5301875e6b073a873bae8b15cc

[Mario Domenech Goulart]

I'm not sure dd18d957edaccd5301875e6b073a873bae8b15cc is the right fix for the problem. It seems that it has been introduced between 4.7.3 and 4.7.4. In that period, the was no relevant change to files.scm.

I'm going to keep that commit as a workaround, but I think this issue deserves further investigation. Maybe we are just covering a more serious compiler bug.

[Mario Domenech Goulart]

I've found (via "git bisect") that 85e8ad0baba7210e2a7cf270232af0f5388e1ef5 is the commit that triggers that behavior. More specifically, this part, probably:

-#XXX CHICKEN_OPTIONS += -specialize -types $(SRCDIR)types.db 
+CHICKEN_OPTIONS += -specialize -types $(SRCDIR)types.db 

which seems to be just the tip of the iceberg. :-)

[Mario Domenech Goulart]

Here's a code snippet that can be used to reproduce the problem (based on file.scm's conc-dirs):

$ cat conc-dirs.scm
(define (conc-dirs dirs)
  (let loop ((strs dirs))
    (if (null? strs)
	""
	(let ((s1 (car strs)))
	  (if (zero? (string-length s1))
	      (loop (cdr strs))
	      (loop (cdr strs)))))))

(print (conc-dirs '(#f)))

$ csc conc-dirs.scm && ./conc-dirs

Error: (string-length) bad argument type: #f

        Call history:

        conc-dirs.scm:10: conc-dirs             <--

$ csc -specialize conc-dirs.scm && ./conc-dirs
Segmentation fault (core dumped)

However, it works as expected if I just remove the let binding:

$ cat conc-dirs2.scm
(define (conc-dirs dirs)
  (let loop ((strs dirs))
    (if (null? strs)
	""
	(if (zero? (string-length (car strs)))
	    (loop (cdr strs))
	    (loop (cdr strs))))))

(print (conc-dirs '(#f)))

$ csc -specialize conc-dirs2.scm && ./conc-dirs2

Error: (string-length) bad argument type: #f

        Call history:

        conc-dirs2.scm:9: conc-dirs             <--

[Christian Kellermann]

A simpler example to trigger this is:

(define (t l)
  (let ((s1 (car l)))
    (zero? (string-length s1))))

(print (t '(#f)))

The let in combination of the predicate zero? seems to be necessary to trigger this.

[Christian Kellermann]

The crash seems to get caused by string-length's specialisation to ##sys#size which reproducably crashes when it gets passed #f. Why does the flow analysis thing we do have a string here?

[Christian Kellermann]

I think it's the #:enforce flag of string-length's types.db entry. I have sent a patch to chicken-hackers for review.

[felix winkelmann]

This is a bug in the flow-analysis pass. Somehow the enforcement-property of string-length is applied to early, for whatever reason.

[felix winkelmann]

The expression is walked twice. The first walk applies the enforcement, the second makes the incorrect assumption - see #751.

[felix winkelmann]

Milestone 4.8.0 deleted