[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-hackers] [PATCH] Fix unsafe code generation caused by debugger
From: |
Peter Bex |
Subject: |
[Chicken-hackers] [PATCH] Fix unsafe code generation caused by debugger change in core target language |
Date: |
Sat, 23 Jan 2016 21:12:38 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- [Chicken-hackers] [PATCH] Fix unsafe code generation caused by debugger change in core target language,
Peter Bex <=