Mail archive
alpine-devel

Solved: Re: [musl][alpine-devel] Attempting to debug C++ library and command via valgrind

From: Isaac Dunham <ibid.ag_at_gmail.com>
Date: Fri, 11 Jul 2014 21:03:40 -0700

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:
<snip>
> > > 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_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Fri Jul 11 2014 - 21:03:40 UTC