From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18152 invoked by alias); 5 Nov 2009 14:12:58 -0000 Received: (qmail 18145 invoked by uid 22791); 5 Nov 2009 14:12:57 -0000 X-SWARE-Spam-Status: No, hits=-2.4 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; Thu, 05 Nov 2009 14:12:53 +0000 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nA5ECkn7005380; Thu, 5 Nov 2009 09:12:46 -0500 Received: from fche.csb (vpn-227-44.phx2.redhat.com [10.3.227.44]) by int-mx08.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id nA5ECjPX008506; Thu, 5 Nov 2009 09:12:46 -0500 Received: by fche.csb (Postfix, from userid 2569) id 6BF2058122; Thu, 5 Nov 2009 09:12:45 -0500 (EST) To: "wenji.huang@oracle.com" Cc: "systemtap@sourceware.org" Subject: Re: [RFC PATCH] Fix segmentation fault of listing kprocess.create References: <20091105150217031.00000001204@ETSD-Ora-lap2> <20091105153851046.00000002852@ETSD-Ora-lap2> From: fche@redhat.com (Frank Ch. Eigler) Date: Thu, 05 Nov 2009 14:12:00 -0000 In-Reply-To: <20091105153851046.00000002852@ETSD-Ora-lap2> (Wenji Huang's message of "Thu, 5 Nov 2009 15:38:51 +0800") Message-ID: User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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/msg00433.txt.bz2 "Wenji Huang" writes: >> Please ignore the previous patch, the root cause is the >> following section tapsets.cxx: dwarf_derived_probe::saveargs Indeed. >> /* 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; Right, such an empty token should not exist. (We may be able to remove this default constructor and force clients to fill in the fields immediately.) When synthesizing new parse tree structures, the token pointer assigned to the new objects usually relates to the original script-level object that caused the synthesis. So for example in a return probe that uses a saved entry-time $var, a whole new synthetic probe and global variables could all be assigned to the same "$var" token. Perhaps the recently introduced saveargs() function should be supplied with an appropriate token*, for examples q.base_probe->tok. - FChE