From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14730 invoked by alias); 22 Oct 2009 10:43:11 -0000 Received: (qmail 14716 invoked by uid 22791); 22 Oct 2009 10:43:08 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Oct 2009 10:43:04 +0000 Received: (qmail 22460 invoked from network); 22 Oct 2009 10:43:02 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Oct 2009 10:43:02 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] Fix for PR gdb/10819 Date: Thu, 22 Oct 2009 10:43:00 -0000 User-Agent: KMail/1.9.10 Cc: Paul Pluzhnikov , Jan Kratochvil References: <8ac60eac0910212148w24f44d53xfa6bedd7e12b41d1@mail.gmail.com> <20091022054758.GA15116@host0.dyn.jankratochvil.net> <8ac60eac0910212314h3517ff9btcad84f8d0978bddb@mail.gmail.com> In-Reply-To: <8ac60eac0910212314h3517ff9btcad84f8d0978bddb@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910221142.55021.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00516.txt.bz2 On Thursday 22 October 2009 07:14:21, Paul Pluzhnikov wrote: > Comment added. > + if (cie_table->num_entries == 0) > + { > + /* On Solaris 8 bsearch may call comparison function even when given > + an empty table. As a work around, don't call bsearch under these > + conditions. */ > + return NULL; > + } >Apparently calling bsearch on a table with zero elements is unsafe on Solaris >8. FTR, so that this is archived, see: http://cvs.opensolaris.org/source/xref/pef/phase_I/usr/src/lib/libbc/libc/gen/common/bsearch.c 43 int two_width = width + width; 44 POINTER last = base + width * (nel - 1); /* Last element in table */ 45 46 while (last >= base) { The issue happens because you're passing a NULL BASE (your ENTRIES), so LAST wraps around, and the while loop enters. That bsearch assumes BASE is a pointer into a valid object, which seems valid given that BASE should point at an array of NEL objects. You don't have a table with zero elements, you have no table at all. Note that the solaris man page doesn't explicitly specify that when NEL is 0, the compare function should not be called, no matter what. opengroup.org does, but that probably post dates the original bsearch appearences. This seems to have been considered in more recent sources: http://cvs.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/common/util/bsearch.c It is quite possible that other unix hosts have the same valid-object assumption, if not by chance, because it's quite possible that they've inherited the exact same bsearch.c implementation. I see that netbsd's implementation even asserts (in devel builds only it seems) that base is not null. There's another bsearch call in dwarf2-frame.c and another one in objfiles.c (all recent and yours, it seems :-)). Do they need attention to the base==NULL or number-elements==0 case as well? - Pedro Alves