[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170615082841.7c0e9c0e@vostro>
Date: Thu, 15 Jun 2017 08:28:41 +0300
From: Timo Teras <timo.teras@....fi>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com
Subject: Re: valgrind memcheck + drd error on alpine 3.6 container
On Wed, 14 Jun 2017 20:16:26 -0400
Rich Felker <dalias@...c.org> wrote:
> On Wed, Jun 14, 2017 at 07:51:30PM +0200, Eugenio Pérez wrote:
> > I'm having an issue trying to use valgrind drd in the simplest
> > musl-linked program (just return 0).
> >
> > drd refuses to even run main, and give me this error:
> >
> > ==24== drd, a thread error detector
> > ==24== Copyright (C) 2006-2015, and GNU GPL'd, by Bart Van Assche.
> > ==24== Using Valgrind-3.12.0 and LibVEX; rerun with -h for
> > copyright info ==24== Command: ./f2k
> > ==24==
> >
> > drd: drd_malloc_wrappers.c:115 (handle_free): Assertion 'success'
> > failed.
> >
> > host stacktrace:
> > ==24== at 0x3805EF1D: show_sched_status_wrk (m_libcassert.c:343)
> > ==24== by 0x3805F208: report_and_quit (m_libcassert.c:419)
> > ==24== by 0x3805F3E9: vgPlain_assert_fail (m_libcassert.c:485)
> > ==24== by 0x38057635: handle_free (drd_malloc_wrappers.c:115)
> > ==24== by 0x380A51B9: do_client_request (scheduler.c:1861)
> > ==24== by 0x380A51B9: vgPlain_scheduler (scheduler.c:1425)
> > ==24== by 0x380B25DA: thread_wrapper (syswrap-linux.c:103)
> > ==24== by 0x380B25DA: run_a_thread_NORETURN (syswrap-linux.c:156)
> >
> > sched status:
> > running_tid=1
> >
> > Thread 1: status = VgTs_Runnable (lwpid 24)
> > ==24== at 0x4C96951: free (vg_replace_malloc.c:530)
> > ==24== by 0x4057A19: ??? (in /lib/ld-musl-x86_64.so.1)
> >
> > I would like to compare it with glibc, but I'm unable to use it in
> > alpine linux properly. If it helps, memcheck gives me this error:
> >
> > ==163== Invalid free() / delete / delete[] / realloc()
> > ==163== at 0x4C939EA: free (vg_replace_malloc.c:530)
> > ==163== by 0x4057A19: ??? (in /lib/ld-musl-x86_64.so.1)
> > ==163== Address 0x4e9b180 is in a rw- mapped file
> > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so segment
> > ==163==
> > ==163==
> > ==163== HEAP SUMMARY:
> > ==163== in use at exit: 404 bytes in 1 blocks
> > ==163== total heap usage: 1 allocs, 1 frees, 404 bytes allocated
> > ==163==
> > ==163== 404 bytes in 1 blocks are still reachable in loss record 1
> > of 1 ==163== at 0x4C9461F: calloc (vg_replace_malloc.c:711)
> > ==163== by 0x4058B45: ??? (in /lib/ld-musl-x86_64.so.1)
> > ==163== by 0x4059774: __dls3 (in /lib/ld-musl-x86_64.so.1)
> > ==163== by 0xFFF000CB7: ???
> > ==163== by 0xFFF000D27: ???
> > ==163==
> > ==163== LEAK SUMMARY:
> > ==163== definitely lost: 0 bytes in 0 blocks
> > ==163== indirectly lost: 0 bytes in 0 blocks
> > ==163== possibly lost: 0 bytes in 0 blocks
> > ==163== still reachable: 404 bytes in 1 blocks
> > ==163== suppressed: 0 bytes in 0 blocks
> >
> > And that is before even reach main() function! However, memchecks
> > continue after error; drd does not. ¿What could I do to keep
> > diagnosing this error?
>
> It's not an error, just lack of a suppressions file. You can ignore it
> or figure out how to write the suppressions file, or get one from
> somewhere (maybe a distro) that's already done it for musl.
Could you please re-consider applying the patch that moves the "donate
memory" part to malloc.c, and stops misusing free() like this. It
really helps readability, maintainability and modularity to not
hardcode malloc internals in dynlink.c. I think I had sent a patch for
this in IRC, but could not found it immediately.
Timo
PS. What is the status of
http://www.openwall.com/lists/musl/2017/01/06/1 ?
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
