From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25328 invoked by alias); 29 Nov 2011 15:00:56 -0000 Received: (qmail 25320 invoked by uid 22791); 29 Nov 2011 15:00:55 -0000 X-SWARE-Spam-Status: No, hits=-0.9 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from lo.gmane.org (HELO lo.gmane.org) (80.91.229.12) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Nov 2011 15:00:42 +0000 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RVPAn-00032X-3M for systemtap@sources.redhat.com; Tue, 29 Nov 2011 16:00:41 +0100 Received: from wardy-en0.manor.fubra.net ([87.124.34.36]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Nov 2011 16:00:40 +0100 Received: from matthew.ward by wardy-en0.manor.fubra.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 29 Nov 2011 16:00:40 +0100 To: systemtap@sources.redhat.com From: Matthew Ward Subject: Re: usertap kernel read faults - can I ignore them somehow? Date: Tue, 29 Nov 2011 15:02:00 -0000 Message-ID: <4ED4F383.5030901@fubra.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: systemtap@sources.redhat.com User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0 In-Reply-To: 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: 2011-q4/txt/msg00237.txt.bz2 Message-ID: <20111129150200.EJc3VmAGWpAeEEA_hsEOuP-e9Q6OFCKeMeabxYbOIrM@z> On 29/11/2011 14:38, Frank Ch. Eigler wrote: > > Hi, Matthew - > >> I'm having an issue with our usertap tapset >> (https://github.com/fubralimited/usertap) [...] >> ERROR: kernel read fault at 0x0000000100000264 (addr) near identifier >> '@cast' at /usr/share/systemtap/tapset/ip.stp:45:11 > > You can do several things. > First, you can run "stap --skip-badvars ...", which turns all erroneous > $var accesses into 0. Second, you can (sometimes) wrap expressions with > try { var = $var } catch { } > to absorb the error. But see. > > - FChE > Thanks, that's exactly what I was looking for. When using the --skip-badvars option, if I'm running the tapset as a service using stapio, do I pass this to /usr/bin/stap when I build the original module (.ko) and this will apply whenever the module version is used by stapio etc. from then on? Matt.