From owner-freebsd-current@FreeBSD.ORG Sun Apr 11 00:14:55 2010 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8A71C106564A for ; Sun, 11 Apr 2010 00:14:55 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2508FC12 for ; Sun, 11 Apr 2010 00:14:54 +0000 (UTC) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id o3B0EsRt010462; Sat, 10 Apr 2010 17:14:54 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.3/Submit) id o3B0EsIS010461; Sat, 10 Apr 2010 17:14:54 -0700 (PDT) (envelope-from david) Date: Sat, 10 Apr 2010 17:14:54 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20100411001454.GO73901@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ScBGguMCFzdFq7Io" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: SIGSEGV in dc, at bcode.c:277 (function reset_bmachine()) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 00:14:55 -0000 --ScBGguMCFzdFq7Io Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As these things go, this probably isn't as critical as most thinsg disussed on this list, but I happened to notice it today, built a debugging world and at least cornered the annoying little varmint. Sorry; no patch at this time. :-( Here's how to reproduce it: while running CURRENT, invoke dc(1) using the command-line expression-soecification ("-e ..."), thus: freebeast(9.0-C)[2] dc -e "6 2/p" Segmentation fault (core dumped) freebeast(9.0-C)[3]=20 This was running: FreeBSD freebeast.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r206447= : Sat Apr 10 14:49:56 PDT 2010 root@freebeast.catwhisker.org:/common/S1= /obj/usr/src/sys/GENERIC i386 It's been a while since I did much with gdb, so the attempt at post-mortem dump analysis wasn't very useful. However, I did try re-running the test under gdb, which demonstrated that on (initial) entry to reset_bmachine(), init_bmachine() has not (yet?) been called; as as result, there is no storage allocated to bmachine.readstack[]. This is an issue because reset_bmachine() tries to place data in that array, thus: 270 271 /* Reset the things needed before processing a (new) file */ 272 void 273 reset_bmachine(struct source *src) 274 { 275=20 276 bmachine.readsp =3D 0; 277 bmachine.readstack[0] =3D *src; 278 } 279=20 Now, I've not had occasion to prowl around and become familiar with the internals of dc(1), so I don't know whether invoking reset_bmachine() without having invoked init_bmachine() beforehand is just bogus, or if perhaps reset_bmachine() should check to see if init_bmachine() has been called (and if not, call it), or .... But I think it's fairly clear that there's a bit of a logic error here. [In case anyone was wondering why someone might try to use that form of invocation: I was doing arithmetic in a shell script, and wanted to be able to control rounding, rather than necessarily performing so- called "integer" arithmetic.] I can file a PR if it would help the tracking & getting the bug fixed. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --ScBGguMCFzdFq7Io Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iEYEARECAAYFAkvBFHgACgkQmprOCmdXAD0OvACggRZFY4ZkKO6BiFupKJUOYI7C C7YAn0zl+TY5D7kInmyp6uOrI0t2QAGG =jGOj -----END PGP SIGNATURE----- --ScBGguMCFzdFq7Io--