From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18131 invoked by alias); 13 Jan 2014 10:49:24 -0000 Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org Received: (qmail 18121 invoked by uid 89); 13 Jan 2014 10:49:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 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; Mon, 13 Jan 2014 10:49:22 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s0DAnKou030725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Jan 2014 05:49:20 -0500 Received: from [10.36.116.92] (ovpn-116-92.ams2.redhat.com [10.36.116.92]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s0DAnJ5a013346; Mon, 13 Jan 2014 05:49:19 -0500 Subject: Re: report a segment fault bug of systemtap From: Mark Wielaard To: "Frank Ch. Eigler" Cc: maliubiao , systemtap@sourceware.org In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 13 Jan 2014 10:49:00 -0000 Message-ID: <1389610159.23835.46.camel@bordewijk.wildebeest.org> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-q1/txt/msg00025.txt.bz2 On Sat, 2014-01-11 at 13:10 -0500, Frank Ch. Eigler wrote: > It seems like incomplete DWARF data can result in elfutils passing > NULL char*'s to the stap translator, which the latter is not always > prepared to tolerate. We encountered this same problem here yesterday > and committed a patch. I quickly looked at the patch and I do think elfutils is allowed to return NULL indeed. And you should guard against it. dwarf_decl_file () will return NULL when there is no DW_AT_decl_file attribute, if the value is zero (which indicates no source information was recorded by the compiler) or if the .debug_line section isn't valid/doesn't contain the indicated source file. dwarf_diename () will return NULL when no DW_AT_name attribute can be found (which isn't guaranteed to be produced by the compiler in all cases). Or if the DW_AT_name is wrongly encoded (isn't a string). In particular for CUs a DW_TAG_compile_unit often does have a name (the primary source the compiler used), but a DW_TAG_partial_unit often doesn't have one (since there it might be unclear whether there even is a primary source file in that case). Cheers, Mark