From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Noah Lavine Newsgroups: gmane.lisp.guile.bugs Subject: bug#13074: VM Segfaults with Bad `Call' Instruction Date: Tue, 11 Dec 2012 08:32:26 -0500 Message-ID: References: <87hao0r3nh.fsf@gnu.org> <87hao0p2of.fsf@gnu.org> <878v95exhq.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b33993f785a6b04d093b6ef X-Trace: ger.gmane.org 1355232820 13277 80.91.229.3 (11 Dec 2012 13:33:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2012 13:33:40 +0000 (UTC) Cc: 13074-done@debbugs.gnu.org To: Ludovic =?UTF-8?Q?Court=C3=A8s?= Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Tue Dec 11 14:33:53 2012 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TiPy2-0003p5-T1 for guile-bugs@m.gmane.org; Tue, 11 Dec 2012 14:33:51 +0100 Original-Received: from localhost ([::1]:45200 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiPxq-0007sc-3V for guile-bugs@m.gmane.org; Tue, 11 Dec 2012 08:33:38 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58584) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiPxg-0007kz-Fl for bug-guile@gnu.org; Tue, 11 Dec 2012 08:33:35 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TiPxa-0000OA-6i for bug-guile@gnu.org; Tue, 11 Dec 2012 08:33:28 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54595) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TiPxa-0000O6-3F for bug-guile@gnu.org; Tue, 11 Dec 2012 08:33:22 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.72) (envelope-from ) id 1TiPyE-0007DI-BQ for bug-guile@gnu.org; Tue, 11 Dec 2012 08:34:02 -0500 X-Loop: help-debbugs@gnu.org 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: Original-Received: via spool by 13074-done@debbugs.gnu.org id=D13074.135523279427668 (code D ref 13074); Tue, 11 Dec 2012 13:34:02 +0000 Original-Received: (at 13074-done) by debbugs.gnu.org; 11 Dec 2012 13:33:14 +0000 Original-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 Original-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 Original-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== Original-Received: by 10.68.241.73 with SMTP id wg9mr48380629pbc.3.1355232746953; Tue, 11 Dec 2012 05:32:26 -0800 (PST) Original-Received: by 10.68.81.194 with HTTP; Tue, 11 Dec 2012 05:32:26 -0800 (PST) In-Reply-To: <878v95exhq.fsf@gnu.org> X-Google-Sender-Auth: yrC34cZRE-uOvYLoInbcfKLvcpg X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 140.186.70.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:6670 Archived-At: --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--