From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1208 invoked by alias); 10 Feb 2017 12:58:10 -0000 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 Received: (qmail 1191 invoked by uid 89); 10 Feb 2017 12:58:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*MI:sk:2017021 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 10 Feb 2017 12:58:08 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BEC1D81138 for ; Fri, 10 Feb 2017 12:58:08 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v1ACw7N2022060; Fri, 10 Feb 2017 07:58:07 -0500 Subject: Re: [OB PATCH] Fix NULL pointer dereference To: Gary Benson References: <1486654779-20073-1-git-send-email-gbenson@redhat.com> <84176f49-455d-06ff-6be5-ae50dda14b65@redhat.com> <20170210111927.GA11874@blade.nx> Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: Date: Fri, 10 Feb 2017 12:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20170210111927.GA11874@blade.nx> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-02/txt/msg00251.txt.bz2 On 02/10/2017 11:19 AM, Gary Benson wrote: > Me too, I suppose, though that symtab.c is full of checks for it > so I assumed it meant something. Maybe I was rash! Anyway, here's > the backtrace: > > #0 0x00000000007271be in add_symtab_completions (cust=0x0, sym_text=0x7fffffffdb02 "si", sym_text_len=2, text=0x7fffffffdb02 "si", word=0x7fffffffdb02 "si", > code=TYPE_CODE_UNDEF) at ../../src/gdb/symtab.c:5172 > #1 0x00000000007272cc in symtab_expansion_callback (symtab=0x0, user_data=0x7fffffffd7a0) at ../../src/gdb/symtab.c:5197 > #2 0x00000000006d959a in psym_expand_symtabs_matching (objfile=0x1717540, file_matcher=0x0, symbol_matcher=0x727144 , > expansion_notify=0x72727c , kind=ALL_DOMAIN, data=0x7fffffffd7a0) at ../../src/gdb/psymtab.c:1444 > #3 0x00000000007194c6 in expand_symtabs_matching (file_matcher=0x0, symbol_matcher=0x727144 , > expansion_notify=0x72727c , kind=ALL_DOMAIN, data=0x7fffffffd7a0) at ../../src/gdb/symfile.c:3897 So we reach this call of the 'expansion_notify' function pointer: if (recursively_search_psymtabs (ps, objfile, kind, symbol_matcher, data)) { struct compunit_symtab *symtab = psymtab_to_symtab (objfile, ps); if (expansion_notify != NULL) expansion_notify (symtab, data); } } So why can recursively_search_psymtabs find a matching partial symbol and thus return true, and then psymtab_to_symtab returns NULL, indicating the symtab is empty? That sounds like a bug? Thanks, Pedro Alves