From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12793 invoked by alias); 8 Apr 2010 17:06:49 -0000 Received: (qmail 12644 invoked by uid 22791); 8 Apr 2010 17:06:48 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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, 08 Apr 2010 17:06:43 +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 o38H6fBa023374 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 8 Apr 2010 13:06:41 -0400 Received: from fche.csb (vpn-235-68.phx2.redhat.com [10.3.235.68]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o38H6egf013066; Thu, 8 Apr 2010 13:06:41 -0400 Received: by fche.csb (Postfix, from userid 2569) id 1091258132; Thu, 8 Apr 2010 13:06:40 -0400 (EDT) Date: Thu, 08 Apr 2010 17:06:00 -0000 From: "Frank Ch. Eigler" To: Karl Hiramoto Cc: systemtap@sourceware.org Subject: Re: ERROR: Build-id mismatch: "kernel" vs. "vmlinux" byte 0 (0x00 vs 0x00) Message-ID: <20100408170639.GB28054@redhat.com> References: <4BBCB7AE.8050603@hiramoto.org> <4BBD7BC0.5060009@hiramoto.org> <20100408145533.GA28054@redhat.com> <4BBE073E.7020602@hiramoto.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BBE073E.7020602@hiramoto.org> User-Agent: Mutt/1.4.2.2i 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: 2010-q2/txt/msg00066.txt.bz2 Hi - > >-14 is -EFAULT. This should not happen unless our address > >calculations have gotten messed up somehow. Try rerunning stap with > >-DDEBUG_TRANS -DDEBUG_SYMBOLS. > Here are full logs with " stap --vp 9999 -DDEBUG_TRANS -DDEBUG_SYMBOLS" > The working dropwatch: > http://karl.hiramoto.org/temp/stap_dropwatch.txt > The non working tcp_trace > http://karl.hiramoto.org/temp/stap_tcp_trace.txt Thanks. The difference is that dropwatch uses tracepoints only, and does not rely on kernel symbol/debug data. That in turn means that stap does not emit build-id-checking code. A better test would be to vary kernel version and/or systemtap version, but running with the same script. (Even a simple one like probe kernel.function("sys_open"){} should show the problem.) I'm building myself a 2.6.34-rc3 kernel to see if something became broken lately. > there's also some errors like: > [...] > /tmp/stapEyVbEM/stapconf_6415a8d55b7118f55f4e4a8368ac8512_390.h > /usr/share/systemtap/runtime/autoconf-grsecurity.c: In function foo: > /usr/share/systemtap/runtime/autoconf-grsecurity.c:10: error: struct > module) has no member namedi~init_size_ > [...] That's OK, runtime/autoconf-* bits are meant to detect kernel characteristics by compilation success / failures. - FChE