From owner-freebsd-dtrace@freebsd.org Mon Dec 19 02:55:26 2016 Return-Path: Delivered-To: freebsd-dtrace@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41B53C879BB for ; Mon, 19 Dec 2016 02:55:26 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0F54C1B1F; Mon, 19 Dec 2016 02:55:25 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk0-x244.google.com with SMTP id n204so3743179qke.2; Sun, 18 Dec 2016 18:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=CvQfomHCXg0CA7Oavb550wfCqt34mFoNJK2xl5/KDJo=; b=KntaHnX3WbYvpt4atd0owlwcTfjDEb9qYfcXTmaoZe6dOhV7vdaH4FbphJYm5ne4DK NuWy51C89X1wpzTJ9ymprHsVrLIGYvsDXYK6+e6zxuwmHj2nD0RNaBcDXMiWMKsd++fh 88dD4Xqh+tCzT73vP4Eo/EIhvwCuhCiEHOj+9/W0ly9BdtSMvvE4ZcYDTZca17vBRQVZ QZ14nxkhvfT0M9W0BYgaKPimUaYDJERRSFh4JRVZKiK0bmz56T5iJ1ko1BBfcC1aKDzG 7Y1fPmny6+V6bBAr7upzpL97s6EHmjMuFBc2czTtchTifls55n13IIAT2bYHthb5uFRt tKdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=CvQfomHCXg0CA7Oavb550wfCqt34mFoNJK2xl5/KDJo=; b=AVKSCPxyzbS8OO5R10gORrBI7LyOdv3chAZWbIK+TSHzDU4i4PLqCPPAV8hP11YINQ DFQrUG6Go6v04Le0YyzoY6O26cDGwj53QSzd9MeUToIHUygeNkjH4kY4+XKfNDLRXXnA AdTKDYM7qmynUMv/m2dNzAgkEBigRGpATth4W1vPmMxH/qPYA3SeML82Ip3nEW2toNWo mPbaWp3yLBcV9ge3cngxIV8BUQzMXoy1dRoI+X9q2V0TRzJkkkyTexZlWCsCXmqH1Y5w T8ld5rtFPNoUlaxmFA/LR5cOt5jJ7zWX6Jug2jR6Un1ZTW50lQHogYnYOkMQ4wztw0IP Y+kA== X-Gm-Message-State: AIkVDXLwEylNQ1zzImDXIX+EA36Pt2VVhRg7h1ILXQ7eJg4zQ23wYmsr7/L1b3vn1hXHoQ== X-Received: by 10.55.43.158 with SMTP id r30mr1219775qkr.28.1482116125083; Sun, 18 Dec 2016 18:55:25 -0800 (PST) Received: from wkstn-mjohnston.west.isilon.com (c-76-104-201-218.hsd1.wa.comcast.net. [76.104.201.218]) by smtp.gmail.com with ESMTPSA id y44sm9441124qtc.45.2016.12.18.18.55.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 18 Dec 2016 18:55:24 -0800 (PST) Sender: Mark Johnston Date: Sun, 18 Dec 2016 19:01:25 -0800 From: Mark Johnston To: Hiroki Sato Cc: freebsd-dtrace@freebsd.org Subject: Re: clause-local variable with copyin() Message-ID: <20161219030125.GB57753@wkstn-mjohnston.west.isilon.com> References: <20161217.151014.1579687141761225852.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161217.151014.1579687141761225852.hrs@allbsd.org> User-Agent: Mutt/1.7.2 (2016-11-26) X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 02:55:26 -0000 On Sat, Dec 17, 2016 at 03:10:14PM +0900, Hiroki Sato wrote: > Hi, > > I have trouble with clause-local variable. A minimum working example > is attached. The "sample" program simply displays a string in an > infinite loop with a USDT named as "dump-str", sample_debug.d does > copyin() and printf() the whole buffer assuming it is > nul-terminated: > > | sample$target:::dump-str > | { > | this->st = copyin(arg0, 1024); > | > | printf("(1)st = %s, %p\n", stringof(this->st), > | (char *)this->st); > | } > | sample$target:::dump-str > | { > | printf("(2)st = %s, %p\n", stringof(this->st), > | (char *)this->st); > | printf("(3)st = %s\n", stringof(copyin(arg0, 1024))); > | } > > The odd part is that it does not work with splitting the probe into > the two as above but works fine without the split. The result was as > follows: > > | % sudo make test > | dtrace -C -I/var/home/hrs/sample_str -s sample_debug.d -c /var/home/hrs/sample_str/sample > | dtrace: script 'sample_debug.d' matched 5 probes > | CPU ID FUNCTION:NAME > | 0 61714 main:dump-str (1)st = test-uname, fffffe0001a19118 > | > | 0 61714 main:dump-str (2)st = , fffffe0001a19118 > | (3)st = test-uname > > this->st became empty at the beginning of the second probe. > > The symptom varied depending on the address of this->st, so I am > guessing that this->st was incorrectly freed at the end of the first > probe. If I use copyinstr(arg0) instead of copyin(), this problem > does not occur. > > Do I misunderstand clause-local variable? I noticed this when I use > if-then clause which was recently implemented as a syntax sugar to > split a probe automatically. The following ended up with the same > result: I think this is more a quirk of copyin() than of clause-local variables. In particular: - your example works as expected if copyinstr() is used instead of copyin(), and - your example works if one assigns this->st = stringof(copyin(...)). copyin() and copyinstr() both copy data into a scratch buffer. However, copyinstr() returns a pass-by-reference string, while copyin() returns a pass-by-value pointer. The DIF instruction which saves to a clause-local variable, STLS, performs a deep copy of pass-by-reference variables to some dedicated storage. The scratch space containing the copyin()/copyinstr() is not preserved between enablings of the same probe, so the string copied during the first probe is not available in the second probe when copyin() is used.