valgrind memcheck + drd error on alpine 3.6 container

valgrind memcheck + drd error on alpine 3.6 container

[Eugenio Pérez]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]

Hi, everyone!

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?

Thanks and regards!

[-- Attachment #2: Type: text/html, Size: 2878 bytes --]

Re: valgrind memcheck + drd error on alpine 3.6 container

[Rich Felker]

On Wed, Jun 14, 2017 at 07:51:30PM +0200, Eugenio Pérez wrote:
> Hi, everyone!
> 
> 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?
> 
> Thanks and regards!

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.

Rich

Re: valgrind memcheck + drd error on alpine 3.6 container

[Timo Teras]

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.

Timo

PS. What is the status of
http://www.openwall.com/lists/musl/2017/01/06/1 ?

Re: valgrind memcheck + drd error on alpine 3.6 container

[Eugenio Pérez]

[-- Attachment #1: Type: text/plain, Size: 4144 bytes --]

El 15/6/2017 7:28, "Timo Teras" <timo.teras@iki.fi> escribió:

> 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.
>
> Timo
>
> PS. What is the status of
> http://www.openwall.com/lists/musl/2017/01/06/1 ?
>

Hi Rich! Thanks for your response!

I can't even generate suppression file! it doesn't generate a suppression
for an assert that is in valgrind code (drd_malloc_wrappers.c:115 is a
valgrind file, not mine).

Thanks for your response, Timo! Should apply that patch solve the issue?
I'm starting with musl and I don't know how to link to it static in my
program

[-- Attachment #2: Type: text/html, Size: 5308 bytes --]

Re: valgrind memcheck + drd error on alpine 3.6 container

[Eugenio Pérez]

[-- Attachment #1: Type: text/plain, Size: 4753 bytes --]

Hi, all! any new on this?

I don;t know if I've been clear enough on this: it's NOT a suppressible
error. If I try to generate them with --gen-suppressions or something
similar, valgrind does not even reach the point where it can generate
suppressions. This limits a lot the use of musl (in my case) an alpine
docker container, since I can't test it with drd/helgrind. Can I collect
more data to fix it?

Thanks and regards.

2017-06-15 9:55 GMT+02:00 Eugenio Pérez <eupm90@gmail.com>:

>
> El 15/6/2017 7:28, "Timo Teras" <timo.teras@iki.fi> escribió:
>
>> 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.
>>
>> Timo
>>
>> PS. What is the status of
>> http://www.openwall.com/lists/musl/2017/01/06/1 ?
>>
>
> Hi Rich! Thanks for your response!
>
> I can't even generate suppression file! it doesn't generate a suppression
> for an assert that is in valgrind code (drd_malloc_wrappers.c:115 is a
> valgrind file, not mine).
>
> Thanks for your response, Timo! Should apply that patch solve the issue?
> I'm starting with musl and I don't know how to link to it static in my
> program
>

[-- Attachment #2: Type: text/html, Size: 6218 bytes --]

Re: valgrind memcheck + drd error on alpine 3.6 container

[Rich Felker]

On Thu, Jun 15, 2017 at 09:55:20AM +0200, Eugenio Pérez wrote:
> El 15/6/2017 7:28, "Timo Teras" <timo.teras@iki.fi> escribió:
> 
> > 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.
> >
> > Timo
> >
> > PS. What is the status of
> > http://www.openwall.com/lists/musl/2017/01/06/1 ?
> >
> 
> Hi Rich! Thanks for your response!
> 
> I can't even generate suppression file! it doesn't generate a suppression
> for an assert that is in valgrind code (drd_malloc_wrappers.c:115 is a
> valgrind file, not mine).
> 
> Thanks for your response, Timo! Should apply that patch solve the issue?
> I'm starting with musl and I don't know how to link to it static in my
> program

In that case I think we should do as Timo suggested, if it
successfully makes the problem go away.

Rich

Re: valgrind memcheck + drd error on alpine 3.6 container

[Rich Felker]

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