From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12122 invoked by alias); 7 Nov 2009 00:14:26 -0000 Received: (qmail 12115 invoked by uid 22791); 7 Nov 2009 00:14:26 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 07 Nov 2009 00:14:21 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nA70EEUV014279; Fri, 6 Nov 2009 19:14:14 -0500 Received: from [10.3.242.232] (vpn-242-232.phx2.redhat.com [10.3.242.232]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nA70EE1Z028800; Fri, 6 Nov 2009 19:14:14 -0500 Message-ID: <4AF4BBD6.9020105@redhat.com> Date: Sat, 07 Nov 2009 00:14:00 -0000 From: Josh Stone User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20090922 Fedora/3.0-3.9.b4.fc12 Lightning/1.0pre Thunderbird/3.0b4 MIME-Version: 1.0 To: "wenji.huang@oracle.com" CC: "systemtap@sourceware.org" Subject: Re: [RFC PATCH] Fix segmentation fault of listing kprocess.create References: <20091105153851046.00000002852@ETSD-Ora-lap2> In-Reply-To: <20091105153851046.00000002852@ETSD-Ora-lap2> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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 X-SW-Source: 2009-q4/txt/msg00458.txt.bz2 On 11/04/2009 11:38 PM, Wenji Huang wrote: > Hi, > > Sorry for a little annoying thread. ^-^ >> Please ignore the previous patch, the root cause is the >> following section >> tapsets.cxx: dwarf_derived_probe::saveargs >> >> /* trick from visit_target_symbol_context */ >> target_symbol *tsym = new target_symbol; >> token *t = new token; >> tsym->tok = t; >> tsym->base_name = "$"; >> tsym->base_name += arg_name; >> >> The empty token is created, I will fix it soon. >> Also any suggestion is welcome! >> > Take a deep look. Seems we will try to access the variables in > return probe. It's fully supported or not? Guess not. > > If not, the function should return early once has_return is true. > If yes, we will hypothesize accessing the argument. And the > source_loc of t has to be q.base_loc since no real one. You were on to the real problem here, and then you and Frank kept talking about token pointers... Yes, we do support reading variables in a return probe, but that's playing funny games with saveargs. The issue is that when a $var is accessed in a return probe, the dwarf_var_expanding_visitor will create a matching .call which does the real $var access. The .call will get resolved later, so within this saveargs it will always appear successful. I committed d87623a which momentarily suspends the has_return status, so that dwarf_var_expanding_visitor won't try to do anything funny. This appears to work for me, so let me know if it still gives you trouble. Josh