From owner-freebsd-arch@FreeBSD.ORG Sat Sep 4 05:13:38 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 08C1716A4CE for ; Sat, 4 Sep 2004 05:13:38 +0000 (GMT) Received: from green.homeunix.org (pcp04368961pcs.nrockv01.md.comcast.net [69.140.212.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8700B43D31 for ; Sat, 4 Sep 2004 05:13:37 +0000 (GMT) (envelope-from green@green.homeunix.org) Received: from green.homeunix.org (green@localhost [127.0.0.1]) by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i845DV7x035299; Sat, 4 Sep 2004 01:13:36 -0400 (EDT) (envelope-from green@green.homeunix.org) Received: (from green@localhost) by green.homeunix.org (8.13.1/8.13.1/Submit) id i845DUtk035298; Sat, 4 Sep 2004 01:13:30 -0400 (EDT) (envelope-from green) Date: Sat, 4 Sep 2004 01:13:30 -0400 From: Brian Fundakowski Feldman To: Jun Kuriyama Message-ID: <20040904051330.GH45292@green.homeunix.org> References: <7m3c20x7p3.wl@black.imgsrc.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7m3c20x7p3.wl@black.imgsrc.co.jp> User-Agent: Mutt/1.5.6i cc: arch@FreeBSD.org Subject: Re: abort(3) in libc/db/btree/bt_split.c X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Sep 2004 05:13:38 -0000 On Fri, Sep 03, 2004 at 02:06:16PM +0900, Jun Kuriyama wrote: > > I found there are abort(3)s in bt_split.c (found by ruby18/portupgrade > dumping core). > > It seems flags in data structure which ruby uses are corrupted, but > abort(3) is not helpful for usual users. > > So I think __bt_split() (and other functions in this file) should > return RET_ERROR, or write a dying message before abort(3). > > I'd like to try to code returing RET_ERROR (with internal tree > cleanup) if that is the way to go. Have you checked if they were fixed in subsequent SleepyCat DB 1.x releases to return error instead of dump core, so we could use a vendor fix? -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\