From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: valgrind memcheck + drd error on alpine 3.6 container
Date: Tue, 20 Jun 2017 21:09:57 -0400 [thread overview]
Message-ID: <20170621010957.GD1627@brightrain.aerifal.cx> (raw)
In-Reply-To: <20170615082841.7c0e9c0e@vostro>
On Thu, Jun 15, 2017 at 08:28:41AM +0300, Timo Teras wrote:
> On Wed, 14 Jun 2017 20:16:26 -0400
> Rich Felker <dalias@libc.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.
I think that's a good idea, but I don't have it in front of me. It
does need to be checked very carefully for correctness though. I
remember there were subtle bugs in one version which is why I was
hesitant to go forward without time to spend checking it in detail.
Rich
prev parent reply other threads:[~2017-06-21 1:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-14 17:51 Eugenio Pérez
2017-06-15 0:16 ` Rich Felker
2017-06-15 5:28 ` Timo Teras
2017-06-15 7:55 ` Eugenio Pérez
2017-06-20 8:08 ` Eugenio Pérez
2017-06-21 1:11 ` Rich Felker
2017-06-21 1:09 ` Rich Felker [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170621010957.GD1627@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).