From unknown Mon Aug 11 18:15:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13074: VM Segfaults with Bad `Call' Instruction Resent-From: Noah Lavine Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 04 Dec 2012 03:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 13074 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: 13074@debbugs.gnu.org X-Debbugs-Original-To: bug-guile@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.135459054910681 (code B ref -1); Tue, 04 Dec 2012 03:10:02 +0000 Received: (at submit) by debbugs.gnu.org; 4 Dec 2012 03:09:09 +0000 Received: from localhost ([127.0.0.1]:52261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tfise-0002mD-CV for submit@debbugs.gnu.org; Mon, 03 Dec 2012 22:09:09 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41949) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tfisb-0002m4-CW for submit@debbugs.gnu.org; Mon, 03 Dec 2012 22:09:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TfiqB-0000lO-E7 for submit@debbugs.gnu.org; Mon, 03 Dec 2012 22:06:39 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-102.3 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID,USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:49626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfiqB-0000lK-B2 for submit@debbugs.gnu.org; Mon, 03 Dec 2012 22:06:35 -0500 Received: from eggs.gnu.org ([208.118.235.92]:42821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tfiq7-0006Q1-EY for bug-guile@gnu.org; Mon, 03 Dec 2012 22:06:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tfiq6-0000l6-BI for bug-guile@gnu.org; Mon, 03 Dec 2012 22:06:31 -0500 Received: from mail-pb0-f41.google.com ([209.85.160.41]:38365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tfiq6-0000kq-4x for bug-guile@gnu.org; Mon, 03 Dec 2012 22:06:30 -0500 Received: by mail-pb0-f41.google.com with SMTP id xa7so2405087pbc.0 for ; Mon, 03 Dec 2012 19:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=6z3YEkieaYscc2cP+e3HD+N34eC4CPaGxVglbDWwF4o=; b=nBJ/LpE/FqCbKbdSQzSgXLuL++jtb1RXQI6xE/8/jCTfxi2MR+NFEdSQKwGvWN+Q6t 1AM0fdo/f+xYfC71vQQA5WYzACYABKbLjQWWVnpKF20yjF5QbLzkOE8hUrpNKbXxzBhE CDxSEDCopz6zQvyNBQClQ3EoY5O2AzUdWPj6k4wPA2+Js2PvONl2FFOUSS29T2/jicfF tpD0+cXh/Z3aQowLUEtF6wi7rOV0B+4me373A9gQFhw6ZZ7TvtFw0KefNfHel5rVHR5W fRbUbKXBhvY6Z9NwFZw34ZqqxO23MkPLW9Ntd+abl+gfZLPH4do6QXm/i/k54Jnz3Xya 7z7g== MIME-Version: 1.0 Received: by 10.68.248.1 with SMTP id yi1mr35159014pbc.93.1354590388609; Mon, 03 Dec 2012 19:06:28 -0800 (PST) Received: by 10.68.81.194 with HTTP; Mon, 3 Dec 2012 19:06:28 -0800 (PST) Date: Mon, 3 Dec 2012 22:06:28 -0500 X-Google-Sender-Auth: 5r-ISq2v_AtF3GY1dGG7FcM3ubM Message-ID: From: Noah Lavine Content-Type: multipart/alternative; boundary=047d7b338f63ede44704cffe2684 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.2 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) --047d7b338f63ede44704cffe2684 Content-Type: text/plain; charset=ISO-8859-1 Hello, This is an interesting bug, because the only way to hit it (as far as I can tell) is to mess up when writing a compiler. However, I did mess up, and I discover that I can generate a `call' instruction in the trunk VM where the procedure to call will be 0x0. Then the VM will try to check whether the procedure is really a procedure, and Guile will segfault at line 796 of v-i-system.c. I think the correct behavior would be to throw a `vm-bad-instruction' error instead. The fix should be pretty simple - just check if program is 0x0 and jump to vm-bad-instruction in that case. Noah --047d7b338f63ede44704cffe2684 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

This is an interesting bug, because the only way = to hit it (as far as I can tell) is to mess up when writing a compiler.=A0H= owever, I did mess up, and I discover that I can generate a `call' inst= ruction in the trunk VM where the procedure to call will be 0x0. Then the V= M will try to check whether the procedure is really a procedure, and Guile = will segfault at line 796 of v-i-system.c.

I think the correct behavior would be to throw a `vm-ba= d-instruction' error instead. The fix should be pretty simple - just ch= eck if program is 0x0 and jump to vm-bad-instruction in that case.

Noah

--047d7b338f63ede44704cffe2684-- From unknown Mon Aug 11 18:15:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13074: VM Segfaults with Bad `Call' Instruction Resent-From: Noah Lavine Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 05 Dec 2012 03:28:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13074 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: 13074@debbugs.gnu.org Received: via spool by 13074-submit@debbugs.gnu.org id=B13074.135467802424482 (code B ref 13074); Wed, 05 Dec 2012 03:28:01 +0000 Received: (at 13074) by debbugs.gnu.org; 5 Dec 2012 03:27:04 +0000 Received: from localhost ([127.0.0.1]:53931 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg5dX-0006Mp-Sy for submit@debbugs.gnu.org; Tue, 04 Dec 2012 22:27:04 -0500 Received: from mail-pb0-f44.google.com ([209.85.160.44]:37440) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tg5dT-0006MO-MX for 13074@debbugs.gnu.org; Tue, 04 Dec 2012 22:27:00 -0500 Received: by mail-pb0-f44.google.com with SMTP id uo1so3144212pbc.3 for <13074@debbugs.gnu.org>; Tue, 04 Dec 2012 19:26:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=gxMM9hI+p01BnYjkXLWNYJcmz20N3PBpt7loKwNKDRA=; b=uZbje4eZu9SshC6hrvOG1Ek/SzlasbiplewUgG48kr2mjeEnlVTD5io4clLVVUXpnS smqoPYMbLSkPqAxt2OXIC4VZyoC0omCTiOx8maOWGwSB4ltJkbmIEGwrmXLRfHGI/WAc kLVbK1pStHG06U5RlOhsDXdFz0J4dFoDoy3AND6krM8Fm50YlrJcWRBF7ZZ8huh3RiGm hzaHZQuFHCWWRr+75QVyDlfzMD4jqTvommCIhLs6B6szCKVbOt/5a0cYMDkKHWG9e0hm NlSPk39wEWvEuGMQBf/Wbiug3MvjqnVtBVLBGXKruCYh68VTMrVxOV9miM//Fr3HqQqZ +7CQ== MIME-Version: 1.0 Received: by 10.66.88.198 with SMTP id bi6mr40633464pab.54.1354678012627; Tue, 04 Dec 2012 19:26:52 -0800 (PST) Received: by 10.68.81.194 with HTTP; Tue, 4 Dec 2012 19:26:52 -0800 (PST) In-Reply-To: References: Date: Tue, 4 Dec 2012 22:26:52 -0500 X-Google-Sender-Auth: fWXVL2U4g4qQFe1vbYouzdLOANU Message-ID: From: Noah Lavine Content-Type: multipart/alternative; boundary=f46d042de423ba4b1f04d0128df8 X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.4 (/) --f46d042de423ba4b1f04d0128df8 Content-Type: text/plain; charset=ISO-8859-1 The following patch fixes the problem for me: diff --git a/libguile/vm-i-system.c b/libguile/vm-i-system.c index 7153ab5..dff2ab2 100644 --- a/libguile/vm-i-system.c +++ b/libguile/vm-i-system.c @@ -793,7 +793,9 @@ VM_DEFINE_INSTRUCTION (55, call, "call", 1, -1, 1) VM_HANDLE_INTERRUPTS; - if (SCM_UNLIKELY (!SCM_PROGRAM_P (program))) + if (SCM_UNLIKELY (program == NULL)) + goto vm_error_bad_instruction; + else if (SCM_UNLIKELY (!SCM_PROGRAM_P (program))) { if (SCM_STRUCTP (program) && SCM_STRUCT_APPLICABLE_P (program)) { Any objections if I apply it to stable-2.0? (Or master?) Noah On Mon, Dec 3, 2012 at 10:06 PM, Noah Lavine wrote: > Hello, > > This is an interesting bug, because the only way to hit it (as far as I > can tell) is to mess up when writing a compiler. However, I did mess up, > and I discover that I can generate a `call' instruction in the trunk VM > where the procedure to call will be 0x0. Then the VM will try to check > whether the procedure is really a procedure, and Guile will segfault at > line 796 of v-i-system.c. > > I think the correct behavior would be to throw a `vm-bad-instruction' > error instead. The fix should be pretty simple - just check if program is > 0x0 and jump to vm-bad-instruction in that case. > > Noah > > --f46d042de423ba4b1f04d0128df8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable The following patch fixes the problem for me:

diff = --git a/libguile/vm-i-system.c b/libguile/vm-i-system.c
index 715= 3ab5..dff2ab2 100644
--- a/libguile/vm-i-system.c
+++ b= /libguile/vm-i-system.c
@@ -793,7 +793,9 @@ VM_DEFINE_INSTRUCTION (55, call, "call",= 1, -1, 1)
=A0
=A0 =A0VM_HANDLE_INTERRUPTS;
= =A0
- =A0if (SCM_UNLIKELY (!SCM_PROGRAM_P (program)))
+= =A0if (SCM_UNLIKELY (program =3D=3D NULL))
+ =A0 =A0goto vm_error_bad_instruction;
+ =A0else if (SCM_UN= LIKELY (!SCM_PROGRAM_P (program)))
=A0 =A0 =A0{
=A0 =A0= =A0 =A0if (SCM_STRUCTP (program) && SCM_STRUCT_APPLICABLE_P (progr= am))
=A0 =A0 =A0 =A0 =A0{

Any objections if I apply it to stable-2.0? (Or m= aster?)

Noah

<= br>
On Mon, Dec 3, 2012 at 10:06 PM, Noah Lavine = <noah.b.lavine@gmail.com> wrote:
Hello,

This is an interes= ting bug, because the only way to hit it (as far as I can tell) is to mess = up when writing a compiler.=A0However, I did mess up, and I discover that I= can generate a `call' instruction in the trunk VM where the procedure = to call will be 0x0. Then the VM will try to check whether the procedure is= really a procedure, and Guile will segfault at line 796 of v-i-system.c.

I think the correct behavior would be to throw a `vm-ba= d-instruction' error instead. The fix should be pretty simple - just ch= eck if program is 0x0 and jump to vm-bad-instruction in that case.

Noah


--f46d042de423ba4b1f04d0128df8-- From unknown Mon Aug 11 18:15:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13074: VM Segfaults with Bad `Call' Instruction Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 05 Dec 2012 14:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13074 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: Noah Lavine Cc: 13074@debbugs.gnu.org Received: via spool by 13074-submit@debbugs.gnu.org id=B13074.135471662930721 (code B ref 13074); Wed, 05 Dec 2012 14:11:01 +0000 Received: (at 13074) by debbugs.gnu.org; 5 Dec 2012 14:10:29 +0000 Received: from localhost ([127.0.0.1]:54463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgFgB-0007zR-IL for submit@debbugs.gnu.org; Wed, 05 Dec 2012 09:10:28 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]:19818) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgFg8-0007zG-CA for 13074@debbugs.gnu.org; Wed, 05 Dec 2012 09:10:25 -0500 X-IronPort-AV: E=Sophos;i="4.84,221,1355094000"; d="scan'208";a="184732618" Received: from reverse-83.fdn.fr (HELO pluto) ([80.67.176.83]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 05 Dec 2012 15:10:10 +0100 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: Date: Wed, 05 Dec 2012 15:10:10 +0100 In-Reply-To: (Noah Lavine's message of "Tue, 4 Dec 2012 22:26:52 -0500") Message-ID: <87hao0r3nh.fsf@gnu.org> User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.3 (----) Hi Noah, Noah Lavine skribis: > diff --git a/libguile/vm-i-system.c b/libguile/vm-i-system.c > index 7153ab5..dff2ab2 100644 > --- a/libguile/vm-i-system.c > +++ b/libguile/vm-i-system.c > @@ -793,7 +793,9 @@ VM_DEFINE_INSTRUCTION (55, call, "call", 1, -1, 1) > > VM_HANDLE_INTERRUPTS; > > - if (SCM_UNLIKELY (!SCM_PROGRAM_P (program))) > + if (SCM_UNLIKELY (program =3D=3D NULL)) > + goto vm_error_bad_instruction; > + else if (SCM_UNLIKELY (!SCM_PROGRAM_P (program))) > { > if (SCM_STRUCTP (program) && SCM_STRUCT_APPLICABLE_P (program)) > { I=E2=80=99d rather not apply it, because it adds overhead for every call fo= r a situation that cannot happen when using Guile=E2=80=99s compiler, IIUC. WDYT? Thanks, Ludo=E2=80=99. From unknown Mon Aug 11 18:15:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13074: VM Segfaults with Bad `Call' Instruction Resent-From: Noah Lavine Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 05 Dec 2012 14:55:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13074 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 13074@debbugs.gnu.org Received: via spool by 13074-submit@debbugs.gnu.org id=B13074.13547192721993 (code B ref 13074); Wed, 05 Dec 2012 14:55:01 +0000 Received: (at 13074) by debbugs.gnu.org; 5 Dec 2012 14:54:32 +0000 Received: from localhost ([127.0.0.1]:54503 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgGMq-0000W5-3E for submit@debbugs.gnu.org; Wed, 05 Dec 2012 09:54:32 -0500 Received: from mail-pb0-f44.google.com ([209.85.160.44]:41938) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgGMm-0000Vw-KY for 13074@debbugs.gnu.org; Wed, 05 Dec 2012 09:54:30 -0500 Received: by mail-pb0-f44.google.com with SMTP id uo1so3521122pbc.3 for <13074@debbugs.gnu.org>; Wed, 05 Dec 2012 06:54:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=iGxLqkPDSzOT5C3iKoaHD5r3HiKFf4PzUbzCUnrkmug=; b=IeqN1eJD4r29bWLhHmzxC3uZQzuAQDO9JtYbaF3yxuQ60H2iOKPztUt2vE5O74yTgv ulHO9vX+lPabh06iOCOKWz9AT2YoCYwYpMWsfodMGqeo9qXRj4nmTb8eDu7B4/pFfRaG s5xfe9rgMJYoDF10SwtwoEO8+PO3J6iWZqGvC/7ysZnFrw1coZujgO5agmhJeFCYgbtb 0cJfFrcSmHAjqeiXEEjpYpX6SQkuq8xXSFq1WCsFn4afhEPVWhNtaQhdQZwCTwVPuxc7 F64gFzjC/7khenQ6eJUlX+GEXUVC2f12C3u8K7MypHnQvWJurUYoqcyDQz0QPorFPuk0 LLfA== MIME-Version: 1.0 Received: by 10.66.83.6 with SMTP id m6mr11237363pay.52.1354719260101; Wed, 05 Dec 2012 06:54:20 -0800 (PST) Received: by 10.68.81.194 with HTTP; Wed, 5 Dec 2012 06:54:20 -0800 (PST) In-Reply-To: <87hao0r3nh.fsf@gnu.org> References: <87hao0r3nh.fsf@gnu.org> Date: Wed, 5 Dec 2012 09:54:20 -0500 X-Google-Sender-Auth: 3KptC-0ywdJ_IG31VimyujFiG3U Message-ID: From: Noah Lavine Content-Type: multipart/alternative; boundary=f46d042ef46f44cc8504d01c283b X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.9 (/) --f46d042ef46f44cc8504d01c283b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That makes sense. I hit this error in debugging a CPS->GLIL compiler (which I hope will become Guile's compiler, but that's another story). However, once the debugging is done, I suppose it won't make a difference. What do you think about enabling it only in the debug VM, or something like that? Then if there's some way for me to run my code in debug mode, I can get the better output without slowing down most things. Noah On Wed, Dec 5, 2012 at 9:10 AM, Ludovic Court=E8s wrote: > Hi Noah, > > Noah Lavine skribis: > > > diff --git a/libguile/vm-i-system.c b/libguile/vm-i-system.c > > index 7153ab5..dff2ab2 100644 > > --- a/libguile/vm-i-system.c > > +++ b/libguile/vm-i-system.c > > @@ -793,7 +793,9 @@ VM_DEFINE_INSTRUCTION (55, call, "call", 1, -1, 1) > > > > VM_HANDLE_INTERRUPTS; > > > > - if (SCM_UNLIKELY (!SCM_PROGRAM_P (program))) > > + if (SCM_UNLIKELY (program =3D=3D NULL)) > > + goto vm_error_bad_instruction; > > + else if (SCM_UNLIKELY (!SCM_PROGRAM_P (program))) > > { > > if (SCM_STRUCTP (program) && SCM_STRUCT_APPLICABLE_P (program)) > > { > > I=92d rather not apply it, because it adds overhead for every call for a > situation that cannot happen when using Guile=92s compiler, IIUC. > > WDYT? > > Thanks, > Ludo=92. > --f46d042ef46f44cc8504d01c283b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable That makes sense. I hit this error in debugging a CPS->GLIL compiler (wh= ich I hope will become Guile's compiler, but that's another story).= However, once the debugging is done, I suppose it won't make a differe= nce.

What do you think about enabling it only in the debug VM, or something = like that? Then if there's some way for me to run my code in debug mode= , I can get the better output without slowing down most things.

Noah


On We= d, Dec 5, 2012 at 9:10 AM, Ludovic Court=E8s <ludo@gnu.org> wrot= e:
Hi Noah,

Noah Lavine <noah.b.lavine@gm= ail.com> skribis:

> diff --git a/libguile/vm-i-system.c b/libguile/vm-i-system.c
> index 7153ab5..dff2ab2 100644
> --- a/libguile/vm-i-system.c
> +++ b/libguile/vm-i-system.c
> @@ -793,7 +793,9 @@ VM_DEFINE_INSTRUCTION (55, call, "call",= 1, -1, 1)
>
> =A0 =A0VM_HANDLE_INTERRUPTS;
>
> - =A0if (SCM_UNLIKELY (!SCM_PROGRAM_P (program)))
> + =A0if (SCM_UNLIKELY (program =3D=3D NULL))
> + =A0 =A0goto vm_error_bad_instruction;
> + =A0else if (SCM_UNLIKELY (!SCM_PROGRAM_P (program)))
> =A0 =A0 =A0{
> =A0 =A0 =A0 =A0if (SCM_STRUCTP (program) && SCM_STRUCT_APPLICA= BLE_P (program))
> =A0 =A0 =A0 =A0 =A0{

I=92d rather not apply it, because it adds overhead for every call fo= r a
situation that cannot happen when using Guile=92s compiler, IIUC.

WDYT?

Thanks,
Ludo=92.

--f46d042ef46f44cc8504d01c283b-- From unknown Mon Aug 11 18:15:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13074: VM Segfaults with Bad `Call' Instruction Resent-From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 05 Dec 2012 22:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13074 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: Noah Lavine Cc: 13074@debbugs.gnu.org Received: via spool by 13074-submit@debbugs.gnu.org id=B13074.135474566317216 (code B ref 13074); Wed, 05 Dec 2012 22:15:01 +0000 Received: (at 13074) by debbugs.gnu.org; 5 Dec 2012 22:14:23 +0000 Received: from localhost ([127.0.0.1]:55406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgNEU-0004Tc-Pm for submit@debbugs.gnu.org; Wed, 05 Dec 2012 17:14:23 -0500 Received: from mail1-relais-roc.national.inria.fr ([192.134.164.82]:3813) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TgNES-0004TU-Lz for 13074@debbugs.gnu.org; Wed, 05 Dec 2012 17:14:22 -0500 X-IronPort-AV: E=Sophos;i="4.84,224,1355094000"; d="scan'208";a="184803482" Received: from reverse-83.fdn.fr (HELO pluto) ([80.67.176.83]) by mail1-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 05 Dec 2012 23:14:09 +0100 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) References: <87hao0r3nh.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 15 Frimaire an 221 de la =?UTF-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Wed, 05 Dec 2012 23:14:08 +0100 In-Reply-To: (Noah Lavine's message of "Wed, 5 Dec 2012 09:54:20 -0500") Message-ID: <87hao0p2of.fsf@gnu.org> User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.5 (---) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.3 (----) Noah Lavine skribis: > That makes sense. I hit this error in debugging a CPS->GLIL compiler (whi= ch > I hope will become Guile's compiler, but that's another story). However, > once the debugging is done, I suppose it won't make a difference. Oooh, make sure to post about your plans. > What do you think about enabling it only in the debug VM, or something li= ke > that? Then if there's some way for me to run my code in debug mode, I can > get the better output without slowing down most things. I=E2=80=99m inclined to leave it as is, because it=E2=80=99s only hit when = generating wrong code. How strongly do you feel about it? :-) Ludo=E2=80=99. From unknown Mon Aug 11 18:15:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13074: VM Segfaults with Bad `Call' Instruction Resent-From: Noah Lavine Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 11 Dec 2012 04:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13074 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 13074@debbugs.gnu.org Received: via spool by 13074-submit@debbugs.gnu.org id=B13074.135519943131737 (code B ref 13074); Tue, 11 Dec 2012 04:18:01 +0000 Received: (at 13074) by debbugs.gnu.org; 11 Dec 2012 04:17:11 +0000 Received: from localhost ([127.0.0.1]:36092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiHHL-0008Fp-4o for submit@debbugs.gnu.org; Mon, 10 Dec 2012 23:17:11 -0500 Received: from mail-pa0-f44.google.com ([209.85.220.44]:43644) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiHHG-0008Fe-BZ for 13074@debbugs.gnu.org; Mon, 10 Dec 2012 23:17:07 -0500 Received: by mail-pa0-f44.google.com with SMTP id hz11so2507260pad.3 for <13074@debbugs.gnu.org>; Mon, 10 Dec 2012 20:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=ePHbFPuSYJkxMQVpB9rWN7e0iQIuirHDavZDm7cBXB4=; b=jtzpfm5Xk6zlbT70MDRQWrO9c2A8ADsFgNtlMHIidrqjldI5A8AxwBo70vvrjxwQ0q JRClFR4zNvdvdRWPOV/STaFlGsWpqbw8HR/cpznmPzXZfgNuYjKZEPIVFqj4MertcbeI 0dyROWzTftCQUhDhoAdJI9UNKNu4vlciofQ4neiIBWzgXFxPNe1z+l2cuENpXEF1M88x y5orX5QZJec8FlaFzNZ5fxf7lHdaz8jbP3PvQoPgLCH3gNjQuXaB61oHD3fXCkm06QL4 ixeKnMcRZcA5psQ2tg1c+UQx5iZEVymZ/F2YYaGoRjSQvVGRW+R53DPAt/SuHKRBEKRj cqQQ== MIME-Version: 1.0 Received: by 10.66.83.134 with SMTP id q6mr24888710pay.34.1355199386584; Mon, 10 Dec 2012 20:16:26 -0800 (PST) Received: by 10.68.81.194 with HTTP; Mon, 10 Dec 2012 20:16:26 -0800 (PST) In-Reply-To: <87hao0p2of.fsf@gnu.org> References: <87hao0r3nh.fsf@gnu.org> <87hao0p2of.fsf@gnu.org> Date: Mon, 10 Dec 2012 23:16:26 -0500 X-Google-Sender-Auth: djfC2Aw4o0ZKViiMMxbPrU7MC7g Message-ID: From: Noah Lavine Content-Type: multipart/alternative; boundary=f46d042f949409850004d08bf267 X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.4 (/) --f46d042f949409850004d08bf267 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Wed, Dec 5, 2012 at 5:14 PM, Ludovic Court=E8s wrote: > Noah Lavine skribis: > > > That makes sense. I hit this error in debugging a CPS->GLIL compiler > (which > > I hope will become Guile's compiler, but that's another story). However= , > > once the debugging is done, I suppose it won't make a difference. > > Oooh, make sure to post about your plans. I will post more when I have more code to show, but basically it's the same idea as the CPS-to-RTL experiment earlier. The difference is that in that post I said that adding two new things at the same time (CPS and RTL) was probably a bad idea. Now I'm doing something about it, by making the CPS compiler generate GLIL instead. I hope this will be an easier path towards a nicer compiler. > > What do you think about enabling it only in the debug VM, or something > like > > that? Then if there's some way for me to run my code in debug mode, I c= an > > get the better output without slowing down most things. > > I=92m inclined to leave it as is, because it=92s only hit when generating > wrong code. How strongly do you feel about it? :-) > Well, I just fixed the bug, so I feel fine right now. :-) In general, I do think there should at least be an option for having full error-checking in the VM. It would have been much, much harder for me to find this without having patched the VM, because it would have taken me a very long time to try each new thing I tried, because I would have had to restart Guile. I am happy for it not to be on the regular code-path, though. I also realize that writing a compiler is an unusual application, so maybe it should even be a compile-time option for users who prefer their Guile slow. How does that sound? Noah --f46d042f949409850004d08bf267 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On Wed, Dec 5, 20= 12 at 5:14 PM, Ludovic Court=E8s <ludo@gnu.org> wrote:
Noah Lavine <noah.b.lavine@gm= ail.com> skribis:

> That makes sense. I hit this error in debugging a CPS->GLIL compile= r (which
> I hope will become Guile's compiler, but that's another story)= . However,
> once the debugging is done, I suppose it won't make a difference.<= br>
Oooh, make sure to post about your plans.

=
I will post more when I have more code to show, but basically it's= the same idea as the CPS-to-RTL experiment earlier. The difference is that= in that post I said that adding two new things at the same time (CPS and R= TL) was probably a bad idea. Now I'm doing something about it, by makin= g the CPS compiler generate GLIL instead. I hope this will be an easier pat= h towards a nicer compiler.
=A0
> What do you think about enabling it only in the debug VM, or something= like
> that? Then if there's some way for me to run my code in debug mode= , I can
> get the better output without slowing down most things.

I=92m inclined to leave it as is, because it=92s only hit when genera= ting
wrong code. =A0How strongly do you feel about it? =A0:-)

Well, I just fixed the bug, so I feel fine right now. :-)=

In general, I do think there should at least be a= n option for having full error-checking in the VM. It would have been much,= much harder for me to find this without having patched the VM, because it = would have taken me a very long time to try each new thing I tried, because= I would have had to restart Guile. I am happy for it not to be on the regu= lar code-path, though. I also realize that writing a compiler is an unusual= application, so maybe it should even be a compile-time option for users wh= o prefer their Guile slow. How does that sound?

Noah=A0

--f46d042f949409850004d08bf267-- From unknown Mon Aug 11 18:15:41 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.428 (Entity 5.428) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Noah Lavine Subject: bug#13074: closed (Re: bug#13074: VM Segfaults with Bad `Call' Instruction) Message-ID: References: <878v95exhq.fsf@gnu.org> X-Gnu-PR-Message: they-closed 13074 X-Gnu-PR-Package: guile Reply-To: 13074@debbugs.gnu.org Date: Tue, 11 Dec 2012 09:43:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1355218982-3662-1" This is a multi-part message in MIME format... ------------=_1355218982-3662-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #13074: VM Segfaults with Bad `Call' Instruction which was filed against the guile package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 13074@debbugs.gnu.org. --=20 13074: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D13074 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1355218982-3662-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 13074-done) by debbugs.gnu.org; 11 Dec 2012 09:42:53 +0000 Received: from localhost ([127.0.0.1]:36430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiMMX-0000wl-DX for submit@debbugs.gnu.org; Tue, 11 Dec 2012 04:42:53 -0500 Received: from mail4-relais-sop.national.inria.fr ([192.134.164.105]:64755) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiMMV-0000we-Fg for 13074-done@debbugs.gnu.org; Tue, 11 Dec 2012 04:42:52 -0500 X-IronPort-AV: E=Sophos;i="4.84,258,1355094000"; d="scan'208";a="165430268" Received: from nat-eduroam-37.bordeaux.inria.fr (HELO pluto) ([194.199.1.37]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 11 Dec 2012 10:42:09 +0100 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) To: Noah Lavine Subject: Re: bug#13074: VM Segfaults with Bad `Call' Instruction References: <87hao0r3nh.fsf@gnu.org> <87hao0p2of.fsf@gnu.org> X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 21 Frimaire an 221 de la =?utf-8?Q?R=C3=A9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 83C4 F8E5 10A3 3B4C 5BEA D15D 77DD 95E2 EA52 ECF4 X-OS: x86_64-unknown-linux-gnu Date: Tue, 11 Dec 2012 10:42:09 +0100 In-Reply-To: (Noah Lavine's message of "Mon, 10 Dec 2012 23:16:26 -0500") Message-ID: <878v95exhq.fsf@gnu.org> User-Agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -3.5 (---) X-Debbugs-Envelope-To: 13074-done Cc: 13074-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.3 (----) Hi! Noah Lavine skribis: > In general, I do think there should at least be an option for having full > error-checking in the VM. It would have been much, much harder for me to > find this without having patched the VM, because it would have taken me a > very long time to try each new thing I tried, because I would have had to > restart Guile. I am happy for it not to be on the regular code-path, > though. I also realize that writing a compiler is an unusual application, > so maybe it should even be a compile-time option for users who prefer the= ir > Guile slow. How does that sound? The VM does full error checking. But there=E2=80=99s a difference between checking whether an object has the expected type, and checking whether an object is a well-formed =E2=80=98SCM=E2=80=99 object (and NULL is not a = valid =E2=80=98SCM=E2=80=99 object.) Guile never does the latter, and as a rule of thumb I would keep things this way. The brave hacker working on a compiler can easily figure out what how to debug all sorts of crazy things. :-) So I=E2=80=99m closing it for now. Thanks, Ludo=E2=80=99. PS: It=E2=80=99s still unclear to me how you ended up forging an invalid SCM object. I think you either have to generate invalid bytecode, or to use (pointer->scm %null-pointer), or variants thereof. ------------=_1355218982-3662-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 4 Dec 2012 03:09:09 +0000 Received: from localhost ([127.0.0.1]:52261 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tfise-0002mD-CV for submit@debbugs.gnu.org; Mon, 03 Dec 2012 22:09:09 -0500 Received: from eggs.gnu.org ([208.118.235.92]:41949) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Tfisb-0002m4-CW for submit@debbugs.gnu.org; Mon, 03 Dec 2012 22:09:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TfiqB-0000lO-E7 for submit@debbugs.gnu.org; Mon, 03 Dec 2012 22:06:39 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-102.3 required=5.0 tests=BAYES_00, FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID,USER_IN_WHITELIST autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([208.118.235.17]:49626) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TfiqB-0000lK-B2 for submit@debbugs.gnu.org; Mon, 03 Dec 2012 22:06:35 -0500 Received: from eggs.gnu.org ([208.118.235.92]:42821) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tfiq7-0006Q1-EY for bug-guile@gnu.org; Mon, 03 Dec 2012 22:06:35 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tfiq6-0000l6-BI for bug-guile@gnu.org; Mon, 03 Dec 2012 22:06:31 -0500 Received: from mail-pb0-f41.google.com ([209.85.160.41]:38365) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tfiq6-0000kq-4x for bug-guile@gnu.org; Mon, 03 Dec 2012 22:06:30 -0500 Received: by mail-pb0-f41.google.com with SMTP id xa7so2405087pbc.0 for ; Mon, 03 Dec 2012 19:06:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=6z3YEkieaYscc2cP+e3HD+N34eC4CPaGxVglbDWwF4o=; b=nBJ/LpE/FqCbKbdSQzSgXLuL++jtb1RXQI6xE/8/jCTfxi2MR+NFEdSQKwGvWN+Q6t 1AM0fdo/f+xYfC71vQQA5WYzACYABKbLjQWWVnpKF20yjF5QbLzkOE8hUrpNKbXxzBhE CDxSEDCopz6zQvyNBQClQ3EoY5O2AzUdWPj6k4wPA2+Js2PvONl2FFOUSS29T2/jicfF tpD0+cXh/Z3aQowLUEtF6wi7rOV0B+4me373A9gQFhw6ZZ7TvtFw0KefNfHel5rVHR5W fRbUbKXBhvY6Z9NwFZw34ZqqxO23MkPLW9Ntd+abl+gfZLPH4do6QXm/i/k54Jnz3Xya 7z7g== MIME-Version: 1.0 Received: by 10.68.248.1 with SMTP id yi1mr35159014pbc.93.1354590388609; Mon, 03 Dec 2012 19:06:28 -0800 (PST) Received: by 10.68.81.194 with HTTP; Mon, 3 Dec 2012 19:06:28 -0800 (PST) Date: Mon, 3 Dec 2012 22:06:28 -0500 X-Google-Sender-Auth: 5r-ISq2v_AtF3GY1dGG7FcM3ubM Message-ID: Subject: VM Segfaults with Bad `Call' Instruction From: Noah Lavine To: bug-guile@gnu.org Content-Type: multipart/alternative; boundary=047d7b338f63ede44704cffe2684 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 208.118.235.17 X-Spam-Score: -3.2 (---) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -3.2 (---) --047d7b338f63ede44704cffe2684 Content-Type: text/plain; charset=ISO-8859-1 Hello, This is an interesting bug, because the only way to hit it (as far as I can tell) is to mess up when writing a compiler. However, I did mess up, and I discover that I can generate a `call' instruction in the trunk VM where the procedure to call will be 0x0. Then the VM will try to check whether the procedure is really a procedure, and Guile will segfault at line 796 of v-i-system.c. I think the correct behavior would be to throw a `vm-bad-instruction' error instead. The fix should be pretty simple - just check if program is 0x0 and jump to vm-bad-instruction in that case. Noah --047d7b338f63ede44704cffe2684 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

This is an interesting bug, because the only way = to hit it (as far as I can tell) is to mess up when writing a compiler.=A0H= owever, I did mess up, and I discover that I can generate a `call' inst= ruction in the trunk VM where the procedure to call will be 0x0. Then the V= M will try to check whether the procedure is really a procedure, and Guile = will segfault at line 796 of v-i-system.c.

I think the correct behavior would be to throw a `vm-ba= d-instruction' error instead. The fix should be pretty simple - just ch= eck if program is 0x0 and jump to vm-bad-instruction in that case.

Noah

--047d7b338f63ede44704cffe2684-- ------------=_1355218982-3662-1-- From unknown Mon Aug 11 18:15:41 2025 X-Loop: help-debbugs@gnu.org Subject: bug#13074: VM Segfaults with Bad `Call' Instruction Resent-From: Noah Lavine Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 11 Dec 2012 13:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 13074 X-GNU-PR-Package: guile X-GNU-PR-Keywords: To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Cc: 13074-done@debbugs.gnu.org Received: via spool by 13074-done@debbugs.gnu.org id=D13074.135523279427668 (code D ref 13074); Tue, 11 Dec 2012 13:34:02 +0000 Received: (at 13074-done) by debbugs.gnu.org; 11 Dec 2012 13:33:14 +0000 Received: from localhost ([127.0.0.1]:36613 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiPxR-0007CC-Qp for submit@debbugs.gnu.org; Tue, 11 Dec 2012 08:33:14 -0500 Received: from mail-pa0-f44.google.com ([209.85.220.44]:44067) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1TiPxO-0007C5-NW for 13074-done@debbugs.gnu.org; Tue, 11 Dec 2012 08:33:12 -0500 Received: by mail-pa0-f44.google.com with SMTP id hz11so2824172pad.3 for <13074-done@debbugs.gnu.org>; Tue, 11 Dec 2012 05:32:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Achv3SdiI6O/N4S8xpDxuP5K9JAgQzD6k4H7mQs1wik=; b=rjSxCr9/y1tI1lGBNE1TrrSWMIuWfQRIxOhrsNSxNk+7qry9GNY4napzhrng+YNM9Q D5pwSMou5kCkqar8qVaSgr7/80Kq8xsNrIvJ9974huysCQy/PFzsU8YE7qv2PsWnroMy AHWoitbrNXsicmj/IF55wPqsS5v/rOhicFirc/caSmxV7Q7gWdJSAas6pIV7EallcT8A FaK+XG5YHC5aAUCS/OOiE66v9DeZHym+RRFDDvBc5SopZdvG0vZ+NT7tpL3gv+yprqxS uOBrEi/iBYd07HOCBsa8ITXKjaACJ5jVoQSWj4Qjj9vfKuK+caSL4APihB2LZ/D6fZxF os2w== MIME-Version: 1.0 Received: by 10.68.241.73 with SMTP id wg9mr48380629pbc.3.1355232746953; Tue, 11 Dec 2012 05:32:26 -0800 (PST) Received: by 10.68.81.194 with HTTP; Tue, 11 Dec 2012 05:32:26 -0800 (PST) In-Reply-To: <878v95exhq.fsf@gnu.org> References: <87hao0r3nh.fsf@gnu.org> <87hao0p2of.fsf@gnu.org> <878v95exhq.fsf@gnu.org> Date: Tue, 11 Dec 2012 08:32:26 -0500 X-Google-Sender-Auth: yrC34cZRE-uOvYLoInbcfKLvcpg Message-ID: From: Noah Lavine Content-Type: multipart/alternative; boundary=047d7b33993f785a6b04d093b6ef X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: 0.4 (/) --047d7b33993f785a6b04d093b6ef Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On Tue, Dec 11, 2012 at 4:42 AM, Ludovic Court=E8s wrote: > > The VM does full error checking. But there=92s a difference between > checking whether an object has the expected type, and checking whether > an object is a well-formed =91SCM=92 object (and NULL is not a valid =91S= CM=92 > object.) > > Guile never does the latter, and as a rule of thumb I would keep things > this way. > Okay. > The brave hacker working on a compiler can easily figure out what how to > debug all sorts of crazy things. :-) > Yes, "easily". :-) > So I=92m closing it for now. > > Thanks, > Ludo=92. > > PS: It=92s still unclear to me how you ended up forging an invalid SCM > object. I think you either have to generate invalid bytecode, or to > use (pointer->scm %null-pointer), or variants thereof. > I loaded a procedure on the stack, used the new-frame instruction, and then the call instruction. When I switched the order of the first two things, the problem went away. I must have been using uninitialized stack space. Noah --047d7b33993f785a6b04d093b6ef Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable


On Tue, D= ec 11, 2012 at 4:42 AM, Ludovic Court=E8s <ludo@gnu.org> wrote: The VM does full error checking. =A0But there=92s a difference between
checking whether an object has the expected type, and checking whether
an object is a well-formed =91SCM=92 object (and NULL is not a valid =91SCM= =92
object.)

Guile never does the latter, and as a rule of thumb I would keep things
this way.

Okay.
=A0
The brave hacker working on a compiler can easily figure out what how to debug all sorts of crazy things. =A0:-)

Yes, "easily". :-)
=A0
So I=92m closing it for now.

Thanks,
Ludo=92.

PS: It=92s still unclear to me how you ended up forging an invalid SCM
=A0 =A0 object. =A0I think you either have to generate invalid bytecode, or= to
=A0 =A0 use (pointer->scm %null-pointer), or variants thereof.

I loaded a procedure on the stack, used the new-= frame instruction, and then the call instruction. When I switched the order= of the first two things, the problem went away. I must have been using uni= nitialized stack space.

Noah

--047d7b33993f785a6b04d093b6ef--