[Chicken-hackers] [PATCH] Fix unsafe code generation caused by debugger change in core target language

[Peter Bex]

Hi all,

The attached patch's commit message says it all.

I detected this problem by compiling master with DEBUGBUILD=1 and
running csi:

$ csi
CHICKEN
(c) 2008-2015, The CHICKEN Team
(c) 2000-2007, Felix L. Winkelmann
Version 4.10.1 (rev 5674e3c)
linux-unix-gnu-x86-64 [ 64bit manyargs dload ptables ]
compiled 2016-01-16 on yves.more-magic.net (Linux)

#;1> (1)

Error: segmentation violation

        Call history:

        eval.scm:824: compile     
        eval.scm:248: keyword?    
        eval.scm:288: ##sys#number?       
        eval.scm:302: blob?       
        eval.scm:304: ##sys#srfi-4-vector?        
        <syntax>          (1)
        eval.scm:762: compile-call        
        eval.scm:788: compile     
        eval.scm:248: keyword?    
        eval.scm:288: ##sys#number?       
        eval.scm:857: g1803       
        <eval>    (1)
        eval.scm:794: g1632       
        library.scm:4022: ##sys#get-call-chain    
        library.scm:3811: ##sys#make-vector       
        library.scm:1364: ##sys#allocate-vector         <--

From a git bisect, I found 86010b507bef896d0b744c47633eb0ede8218a4e to
be the cause of this breakage.  Some more investigation into the
generated source showed that the code in eval.scm's compile-call would
translate ((##core#app fn v) (##core#app a1 v)) to a direct function
call like ((C_proc)(void*)((C_word*)t2+1)), where t2 would be taken
straight from the argvector, which corresponds to the object resulting
from (##core#app fn v), which in the example is a fixnum.

The code _should_ read ((C_proc)C_fast_retrieve_proc(t2)), which will
raise an exception if t2 is not a closure object.

Cheers,
Peter

0001-Fix-unsafe-code-generation-for-procedure-calls.chicken-5.patch
Description: Text Data

0001-Fix-unsafe-code-generation-for-procedure-calls.master.patch
Description: Text Data

signature.asc
Description: Digital signature