X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mail.alpinelinux.org (Postfix) with ESMTPS id EA254DC00CA for ; Sat, 12 Jul 2014 04:03:44 +0000 (UTC) Received: by mail-pd0-f181.google.com with SMTP id v10so2356230pde.26 for ; Fri, 11 Jul 2014 21:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Ulyz0s7lU6oavShugDxVTphJQFA3WkBrOxkj5ktCL28=; b=xNEWRtJSpgc2hZOMfeFSFI39aSUoJFB9Eoxh+RqodwdTXCaO/X9rWY780YV+rntIvF rViMAdmdXcfz03AqBmNcG4DbKQWD+7XGdo+a6yTlV2CVcsVXvNn0kglF5pNxDkpK1XZr DZmuUHg0b1Cp7QLV7FyXSF3JusonBxEj4fEs9OvKE6qCaZjfiBS+sx9GEVGH2tkvKkMk Y8PDcmMez390iM8YBcbaPuvsEtA1wP1iZicwSBlKTP/Sie8hNsJQSE8a7VFIXl1km2Wj eLXr+2C2cb1LViGmSbgaRN8iGwx/JbFRt+4JKboZtOlUSEeXX0fMqoLHGAOLyzBAL3b4 jOWw== X-Received: by 10.68.164.67 with SMTP id yo3mr3055265pbb.104.1405137823808; Fri, 11 Jul 2014 21:03:43 -0700 (PDT) Received: from newbook ([50.0.227.219]) by mx.google.com with ESMTPSA id s6sm5134525pdl.32.2014.07.11.21.03.42 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Jul 2014 21:03:43 -0700 (PDT) Date: Fri, 11 Jul 2014 21:03:40 -0700 From: Isaac Dunham To: Rich Felker Cc: musl@lists.openwall.com, Alpine Subject: Solved: Re: [musl][alpine-devel] Attempting to debug C++ library and command via valgrind Message-ID: <20140712040339.GB1789@newbook> References: <20140709043946.GA1787@newbook> <20140710041348.GA4689@newbook> <20140710044716.GT179@brightrain.aerifal.cx> <20140710065006.GB4777@newbook> <20140711033933.GW179@brightrain.aerifal.cx> X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140711033933.GW179@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) Hello, Just so everyone knows, someone on the sword-devel list (the person who asked me for valgrind output) found and fixed the bug. Rich, thanks for mentioning strace; that ended up being the key. On Thu, Jul 10, 2014 at 11:39:34PM -0400, Rich Felker wrote: > On Wed, Jul 09, 2014 at 11:50:08PM -0700, Isaac Dunham wrote: > > On Thu, Jul 10, 2014 at 12:47:16AM -0400, Rich Felker wrote: > > > But I think you're getting ahead of things. What > > > actual failure is the program exhibiting? (Crash? Incorrect or no > > > output? Error messages?) Depending on what happens, a gdb backtrace or > > > an strace log may be more useful than the valgrind output. > > _llseek(3, 164840, [164840], SEEK_SET) = 0 > > read(3, "\23\0\0\0", 4) = 4 > > read(3, "\207\204\f\0", 4) = 4 > > read(3, "\34\1", 2) = 2 > > _llseek(3, 164850, [164850], SEEK_SET) = 0 > > read(3, "\23\0\0\0", 4) = 4 > > read(3, "\243\205\f\0", 4) = 4 > > read(3, "'\2", 2) = 2 > > _llseek(3, 164850, [164850], SEEK_SET) = 0 > > read(3, "\23\0\0\0", 4) = 4 > > read(3, "\243\205\f\0", 4) = 4 > > read(3, "'\2", 2) = 2 > > _llseek(3, 164850, [164850], SEEK_SET) = 0 > > read(3, "\23\0\0\0", 4) = 4 > > read(3, "\243\205\f\0", 4) = 4 > > read(3, "'\2", 2) = 2 > > munmap(0xb56af000, 1024000) = 0 > > munmap(0xb57a9000, 180224) = 0 > > munmap(0xb534d000, 1024000) = 0 > > close(4) = 0 > > close(5) = 0 > > close(3) = 0 > > writev(1, [{"Psalms 117:2: For his merciful k"..., 246}, {NULL, 0}], 2Psalms 117:2: For his merciful kindness is great toward us: and the truth of the LORD endureth for ever. Praise ye the LORD. > > : For his merciful kindness is great toward us: and the truth of the LORD endureth for ever. Praise ye the LORD. > > (KJV) > > ) = 246 > > > > Which looks like it's going through a loop twice when it reaches the exit condition. > > The fact that it's using writev suggests strongly that the output is > being written via musl's stdio (to stdout, since it's fd #1) rather > than via some other mechanism, but it could be C++ iostreams using > stdio as their backend. It's hard to say whether this is due to > corruption of the FILE state or the actual calling code writing the > output twice. It turned out to be the calling code reading the last verse twice; the closing curly braces were misplaced. Thanks, Isaac Dunham --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---