valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] POSIX pthread counter (integer) overflow in valgrind drd_vc.c

[Julian S. <js...@ac...>]

 > drd: drd_vc.c:96 (vgDrd_vc_increment): Assertion 'oldcount <
 > vc->vc[i].count' failed.

I suspect (I don't know for sure) that this is a vector clock overflow.
That might happen if your program performed more that 2^32 inter-thread
synchronisation events, for example, mutex lock, unlock, condvar posts
or signals, sem post/wait, thread create/join, etc.  Is that likely?

Can you reduce the problem size (to perhaps a few hundred thousand records)
and see if the failure goes away?

 > I don't understand what the semantics of the thread counter "count" is [..]

I suspect that is incremented every time one of the abovementioned thread
events happens.  The mechanism is a bit complex, but a counter overflow could
happen if there is a chain of such thread events (possibly involving multiple
threads) that is more than 2^32 long.

J

Re: [Valgrind-users] POSIX pthread counter (integer) overflow in valgrind drd_vc.c

[John R. <jr...@bi...>]

> |drd: drd_vc.c:96 (vgDrd_vc_increment): Assertion 'oldcount < vc->vc[i].count' failed.
> My program was running a quite large volume of data (millions of records).

How many millions, and how long does the program run, both with an without drd?
It's quite possible to overflow the 'count', which is an unsigned 32-bit integer
(see drd/drd_vc.h.)  That's only 4300 times one million; I would not be surprised
by an overflow in one day of execution.

What version of drd?  (Run "valgrind --version".)
The drd addresses in the traceback are 0x38000000; current drd uses 0x58000000.
The other versions that you specified are somewhat old: gcc-4.8 (current is gcc-9.1)
and Linux 4.4.76 built 2017-07-14 (almost 2 years ago).

[Valgrind-users] POSIX pthread counter (integer) overflow in valgrind drd_vc.c

[Kevin Xu <kx...@gm...>]

Hi,

I used "valgrind --tool=drd …" to debug my POSIX pthread based program in
C. Valgrind detected an error and terminated a thread with the following
error message:

drd: drd_vc.c:96 (vgDrd_vc_increment): Assertion 'oldcount <
vc->vc[i].count' failed.

host stacktrace:
==27993==    at 0x38025C68: ??? (in /usr/lib64/valgrind/drd-amd64-linux)
==27993==    by 0x38025D94: ??? (in /usr/lib64/valgrind/drd-amd64-linux)
==27993==    by 0x38025F21: ??? (in /usr/lib64/valgrind/drd-amd64-linux)
==27993==    by 0x38018317: ??? (in /usr/lib64/valgrind/drd-amd64-linux)
==27993==    by 0x380183EC: ??? (in /usr/lib64/valgrind/drd-amd64-linux)
==27993==    by 0x380187FC: ??? (in /usr/lib64/valgrind/drd-amd64-linux)
==27993==    by 0x3801D87E: ??? (in /usr/lib64/valgrind/drd-amd64-linux)
==27993==    by 0x3800967A: ??? (in /usr/lib64/valgrind/drd-amd64-linux)
==27993==    by 0x3803DB80: ??? (in /usr/lib64/valgrind/drd-amd64-linux)
==27993==    by 0x38078BDF: ??? (in /usr/lib64/valgrind/drd-amd64-linux)
==27993==    by 0x3808742A: ??? (in /usr/lib64/valgrind/drd-amd64-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 27993)
==27993==    at 0x4C339D3: pthread_mutex_unlock (in
/usr/lib64/valgrind/vgpreload_drd-amd64-linux.so)
==27993==    by 0x47F671: lf_pthread_mutex_unlock (htab2.c:192)
==27993==    by 0x405194: prepare_to_read_n_go (ep3.c:805)
==27993==    by 0x4053C4: reading_begin (ep3.c:847)
==27993==    by 0x405CFF: start_file_loader (ep3.c:1062)
==27993==    by 0x405D4E: start_services (ep3.c:1076)
==27993==    by 0x406743: init_procs (ep3.c:1295)
==27993==    by 0x40336B: main (ep.c:89)

In the program source code, the system call "pthread_mutex_unlock" in
"lf_pthread_mutex_unlock" was the last statement executed before the
termination. I am using OpenSuse wrapped with "Linux linux 4.4.76-1-default
#1 SMP Fri Jul 14 08:48:13 UTC 2017 (9a2885c) x86_64 x86_64 x86_64
GNU/Linux". The compiler is gcc-4.8.

I located the source code in drd_vc.c:

/** Increment the clock of thread 'tid' in vector clock 'vc'. */
void DRD_(vc_increment)(VectorClock* const vc, DrdThreadId const tid)
{
   unsigned i;
   for (i = 0; i < vc->size; i++)
   {
      if (vc->vc[i].threadid == tid)
      {
         typeof(vc->vc[i].count) const oldcount = vc->vc[i].count;
         vc->vc[i].count++;
         // Check for integer overflow.
         tl_assert(oldcount < vc->vc[i].count);
         return;
      }
   }
   …
}

where the statement "tl_assert(oldcount < vc->vc[i].count);" was the break
point.

I don't understand what the semantics of the thread counter "count" is and
how it was overflowed with my program. My program was running a quite large
volume of data (millions of records). I changed my program with different
numbers of variables and noted the error occurred consistently. Therefore I
guess the error was not caused by a memory overwrite.

Any information about the nature of the source code drd_vc.c would be
greatly appreciated. Thank you.

Note that the same question was posted in
https://stackoverflow.com/questions/56453500/posix-pthread-counter-integer-overflow-in-valgrind-drd-vc-c

Kevin

Re: [Valgrind-users] How to use valgrind in openembedded-core

[Philippe W. <phi...@sk...>]

First http://www.valgrind.org/docs/manual/QuickStart.html
Then http://www.valgrind.org/docs/manual/manual.html

(or the same doc in the valgrind you compiled)

Philippe

On Thu, 2019-05-30 at 21:36 +0530, subhasish Karmakar wrote:
> Hi,
> 
> I have compiled valgrind for ARM64 based target using bitbake recipe.
> Below list of executable are generated.
> Please let me know, how can I use them to debug memory leaks of my native apps.
> 
> -------------------------------------------------
> callgrind_annotate
> callgrind_control
> cg_annotate
> cg_diff
> cg_merge
> ms_print
> valgrind
> valgrind-di-server
> valgrind-listener
> vgdb
> -------------------------------------------------
> 
> Thanking you,
> Subhasish
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] How to use valgrind in openembedded-core

[subhasish K. <sub...@gm...>]

Hi,

I have compiled valgrind for ARM64 based target using bitbake recipe.
Below list of executable are generated.
Please let me know, how can I use them to debug memory leaks of my native
apps.

-------------------------------------------------
callgrind_annotate
callgrind_control
cg_annotate
cg_diff
cg_merge
ms_print
valgrind
valgrind-di-server
valgrind-listener
vgdb
-------------------------------------------------

Thanking you,
Subhasish

[Valgrind-users] How we do valgrind error log aggregation

[Samy Al B. <sb...@ba...>]

Hi all,

Wanted to share something with you that we’ve built over the last few weeks
and have been using with great success in our environments. We use a
combination of memory sanitizers here at Backtrace, including valgrind.

The issues we faced were:
1. It’s quite difficult to aggregate the errors and feed them into our
engineering workflows
2. It’s quite easy to miss the fact that you might have introduced a new
non-benign leak or memory error.
3. No automation around creation of tickets.
4. No deduplication of call sites across reports.

Details for all of this are up in
https://engineering.backtrace.io/posts/sanitizers/ - essentially, all you
have to do is HTTPS POST / curl your valgrind logs into a server and it
will aggregate the data for you in a more actionable way. You can also
drill down into the raw logs of an individual error.

I set up a seeded environment with an example from our test corpus (mix of
real world applications and synthetic) up at
https://sanitizers.sp.backtrace.io/p/valgrind/triage (username: sanitizers
/ password: appleorangewat1). If you click on the “Saved Views” button
(left-most icon on the top right) then “All”, you can see some example
views we found particularly useful here, especially when triaging leaks.

Currently, I’ve only added support for XML protocol version 4 and memcheck,
but if folks find this useful for other tools, please let me know and I’m
happy to add support! Lastly, feedback is greatly appreciated.

Hope others find this useful as well.

Regards.
--
Samy Al Bahra
CTO / Co-Founder
Backtrace [https://backtrace.io]

Re: [Valgrind-users] identifying possible leak

[Filippo M. <in...@gm...>]

> Hi,
>
> thanks for the reply. I am using version 3.14. As for the other leaks,
> they are all 'still reachable' and that was the only error reported by
> valgrind. Should take actions to avoid also the 'still reachable' leaks?
> Thnaks for the help I am new to valgrind and, as it is becoming quite
> helpful in my projects, I would like to correctly interpret its reports.
>
> Regards,
> Filippo
>
> On Mon, May 13, 2019, 11:49 PM John Reiser <jr...@bi...> wrote:
>
>> > =16595== 1,008 bytes in 3 blocks are possibly lost in loss record 155
>> of 1,524
>> > ==16595==    at 0x483AB65: calloc (vg_replace_malloc.c:752)
>> > ==16595==    by 0x4012A32: allocate_dtv (in /usr/lib/ld-2.29.so <
>> http://ld-2.29.so>)
>> > ==16595==    by 0x40133E1: _dl_allocate_tls (in /usr/lib/ld-2.29.so <
>> http://ld-2.29.so>)
>>
>> Anything allocated by a routine which is part of the dynamic linker (such
>> as _dl_allocate_tls
>> in /usr/lib/ld-*.so) should be ignored.  The dynamic linker is well-known
>> to leak,
>> and some of those leaks essentially cannot be eliminated.  In any case,
>> you cannot do anything
>> about those leaks.  Besides, this leak is less than 340 bytes on average
>> (1008 / 3),
>> and there are either 154 or (1524 - 154) leaks which are more important
>> (larger).
>>
>> [Next time, please state the version of valgrind that you ran.]
>>
>>
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

Re: [Valgrind-users] identifying possible leak

[John R. <jr...@bi...>]

> =16595== 1,008 bytes in 3 blocks are possibly lost in loss record 155 of 1,524
> ==16595==    at 0x483AB65: calloc (vg_replace_malloc.c:752)
> ==16595==    by 0x4012A32: allocate_dtv (in /usr/lib/ld-2.29.so <http://ld-2.29.so>)
> ==16595==    by 0x40133E1: _dl_allocate_tls (in /usr/lib/ld-2.29.so <http://ld-2.29.so>)

Anything allocated by a routine which is part of the dynamic linker (such as _dl_allocate_tls
in /usr/lib/ld-*.so) should be ignored.  The dynamic linker is well-known to leak,
and some of those leaks essentially cannot be eliminated.  In any case, you cannot do anything
about those leaks.  Besides, this leak is less than 340 bytes on average (1008 / 3),
and there are either 154 or (1524 - 154) leaks which are more important (larger).

[Next time, please state the version of valgrind that you ran.]

[Valgrind-users] identifying possible leak

[Filippo M. <in...@gm...>]

Hi all,

I have been struggling over the last two days at undertanding the folloing
error message from valgrind. Some help would be really appreacited. I am
working with Fortran 90. In the following you can find the error message
and the subroutine probably responsible for it. Thank you in advance.

Regards,
Filippo

=16595== 1,008 bytes in 3 blocks are possibly lost in loss record 155 of
1,524
==16595==    at 0x483AB65: calloc (vg_replace_malloc.c:752)
==16595==    by 0x4012A32: allocate_dtv (in /usr/lib/ld-2.29.so)
==16595==    by 0x40133E1: _dl_allocate_tls (in /usr/lib/ld-2.29.so)
==16595==    by 0x4CD7698: pthread_create@@GLIBC_2.2.5 (in /usr/lib/
libpthread-2.29.so)
==16595==    by 0x6C6A09A: gomp_team_start (team.c:817)
==16595==    by 0x6C60F9D: GOMP_parallel (parallel.c:167)
==16595==    by 0x5149742: exec_blas (in /usr/lib/libopenblasp-r0.3.5.so)
==16595==    by 0x5149B75: blas_level1_thread_with_return_value (in
/usr/lib/libopenblasp-r0.3.5.so)
==16595==    by 0x56BCE6A: ddot_k_SANDYBRIDGE (in /usr/lib/
libopenblasp-r0.3.5.so)
==16595==    by 0x4A5CC97: dqrdc2_ (in /usr/lib/R/lib/libR.so)
==16595==    by 0x4A5D66D: dqrls_ (in /usr/lib/R/lib/libR.so)
==16595==    by 0x14E5F7CC: ??? (in /usr/lib/R/library/stats/libs/stats.so)

 subroutine linreg_se1__evl (glmid)
    implicit none
    integer, intent(in) :: glmid
    double precision, allocatable :: A(:,:), B(:,:), sigma(:)
    double precision :: lnD
    integer :: i, j, xi, wi, sei, l, m, n, info
    xi = GLMLIST_(glmid)%Mi(glm_x1i_,1)
    wi = GLMLIST_(glmid)%Mi(glm_wi_,1)
    l = GLMLIST_(glmid)%Mi(glm_l_,1)
    m = GLMLIST_(glmid)%Mi(glm_m_,1) !number of features
    n = GLMLIST_(glmid)%Mi(glm_n_,1) !number of outputs
    sei = GLMLIST_(glmid)%Mi(glm_se1i_,1)
    print *, l, m, n
    allocate(A(m,m))
    A = 0
    allocate(B(l,m))
    B = MATLIST_dbl(xi)%Mi
    allocate(sigma(n))
    sigma = 0

    call sbr_multRows(B, MATLIST_dbl(wi)%Mi(:,1))
    call wrp_dgemm('T', 'N', dble(1), MATLIST_dbl(xi)%Mi, B, dble(0), A)

    call invSym(A, lnD, info)

    if (info /= 0) print *, 'error not PD'
    call wrp_dsymm('R', 'U', dble(1), A, MATLIST_dbl(xi)%Mi, dble(0), B)
    call uvrv__get(sigma, GLMHPLIST_(glmid)%Mi((m+1):(m+n),1), uvrv_vali_)
    do i = 1, n
       do j = 1, l
          MATLIST_dbl(sei)%Mi(j,i) = sum(B(j,:) * MATLIST_dbl(xi)%Mi(j,:))
+ MATLIST_dbl(wi)%Mi(j,1)**(-1)
          MATLIST_dbl(sei)%Mi(j,i) = (MATLIST_dbl(sei)%Mi(j,i) *
sigma(i)**2)**0.5
       end do
    end do
  end subroutine linreg_se1__evl

Re: [Valgrind-users] Master and -Wformat-overflow warning

[Mark W. <ma...@kl...>]

Hi Jeffrey,

On Thu, May 02, 2019 at 12:46:30PM -0400, Jeffrey Walton wrote:
> On Thu, May 2, 2019 at 12:02 PM Mark Wielaard <ma...@kl...> wrote:
> >
> > On Tue, 2019-04-30 at 20:43 -0400, Jeffrey Walton wrote:
> > > It looks like GCC has one squawk:
> > >
> > > vgdb.c: In function ‘standalone_send_commands’:
> > > vgdb.c:1008:21: warning: ‘%02x’ directive writing between 2 and 8
> > > bytes into a r
> > > egion of size 3 [-Wformat-overflow=]
> > >        sprintf(hex, "%02x", cksum);
> > >                      ^~~~
> > > vgdb.c:1008:20: note: directive argument in the range [0, 2147483647]
> > >        sprintf(hex, "%02x", cksum);
> > >                     ^~~~~~
> >
> > But cksum is an unsigned char, so value is be between [0, 255]. Which
> > is max 2 hex chars.
> >
> > Could you retry with GCC8 or GCC9?
> > And file a bug against GCC otherwise?
> 
> If Valgrind is interested in working around it without increasing the
> buffer size, then the format string "%.2x" should do the trick.

Although I appreciate having zero warning builds, I do believe this
should be filed and tracked in gcc. Or better understood why the
warning is triggering for you. I have been unable to trigger the
warning with GCC 7.3.1 on either amd64 or i686. So I am wondering if
it is somehow arm specific? (Does arm have signed or unsigned char by
default? Does that matter?) Also the fact that it does trigger with
"%02x", but not "%.2x" is suspecious IMHO. Both should indicate that
the value is at least 2 chars, but maybe more. So why does one trigger
the warning, but not the other?

> $ cat test.c
> #include

Missing stdio.h ?

> int main(int argc, char* argv[])
> {
>     char buf[3];
>     sprintf(buf, "%.2x", (unsigned char)argc);
>     printf("%s\n", buf);
>     return 0;
> }
> 
> And:
> 
> $ gcc -Wall -Wformat-overflow=2 test.c -o test.exe

And I assume on your system this produces a warning replacing '.' with
'0'?  I have been unable to trigger the warning with GCC 7.3.1 and GCC
8.2.1 (on x86_64 with or without -m32). So I wonder where/when it does
trigger.

Cheers,

Mark

Re: [Valgrind-users] Master and -Wformat-overflow warning

[Jeffrey W. <nol...@gm...>]

On Thu, May 2, 2019 at 12:02 PM Mark Wielaard <ma...@kl...> wrote:
>
> On Tue, 2019-04-30 at 20:43 -0400, Jeffrey Walton wrote:
> > It looks like GCC has one squawk:
> >
> > vgdb.c: In function ‘standalone_send_commands’:
> > vgdb.c:1008:21: warning: ‘%02x’ directive writing between 2 and 8
> > bytes into a r
> > egion of size 3 [-Wformat-overflow=]
> >        sprintf(hex, "%02x", cksum);
> >                      ^~~~
> > vgdb.c:1008:20: note: directive argument in the range [0, 2147483647]
> >        sprintf(hex, "%02x", cksum);
> >                     ^~~~~~
>
> But cksum is an unsigned char, so value is be between [0, 255]. Which
> is max 2 hex chars.
>
> Could you retry with GCC8 or GCC9?
> And file a bug against GCC otherwise?

If Valgrind is interested in working around it without increasing the
buffer size, then the format string "%.2x" should do the trick.

$ cat test.c
#include
int main(int argc, char* argv[])
{
    char buf[3];
    sprintf(buf, "%.2x", (unsigned char)argc);
    printf("%s\n", buf);
    return 0;
}

And:

$ gcc -Wall -Wformat-overflow=2 test.c -o test.exe
$ ./test.exe a b c d
05
$ ./test.exe a b c d e f g h i
0a
$ ./test.exe a b c d e f g h i j k l m n o p q r s t u v w x y z
1b

Re: [Valgrind-users] Master and -Wformat-overflow warning

[Jeffrey W. <nol...@gm...>]

On Thu, May 2, 2019 at 12:06 PM Jeffrey Walton <nol...@gm...> wrote:
>
>  ...
> > > vgdb.c:1008:20: note: directive argument in the range [0, 2147483647]
> > >        sprintf(hex, "%02x", cksum);
> > >                     ^~~~~~
> >
> > But cksum is an unsigned char, so value is be between [0, 255]. Which
> > is max 2 hex chars.
> >
> > Could you retry with GCC8 or GCC9?
> > And file a bug against GCC otherwise?
>
> I thought it might be something like that.
>
> I believe the char get promoted to an int for printf since it is
> variadic. Maybe it would just be easier to workaround the finding by
> making the buffer larger to accommodate an int.
>
> Its not Valgrind's problem to be sure. Valgrind is just
> working/playing nice with other tools.

Yeah, there were some warnings about potential false positives:

* https://gcc.gnu.org/onlinedocs/gcc-8.1.0/gcc/Warning-Options.html
* https://developers.redhat.com/blog/2017/02/22/memory-error-detection-using-gcc/

It looks like the issue has already been raised at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79257.

Jeff

Re: [Valgrind-users] Master and -Wformat-overflow warning

[Jeffrey W. <nol...@gm...>]

On Thu, May 2, 2019 at 12:02 PM Mark Wielaard <ma...@kl...> wrote:
>
> Hi Jeffrey,
>
> On Tue, 2019-04-30 at 20:43 -0400, Jeffrey Walton wrote:
> > It looks like GCC has one squawk:
> >
> > vgdb.c: In function ‘standalone_send_commands’:
> > vgdb.c:1008:21: warning: ‘%02x’ directive writing between 2 and 8
> > bytes into a r
> > egion of size 3 [-Wformat-overflow=]
> >        sprintf(hex, "%02x", cksum);
> >                      ^~~~
> > vgdb.c:1008:20: note: directive argument in the range [0, 2147483647]
> >        sprintf(hex, "%02x", cksum);
> >                     ^~~~~~
>
> But cksum is an unsigned char, so value is be between [0, 255]. Which
> is max 2 hex chars.
>
> Could you retry with GCC8 or GCC9?
> And file a bug against GCC otherwise?

I thought it might be something like that.

I believe the char get promoted to an int for printf since it is
variadic. Maybe it would just be easier to workaround the finding by
making the buffer larger to accommodate an int.

Its not Valgrind's problem to be sure. Valgrind is just
working/playing nice with other tools.

Jeff

.

Re: [Valgrind-users] Master and -Wformat-overflow warning

[Tom H. <to...@co...>]

On 02/05/2019 17:02, Mark Wielaard wrote:
> Hi Jeffrey,
> 
> On Tue, 2019-04-30 at 20:43 -0400, Jeffrey Walton wrote:
>> It looks like GCC has one squawk:
>>
>> vgdb.c: In function ‘standalone_send_commands’:
>> vgdb.c:1008:21: warning: ‘%02x’ directive writing between 2 and 8
>> bytes into a r
>> egion of size 3 [-Wformat-overflow=]
>>         sprintf(hex, "%02x", cksum);
>>                       ^~~~
>> vgdb.c:1008:20: note: directive argument in the range [0, 2147483647]
>>         sprintf(hex, "%02x", cksum);
>>                      ^~~~~~
> 
> But cksum is an unsigned char, so value is be between [0, 255]. Which
> is max 2 hex chars.

It is, but it is technically promoted to int by being passed
to a varargs function I think...

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Master and -Wformat-overflow warning

[Mark W. <ma...@kl...>]

Hi Jeffrey,

On Tue, 2019-04-30 at 20:43 -0400, Jeffrey Walton wrote:
> It looks like GCC has one squawk:
> 
> vgdb.c: In function ‘standalone_send_commands’:
> vgdb.c:1008:21: warning: ‘%02x’ directive writing between 2 and 8
> bytes into a r
> egion of size 3 [-Wformat-overflow=]
>        sprintf(hex, "%02x", cksum);
>                      ^~~~
> vgdb.c:1008:20: note: directive argument in the range [0, 2147483647]
>        sprintf(hex, "%02x", cksum);
>                     ^~~~~~

But cksum is an unsigned char, so value is be between [0, 255]. Which
is max 2 hex chars.

Could you retry with GCC8 or GCC9?
And file a bug against GCC otherwise?

Thanks,

Mark

[Valgrind-users] Master and -Wformat-overflow warning

[Jeffrey W. <nol...@gm...>]

Hi Everyone,

I'm building Master on an ARM Cortex A7 dev-board with GCC 7.4.0.

It looks like GCC has one squawk:

gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../include -I../VEX/pub -I../V
EX/pub -DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_vanilla=1  -
I../coregrind -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DVG_PLATFORM="\"arm-lin
ux\"" -g2 -O3  -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstri
ct-prototypes -Wmissing-declarations -Wcast-qual -Wwrite-strings -Wempty-body -W
format -Wformat-signedness -Wformat-security -Wignored-qualifiers -Wmissing-para
meter-type -Wlogical-op -Wimplicit-fallthrough=2 -Wold-style-declaration -finlin
e-functions -fno-stack-protector -fno-strict-aliasing -fno-builtin  -marm -mcpu=
cortex-a8 -DENABLE_LINUX_TICKET_LOCK -g2 -O3 -MT m_aspacemgr/libcoregrind_arm_li
nux_a-aspacemgr-segnames.o -MD -MP -MF m_aspacemgr/.deps/libcoregrind_arm_linux_
a-aspacemgr-segnames.Tpo -c -o m_aspacemgr/libcoregrind_arm_linux_a-aspacemgr-se
gnames.o `test -f 'm_aspacemgr/aspacemgr-segnames.c' || echo './'`m_aspacemgr/as
pacemgr-segnames.c
vgdb.c: In function ‘standalone_send_commands’:
vgdb.c:1008:21: warning: ‘%02x’ directive writing between 2 and 8 bytes into a r
egion of size 3 [-Wformat-overflow=]
       sprintf(hex, "%02x", cksum);
                     ^~~~
vgdb.c:1008:20: note: directive argument in the range [0, 2147483647]
       sprintf(hex, "%02x", cksum);
                    ^~~~~~
In file included from /usr/include/stdio.h:862:0,
                 from vgdb.c:42:
/usr/include/arm-linux-gnueabihf/bits/stdio2.h:33:10: note: ‘__builtin___sprintf
_chk’ output between 3 and 9 bytes into a destination of size 3
   return __builtin___sprintf_chk (__s, __USE_FORTIFY_LEVEL - 1,
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       __bos (__s), __fmt, __va_arg_pack ());
       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
mv -f m_aspacemgr/.deps/libcoregrind_arm_linux_a-aspacemgr-segnames.Tpo m_aspace
mgr/.deps/libcoregrind_arm_linux_a-aspacemgr-segnames.Po

Jeff

Re: [Valgrind-users] 答复: Some question about linker dlopen with valgrind

[John R. <jr...@bi...>]

On 4/24/2019 0128 UTC, Wuweijia wrote:
> Android Q
> 
> The libc  source  as below:

The purpose of a test case is to reproduce the problem.  What you wrote fails badly.
It does not compile, under ANY compiler: functions are used before they are declared.
It does not have the necessary #include statements.
It is not written in C language.  'reinterpret_cast' is C++.
It is not standard C++.  __has_builtin() (from Android #include) is only in the 'clang' dialect.
It uses symbols that start with underscore ('_') without understanding what it is doing.
They're written with a leading underscore to warn you that you should not touch them.

You should have said:
    git clone https://android.googlesource.com/platform/bionic/
    git clone https://android.googlesource.com/platform/system/core

===== test-libc.cpp
#include <dlfcn.h>
#include <stdio.h>
#include <stdint.h>
#include <private/bionic_ssp.h>
#include <private/__get_tls.h>
#include <private/bionic_asm_tls.h>
#include <private/bionic_globals.h>
#include <bionic/libc_init_common.h>


static void TestInitImpl() {
         printf("%s enter\n", __func__);
//-----------This is most important  call,  If call  dlopen success, and then malloc trace is not available now; If Not success, the malloc trace is okay;
         void * handle = dlopen("liblog.so",  RTLD_NOW );
         printf("handle:%p\n", handle);
}

__attribute__((noinline))
static void __libc_preinit_impl() {
   // Register libc.so's copy of the TLS generation variable so the linker can
   // update it when it loads or unloads a shared object.
   TlsModules& tls_modules = __libc_shared_globals()->tls_modules;
   tls_modules.generation_libc_so = &__libc_tls_generation_copy;
   __libc_tls_generation_copy = tls_modules.generation;

   __libc_init_globals();
   __libc_init_common();
	
   // Hooks for various libraries to let them know that we're starting up.
      TestInitImpl();
}

__attribute__((constructor(1))) static void __libc_preinit() {
   // The linker has initialized its copy of the global stack_chk_guard, and filled in the main
   // thread's TLS slot with that value. Initialize the local global stack guard with its value.
   __stack_chk_guard = reinterpret_cast<uintptr_t>(__get_tls()[TLS_SLOT_STACK_GUARD]);

   __libc_preinit_impl();
}
=====

export ADIR=$PWD  # after "git clone" above
# -I list: Android source is crap.
test-libc.so: test-libc.cpp
	clang++ -shared -fPIC -g -nostdinc \
	  -I$(ADIR)/bionic/libc/include \
	  -I$(ADIR)/bionic/libc \
	  -I$(ADIR)/bionic/libc/async_safe/include \
	  -I$(ADIR)/core/liblog/include \
	  -I/usr/lib/gcc/x86_64-redhat-linux/8/include \
	  -I/usr/include \
	  $< -o $@
=====


 >          void * handle = dlopen("liblog.so",  RTLD_NOW );  -----------This is most important  call,  If call  dlopen success, and then malloc trace is not available now; If Not success, the malloc trace is okay;

So calling dlopen() while still in the initialization phase of the run-time linker,
causes trouble for valgrind.  Get the source, apply a debugger, and find out why.

Calling dlopen() from a DT_INIT, DT_INIT_ARRAY, or DT_PREINIT_ARRAY function
is a design error: the run-time linker makes NO guarantees about what happens.

[Valgrind-users] I found some text, need to confirm .. //答复: 答复: Some question about linker dlopen with valgrind

[Wuweijia <wuw...@hu...>]

localhost:/system/bin #  ./valgrind -v --undef-value-errors=no    ./test64
MallocInitImpl enter
handle:0xd0a1699ce22c0e09
==8142== Memcheck, a memory error detector
==8142== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==8142== Using Valgrind-3.14.0-353a3587bb-20181007X and LibVEX; rerun with -h for copyright info
==8142== Command: ./test64
==8142==
--8142-- Valgrind options:
--8142--    -v
--8142--    --undef-value-errors=no
--8142-- Contents of /proc/version:
--8142--   Linux version 4.4.7+ (root@baixin-HP-Compaq-8200-Elite-MT-PC) (gcc version 4.9.3 20151223 (prerelease) (SDK V100R005C00SPC030B080) ) #1 SMP PREEMPT Fri Sep 9 14:57:05 CST 2016
--8142--
--8142-- Arch and hwcaps: ARM64, LittleEndian, baseline
--8142-- Page sizes: currently 4096, max supported 65536
--8142-- Valgrind library directory: /system/lib64/valgrind
--8142-- Reading syms from /system_Q_EA3/bin/test64
--8142-- Reading syms from /system_Q_EA3/bin/linker64
--8142-- Reading syms from /system_Q_EA3/lib64/valgrind/memcheck-arm64-linux
--8142--    object doesn't have a dynamic symbol table
--8142-- Scheduler: using generic scheduler lock implementation.
--8142-- Reading suppressions file: /system/lib64/valgrind/default.supp
--8142-- Reading syms from /system_Q_EA3/lib64/libc_xom.so
--8142-- Reading syms from /system_Q_EA3/lib64/libm.so
--8142-- Reading syms from /system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so
--8142-- warning: DiCfSI 0x5a5f000 .. 0x5a5f00b outside mapped rx segments (vgpreload_core-arm64-linux.so)
--8142-- warning: DiCfSI 0x5a5f00c .. 0x5a5f00f outside mapped rx segments (vgpreload_core-arm64-linux.so)
--8142-- warning: DiCfSI 0x5a5f010 .. 0x5a5f013 outside mapped rx segments (vgpreload_core-arm64-linux.so)
--8142-- warning: DiCfSI 0x5a5f014 .. 0x5a5f017 outside mapped rx segments (vgpreload_core-arm64-linux.so)
--8142-- warning: DiCfSI 0x5a5f018 .. 0x5a5f073 outside mapped rx segments (vgpreload_core-arm64-linux.so)
--8142-- warning: DiCfSI 0x5a5f074 .. 0x5a5f093 outside mapped rx segments (vgpreload_core-arm64-linux.so)
--8142-- warning: DiCfSI 0x5a5f094 .. 0x5a5f117 outside mapped rx segments (vgpreload_core-arm64-linux.so)
--8142-- Reading syms from /system_Q_EA3/lib64/libdl.so
--8142-- warning: DiCfSI 0x5a9a000 .. 0x5a9a007 outside mapped rx segments (libdl.so)
--8142-- warning: DiCfSI 0x5a9a008 .. 0x5a9a013 outside mapped rx segments (libdl.so)
--8142-- warning: DiCfSI 0x5a9a014 .. 0x5a9a01b outside mapped rx segments (libdl.so)
--8142-- Reading syms from /system_Q_EA3/lib64/libc++.so
--8142-- Reading syms from /system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so
==8142== Preferring higher priority redirection:
--8142--     old: 0x05b58180 (memcpy              ) R-> (2018.0) 0x06055a14 memcpy
--8142--     new: 0x05b58180 (memcpy              ) R-> (2018.1) 0x06057454 memmove
linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
--8142-- REDIR: 0x5b58240 (libc.so:memset) redirected to 0x6057324 (memset)
--8142-- REDIR: 0x5b58180 (libc.so:memcpy) redirected to 0x6057454 (memmove)
--8142-- REDIR: 0x5b1a32c (libc.so:malloc) redirected to 0x6059148 (malloc)
--8142-- REDIR: 0x5b58860 (libc.so:strlen) redirected to 0x60545a4 (strlen)
--8142-- REDIR: 0x5b58730 (libc.so:strcpy) redirected to 0x605464c (strcpy)
--8142-- REDIR: 0x5b57e00 (libc.so:memchr) redirected to 0x605544c (memchr)
MallocInitImpl enter
--8142-- REDIR: 0x5b1a2bc (libc.so:free) redirected to 0x605ab48 (free)
--8142-- Discarding syms at 0x6054000-0x605d824 in /system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so (have_dinfo 1) ---------------------------------whether these text show why malloc  trace is failed,  valgrind unload the  vgpreload_memcheck-arm64-linux.so , so no memory leak check.
--8142-- Reading syms from /system_Q_EA3/lib64/liblog.so
handle:0x67b0f9a77f30e9a7
p=0x6813000 p[2049]=5 malloc=0x5b1a32c
==8142==
==8142== HEAP SUMMARY:
==8142==     in use at exit: 1,072 bytes in 2 blocks
==8142==   total heap usage: 2 allocs, 0 frees, 1,072 bytes allocated
==8142==
==8142== Searching for pointers to 2 not-freed blocks
==8142== Checked 11,189,112 bytes
==8142==
==8142== LEAK SUMMARY:
==8142==    definitely lost: 0 bytes in 0 blocks
==8142==    indirectly lost: 0 bytes in 0 blocks
==8142==      possibly lost: 0 bytes in 0 blocks
==8142==    still reachable: 1,072 bytes in 2 blocks
==8142==         suppressed: 0 bytes in 0 blocks
==8142== Rerun with --leak-check=full to see details of leaked memory
==8142==
==8142== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==8142== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

-----邮件原件-----
发件人: Wuweijia [mailto:wuw...@hu...] 
发送时间: 2019年4月24日 10:56
收件人: John Reiser <jr...@bi...>; val...@li...
抄送: Fanbohao <fan...@hu...>
主题: [Valgrind-users] 答复: Some question about linker dlopen with valgrind

Is there any ways to make valgrind to support init_array to dlopen shared object;

I think linker can make the right jump to the malloc function without valgirind, so the source is right;

I want some ways to trace the valgirnd why redir module to malloc is failue;  




-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...]
发送时间: 2019年4月23日 23:19
收件人: val...@li...
主题: Re: [Valgrind-users] Some question about linker dlopen with valgrind

>>            On the Android OS,  there is a question about the linker program with vaglrind memcheck.

Which version of Android?

>>
>>            The 1^st  experiment,  the libc module *do*call the dlopen 
>> function to load some shared object, before the linker  call the 
>> pre_init functions (  before transfer the cpu control to the main ), 
>> and then the valgrind *can  not*trace malloc leak;
>>
>>            The second experiment, the libc module *do not*call the 
>> dlopen function to load some shared object, before the linker  call 
>> the pre_init functions (  before transfer the cpu control to the main 
>> ), and then the valgrind *can*  trace malloc leak;
>>
>>            I want to know why , and how to  make valgrind can trace memory leak, while  the libc module call the dlopen function to load some so, before the linker call the pre-init functions.

According to
    https://docs.oracle.com/cd/E19683-01/816-1386/6m7qcobks/index.html
the order of execution is:
   1. linker resolves and fetches all DT_NEEDED modules (shared libraries),
      and performs all relocations for the entire process image
   2. linker calls DT_PREINIT_ARRAY functions of the main program, in order
      (only a main program may have DT_PREINIT_ARRAY; a shared library MUST NOT)
   3. in dependency order (topological bottom-up) of all loaded modules (main program
      and shared libraries): linker calls DT_INIT and then DT_INIT_ARRAY (in order)
      for the module
   4. linker transfers control to the ElfXX_Ehdr.e_entry address of the main program

It is undefined what happens if a DT_PREINIT_ARRAY, DT_INIT_ARRAY, or DT_INIT function calls dlopen, particularly if the newly-loaded module depends on any other modules, whether or not those modules have been loaded already.  (The dependent module might not be initialized yet.)


_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] 答复: Some question about linker dlopen with valgrind

[Wuweijia <wuw...@hu...>]

Is there any ways to make valgrind to support init_array to dlopen shared object;

I think linker can make the right jump to the malloc function without valgirind, so the source is right;

I want some ways to trace the valgirnd why redir module to malloc is failue;  




-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2019年4月23日 23:19
收件人: val...@li...
主题: Re: [Valgrind-users] Some question about linker dlopen with valgrind

>>            On the Android OS,  there is a question about the linker program with vaglrind memcheck.

Which version of Android?

>>
>>            The 1^st  experiment,  the libc module *do*call the dlopen 
>> function to load some shared object, before the linker  call the 
>> pre_init functions (  before transfer the cpu control to the main ), 
>> and then the valgrind *can  not*trace malloc leak;
>>
>>            The second experiment, the libc module *do not*call the 
>> dlopen function to load some shared object, before the linker  call 
>> the pre_init functions (  before transfer the cpu control to the main 
>> ), and then the valgrind *can*  trace malloc leak;
>>
>>            I want to know why , and how to  make valgrind can trace memory leak, while  the libc module call the dlopen function to load some so, before the linker call the pre-init functions.

According to
    https://docs.oracle.com/cd/E19683-01/816-1386/6m7qcobks/index.html
the order of execution is:
   1. linker resolves and fetches all DT_NEEDED modules (shared libraries),
      and performs all relocations for the entire process image
   2. linker calls DT_PREINIT_ARRAY functions of the main program, in order
      (only a main program may have DT_PREINIT_ARRAY; a shared library MUST NOT)
   3. in dependency order (topological bottom-up) of all loaded modules (main program
      and shared libraries): linker calls DT_INIT and then DT_INIT_ARRAY (in order)
      for the module
   4. linker transfers control to the ElfXX_Ehdr.e_entry address of the main program

It is undefined what happens if a DT_PREINIT_ARRAY, DT_INIT_ARRAY, or DT_INIT function calls dlopen, particularly if the newly-loaded module depends on any other modules, whether or not those modules have been loaded already.  (The dependent module might not be initialized yet.)


_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] 答复: Some question about linker dlopen with valgrind

[Wuweijia <wuw...@hu...>]

Android Q 

The libc  source  as below:
__attribute__((constructor(1))) static void __libc_preinit() {
  // The linker has initialized its copy of the global stack_chk_guard, and filled in the main
  // thread's TLS slot with that value. Initialize the local global stack guard with its value.
  __stack_chk_guard = reinterpret_cast<uintptr_t>(__get_tls()[TLS_SLOT_STACK_GUARD]);

  __libc_preinit_impl();
}

__attribute__((noinline))
static void __libc_preinit_impl() {
  // Register libc.so's copy of the TLS generation variable so the linker can
  // update it when it loads or unloads a shared object.
  TlsModules& tls_modules = __libc_shared_globals()->tls_modules;
  tls_modules.generation_libc_so = &__libc_tls_generation_copy;
  __libc_tls_generation_copy = tls_modules.generation;

  __libc_init_globals();
  __libc_init_common();
	
  // Hooks for various libraries to let them know that we're starting up.
     TestInitImpl();
  }

static void TestInitImpl() {
        printf("%s enter\n", __func__);
        void * handle = dlopen("liblog.so",  RTLD_NOW );  -----------This is most important  call,  If call  dlopen success, and then malloc trace is not available now; If Not success, the malloc trace is okay;
        printf("handle:%p\n", handle);
}

The test main as below:

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>

int main(int argc, char ** argv) {
        char * p = (char *)malloc(2048);
        p[2049] = 5;
        printf("p=%p p[2049]=%d malloc=%p \n", p, p[2049], malloc);
        (void) argc;
        (void) argv;
        return 0;
}


The valgrind output as below:

localhost:/system/bin # ./valgrind --undef-value-errors=no --trace-malloc=yes     ./test64
MallocInitImpl enter
handle:0xcf2625b55fe1209
==7131== Memcheck, a memory error detector
==7131== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==7131== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==7131== Command: ./test64
==7131==
linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_core-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
WARNING: linker: Warning: "/system_Q_EA3/lib64/valgrind/vgpreload_memcheck-arm64-linux.so" has unsupported flags DT_FLAGS_1=0x421 (ignoring unsupported flags)
--7131-- malloc(48) = 0x60AA040
--7131-- malloc(1024) = 0x60AA0B0-----------------------------before  call dlopen in libc module , these text show me malloc trace is okay.
MallocInitImpl enter
--7131-- free(0x0)
handle:0x25bc73725878d53  -----------------------after print these text (it mean dlopen success in libc) , malloc trace is failure;
p=0x6813000 p[2049]=5 malloc=0x5d0f32c----------------------these text  mean main alloc some memory ;
==7131==
==7131== HEAP SUMMARY:
==7131==     in use at exit: 1,072 bytes in 2 blocks
==7131==   total heap usage: 2 allocs, 0 frees, 1,072 bytes allocated
==7131==
==7131== LEAK SUMMARY:
==7131==    definitely lost: 0 bytes in 0 blocks
==7131==    indirectly lost: 0 bytes in 0 blocks
==7131==      possibly lost: 0 bytes in 0 blocks
==7131==    still reachable: 1,072 bytes in 2 blocks
==7131==         suppressed: 0 bytes in 0 blocks
==7131== Rerun with --leak-check=full to see details of leaked memory
==7131==
==7131== For counts of detected and suppressed errors, rerun with: -v
==7131== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


-----邮件原件-----
发件人: John Reiser [mailto:jr...@bi...] 
发送时间: 2019年4月23日 23:19
收件人: val...@li...
主题: Re: [Valgrind-users] Some question about linker dlopen with valgrind

>>            On the Android OS,  there is a question about the linker program with vaglrind memcheck.

Which version of Android?

>>
>>            The 1^st  experiment,  the libc module *do*call the dlopen 
>> function to load some shared object, before the linker  call the 
>> pre_init functions (  before transfer the cpu control to the main ), 
>> and then the valgrind *can  not*trace malloc leak;
>>
>>            The second experiment, the libc module *do not*call the 
>> dlopen function to load some shared object, before the linker  call 
>> the pre_init functions (  before transfer the cpu control to the main 
>> ), and then the valgrind *can*  trace malloc leak;
>>
>>            I want to know why , and how to  make valgrind can trace memory leak, while  the libc module call the dlopen function to load some so, before the linker call the pre-init functions.

According to
    https://docs.oracle.com/cd/E19683-01/816-1386/6m7qcobks/index.html
the order of execution is:
   1. linker resolves and fetches all DT_NEEDED modules (shared libraries),
      and performs all relocations for the entire process image
   2. linker calls DT_PREINIT_ARRAY functions of the main program, in order
      (only a main program may have DT_PREINIT_ARRAY; a shared library MUST NOT)
   3. in dependency order (topological bottom-up) of all loaded modules (main program
      and shared libraries): linker calls DT_INIT and then DT_INIT_ARRAY (in order)
      for the module
   4. linker transfers control to the ElfXX_Ehdr.e_entry address of the main program

It is undefined what happens if a DT_PREINIT_ARRAY, DT_INIT_ARRAY, or DT_INIT function calls dlopen, particularly if the newly-loaded module depends on any other modules, whether or not those modules have been loaded already.  (The dependent module might not be initialized yet.)


_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Some question about linker dlopen with valgrind

[John R. <jr...@bi...>]

>>            On the Android OS,  there is a question about the linker program with vaglrind memcheck.

Which version of Android?

>>
>>            The 1^st  experiment,  the libc module *do*call the dlopen function to load some shared object, before the linker  call the pre_init functions (  before transfer the cpu control to the main ), and then the valgrind *can  not*trace malloc leak;
>>
>>            The second experiment, the libc module *do not*call the dlopen function to load some shared object, before the linker  call the pre_init functions (  before transfer the cpu control to the main ), and then the valgrind *can*  trace malloc leak;
>>
>>            I want to know why , and how to  make valgrind can trace memory leak, while  the libc module call the dlopen function to load some so, before the linker call the pre-init functions.

According to
    https://docs.oracle.com/cd/E19683-01/816-1386/6m7qcobks/index.html
the order of execution is:
   1. linker resolves and fetches all DT_NEEDED modules (shared libraries),
      and performs all relocations for the entire process image
   2. linker calls DT_PREINIT_ARRAY functions of the main program, in order
      (only a main program may have DT_PREINIT_ARRAY; a shared library MUST NOT)
   3. in dependency order (topological bottom-up) of all loaded modules (main program
      and shared libraries): linker calls DT_INIT and then DT_INIT_ARRAY (in order)
      for the module
   4. linker transfers control to the ElfXX_Ehdr.e_entry address of the main program

It is undefined what happens if a DT_PREINIT_ARRAY, DT_INIT_ARRAY, or DT_INIT function
calls dlopen, particularly if the newly-loaded module depends on any other modules,
whether or not those modules have been loaded already.  (The dependent module
might not be initialized yet.)

Re: [Valgrind-users] Some question about linker dlopen with valgrind

[John R. <jr...@bi...>]

>            On the Android OS,  there is a question about the linker program with vaglrind memcheck;
> 
>            The 1^st  experiment,  the libc module *do*call the dlopen function to load some shared object, before the linker  call the pre_init functions (  before transfer the cpu control to the main ), and then the valgrind *can  not*trace malloc leak;
> 
>            The second experiment, the libc module *do not*call the dlopen function to load some shared object, before the linker  call the pre_init functions (  before transfer the cpu control to the main ), and then the valgrind *can*  trace malloc leak;
> 
>            I want to know why , and how to  make valgrind can trace memory leak, while  the libc module call the dlopen function to load some so, before the linker call the pre-init functions.
> 
>            If you want to add some args to trace, Please email me.
> 
>            Valgrind version 3.14.

Thank you for stating the version of Valgrind.

It is hard to follow and understand the descriptions of the first and second experiments.
Please construct two test cases of specific literal source code with recipes for compile
and linking, corresponding to the first and second experiments.  Those two cases
should be runnable under valgrind, and should illustrate the difference between them.

[Valgrind-users] Some question about linker dlopen with valgrind

[Wuweijia <wuw...@hu...>]

Hi
          On the Android OS,  there is a question about the linker program with vaglrind memcheck;
          The 1st  experiment,  the libc module do call the dlopen function to load some shared object, before the linker  call the pre_init functions (  before transfer the cpu control to the main ), and then the valgrind can  not trace malloc leak;
          The second experiment, the libc module do not call the dlopen function to load some shared object, before the linker  call the pre_init functions (  before transfer the cpu control to the main ), and then the valgrind can  trace malloc leak;

          I want to know why , and how to  make valgrind can trace memory leak, while  the libc module call the dlopen function to load some so, before the linker call the pre-init functions.

          If you want to add some args to trace, Please email me.

          Valgrind version 3.14.
BR Owen

[Valgrind-users] valgrind-3.15.0 is available

[Julian S. <js...@ac...>]

We are pleased to announce a new release of Valgrind, version 3.15.0,
available from http://valgrind.org/downloads/current.html.  The source tarball
is signed with the PGP key at the bottom of this message.

3.15.0 updates support for existing platforms and adds a major overhaul of the
DHAT heap profiler.  There are, as ever, many refinements and bug fixes.  The
release notes below give more details.

Our thanks to all those who contribute to Valgrind's development.  This
release represents a great deal of time, energy and effort on the part of many
people.

Unfortunately the Solaris port no longer has a maintainer.  If you have some
familiarity with low level Solaris system programming and would like to help
out, please get in touch.  We are also looking for further assistance with the
MacOS port.

Happy and productive debugging and profiling,

-- The Valgrind Developers


Release 3.15.0 (12 April 2019)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3.15.0 is a feature release with many improvements and the usual collection of
bug fixes.

This release supports X86/Linux, AMD64/Linux, ARM32/Linux, ARM64/Linux,
PPC32/Linux, PPC64BE/Linux, PPC64LE/Linux, S390X/Linux, MIPS32/Linux,
MIPS64/Linux, ARM/Android, ARM64/Android, MIPS32/Android, X86/Android,
X86/Solaris, AMD64/Solaris and AMD64/MacOSX 10.12.  There is also preliminary
support for X86/macOS 10.13 and AMD64/macOS 10.13.

* ==================== CORE CHANGES ===================

* The XTree Massif output format now makes use of the information obtained
   when specifying --read-inline-info=yes.

* amd64 (x86_64): the RDRAND and F16C insn set extensions are now supported.

* ==================== TOOL CHANGES ====================

* DHAT:

   - DHAT been thoroughly overhauled, improved, and given a GUI.  As a result,
     it has been promoted from an experimental tool to a regular tool.  Run it
     with --tool=dhat instead of --tool=exp-dhat.

   - DHAT now prints only minimal data when the program ends, instead writing
     the bulk of the profiling data to a file.  As a result, the --show-top-n
     and --sort-by options have been removed.

   - Profile results can be viewed with the new viewer, dh_view.html.  When
     a run ends, a short message is printed, explaining how to view the result.

   - See the documentation for more details.

* Cachegrind:

   - cg_annotate has a new option, --show-percs, which prints percentages next
     to all event counts.

* Callgrind:

   - callgrind_annotate has a new option, --show-percs, which prints
     percentages next to all event counts.

   - callgrind_annotate now inserts commas in call counts, and
     sort the caller/callee lists in the call tree.

* Massif:

   - The default value for --read-inline-info is now "yes" on
     Linux/Android/Solaris. It is still "no" on other OS.

* Memcheck:

   - The option --xtree-leak=yes (to output leak result in xtree format)
     automatically activates the option --show-leak-kinds=all, as xtree
     visualisation tools such as kcachegrind can in any case select what kind
     of leak to visualise.

   - There has been further work to avoid false positives.  In particular,
     integer equality on partially defined inputs (C == and !=) is now handled
     better.

* ==================== OTHER CHANGES ====================

* The new option --show-error-list=no|yes displays, at the end of the run, the
   list of detected errors and the used suppressions.  Prior to this change,
   showing this information could only be done by specifying "-v -v", but that
   also produced a lot of other possibly-non-useful messages.  The option -s is
   equivalent to --show-error-list=yes.

* ==================== FIXED BUGS ====================

The following bugs have been fixed or resolved.  Note that "n-i-bz"
stands for "not in bugzilla" -- that is, a bug that was reported to us
but never got a bugzilla entry.  We encourage you to file bugs in
bugzilla (https://bugs.kde.org/enter_bug.cgi?product=valgrind) rather
than mailing the developers (or mailing lists) directly -- bugs that
are not entered into bugzilla tend to get forgotten about or ignored.

To see details of a given bug, visit
   https://bugs.kde.org/show_bug.cgi?id=XXXXXX
where XXXXXX is the bug number as listed below.

385411  s390x: z13 vector floating-point instructions not implemented
397187  z13 vector register support for vgdb gdbserver
398183  Vex errors with _mm256_shuffle_epi8/vpshufb
398870  Please add support for instruction vcvtps2ph
399287  amd64 front end: Illegal Instruction vcmptrueps
399301  Use inlined frames in Massif XTree output.
399322  Improve callgrind_annotate output
399444  VEX/priv/guest_s390_toIR.c:17407: (style) Mismatching assignment [..]
400164  helgrind test encounters mips x-compiler warnings and assembler error
400490  s390x: VRs allocated as if separate from FPRs
400491  s390x: Operand of LOCH treated as unsigned integer
400975  Compile error: error: '-mips64r2' conflicts with the other
         architecture options, which specify a mips64 processor
401112  LLVM 5.0 generates comparison against partially initialized data
401277  More bugs in z13 support
401454  Add a --show-percs option to cg_annotate and callgrind_annotate.
401578  drd: crashes sometimes on fork()
401627  memcheck errors with glibc avx2 optimized wcsncmp
401822  none/tests/ppc64/jm-vmx fails and produces assembler warnings
401827  none/tests/ppc64/test_isa_2_06_part3 failure on ppc64le (xvrsqrtesp)
401828  none/tests/ppc64/test_isa_2_06_part1 failure on ppc64le (fcfids and
         fcfidus)
402006  mark helper regs defined in final_tidyup before freeres_wrapper call
402048  WARNING: unhandled ppc64[be|le]-linux syscall: 26 (ptrace)
402123  invalid assembler opcodes for mips32r2
402134  assertion fail in mc_translate.c (noteTmpUsesIn) Iex_VECRET on arm64
402327  Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x13 (DW_OP_drop)
402341  drd/tests/tsan_thread_wrappers_pthread.h:369: suspicious code ?
402351  mips64 libvexmultiarch_test fails on s390x
402369  Overhaul DHAT
402395  coregrind/vgdb-invoker-solaris.c: 2 * poor error checking
402480  Do not use %rsp in clobber list
402481  vbit-test fails on x86 for Iop_CmpEQ64 iselInt64Expr Sar64
402515  Implement new option --show-error-list=no|yes / -s
402519  POWER 3.0 addex instruction incorrectly implemented
402781  Redo the cache used to process indirect branch targets
403123  vex amd64->IR:0xF3 0x48 0xF 0xAE 0xD3 (wrfsbase)
403552  s390x: wrong facility bit checked for vector facility
404054  memcheck powerpc subfe x, x, x initializes x to 0 or -1 based on CA
404638  Add VG_(replaceIndexXA)
404843  s390x: backtrace sometimes ends prematurely
404888  autotools cleanup series
405079  unhandled ppc64le-linux syscall: 131 (quotactl)
405182  Valgrind fails to build with Clang
405205  filter_libc: remove the line holding the futex syscall error entirely
405356  PPC64, xvcvsxdsp, xvcvuxdsp are supposed to write the 32-bit result to
         the upper and lower 32-bits of the 64-bit result
405362  PPC64, vmsummbm instruction doesn't handle overflow case correctly
405363  PPC64, xvcvdpsxws, xvcvdpuxws, do not handle NaN arguments correctly.
405365  PPC64, function _get_maxmin_fp_NaN() doesn't handle QNaN, SNaN case
         correctly.
405403  s390x disassembler cannot be used on x86
405430  Use gcc -Wimplicit-fallthrough=2 by default if available
405458  MIPS mkFormVEC arguments swapped?
405716  drd: Fix an integer overflow in the stack margin calculation
405722  Support arm64 core dump
405733  PPC64, xvcvdpsp should write 32-bit result to upper and lower 32-bits
         of the 64-bit destination field.
405734  PPC64, vrlwnm, vrlwmi, vrldrm, vrldmi do not work properly when
         me < mb
405782  "VEX temporary storage exhausted" when attempting to debug slic3r-pe
406198  none/tests/ppc64/test_isa_3_0_other test sporadically including CA
         bit in output.
406352  cachegrind/callgrind fails ann tests because of missing a.c
406354  dhat is broken on x86 (32bit)
406355  mcsignopass, mcsigpass, mcbreak fail due to difference in gdb output
406357  gdbserver_tests fails because of gdb output change
406360  memcheck/tests/libstdc++.supp needs more supression variants
406422  none/tests/amd64-linux/map_32bits.vgtest fails too easily
406465  arm64 insn selector fails on "t0 = <expr>" where <expr> has type
         Ity_F16
n-i-bz  add syswrap for PTRACE_GET|SET_THREAD_AREA on amd64.
n-i-bz  Fix callgrind_annotate non deterministic order for equal total
n-i-bz  callgrind_annotate --threshold=100 does not print all functions.
n-i-bz  callgrind_annotate Use of uninitialized value in numeric gt (>)
n-i-bz  amd64 (x86_64): RDRAND and F16C insn set extensions are supported

(3.15.0.RC1:  8 April 2019, git ce94d674de5b99df173aad4c3ee48fc2a92e5d9c)
(3.15.0.RC2: 11 April 2019, git 0c8be9bbede189ec580ec270521811766429595f)
(3.15.0:     14 April 2019, git 270037da8b508954f0f7d703a0bebf5364eec548)


-----BEGIN PGP PUBLIC KEY BLOCK-----

mQENBFy189QBCACxFf0SSSycE42ulnIYk7GNR9FnKlDN4rNZ9TExYWMh6cJIELgq
W5eI9xoHJarfLc7uSKPagcGPIntThCMBw8dLnL8mFzsCOIrjQl/C9FZua53RwmzE
t6+yvMJMcYz8Vqfh7J8w5+zlAMFSqbE5jAcWEzlaz8YMt8GTgixhFSC6eyy0j+4L
k35+lKOvX1htUIjVYz9nfVgGmz6Vg+2dyjxoB6GHXtrAExRuoo0jqctLc8dZOp0U
MMzVEQzJItcYj6/L1FEOYcrnhVri92sgB+AReMWy1ailt+OmNXmEkpV5L4vCJn2Y
sThu7OnecBUoMMP13y2UB23h3vlxe0RyxuZNABEBAAG0H0p1bGlhbiBTZXdhcmQg
PGpzZXdhcmRAYWNtLm9yZz6JATgEEwECACIFAly189QCGwMGCwkIBwMCBhUIAgkK
CwQWAgMBAh4BAheAAAoJELoBZuaY+mA1ttoH/0MkIQcB4QohV2Z9Fkf95jm6uz/P
rFewPS7iyRMLL9sPktjqXg0X1yxX5ShpEbtL18X+qbAVDIe98uTdyFb21b8DjP6n
v2KnIZFDD+iZEceWJD6MAXcicvr4sv4LESzreNEIF6wHdWkWC4v57hQl+uywWXiI
T4gnHUEJIu0cNP3vMcSjrgrzeaPW3z56B+BLBM1XncrZ0mbz77/FK9lQM1arLpcU
dPNJlVMqNdbLLlIsmkZ8jfE7TCOCNuIrCHeNTRGY5NuY829pheGwutIlp4t+Pchz
/cib3hZeilJrFuuqBOk4ipZ/s1PwS9DigGOk1I0egqIBhPdAsEY3gBXdOXyJAjME
EAEKAB0WIQTsPP6I9soHiHdPXB0apEvmSd52CgUCXLYy8gAKCRAapEvmSd52CnJb
D/45yMDDnSelx6MfBwQcowqkkK/BzZs+akR5hX76g5alMSA2MRBkudGO8R/G2fva
sa9e2Js+3crmoyOxfL3PCun/N7/J2rX8PPT6d4hk1N3fluUWghUhCDMHmfPy1N5d
WMTTW/EvZrYdh1dauGw/k+DP/M784FN8UU15hggMCcqM5LGNKuMOhFadntecj/Wr
aAtroLD3Geq7eUAO18oYgJFRktdXtDkWGTG6+KhoLTIaW8xRAR1OiO6Oxua+3htU
Zrk9AIDAJQymeA9budWyVAMPZSgnkSdMQBe8UnwsCx1X6xZP+wHihZ86oClydieh
3AtsLzjzZGNytAO7+BP7cNxvrWXBNUMTEQwAcMp8PbjV3NAK/96sfdQ++3wttvMw
4M4AI0hFxE67EkpTjk0rDhDINjOowyn/MBpNuuC2BuDlzrR7AV8jKq957OMko6uk
S/NlJo9LUYeyLSU1lF5B6fh6tu3Tyv4yASTp6fyihh+G24azAbYi4WQu79ltuDQb
Zg4fGVB/vcydsf1NxiEQMMSOyrcws+WNYjqGymZ70YZW+PDEBZcW4WE515RR0N3N
3YmLbvIywYQe2zKFOoLu2CDx/q/gqMX0W9I4h3sSKOoFIFkeY7Cr/6OdV6S1Re9d
o/dGoKDzfjaXpTZf4Kv19wEizElnoi7S7tFrbLLMV1vQHrkBDQRctfPUAQgAtKTF
G5HFIUs8kO3Cs3EysJhOe/pEIYhkdRwKn46ostfk7Ghd4YdwRYDscZaqrwCaY1lV
VLKd33IPdFHpGwRQrM0RyLA+A6xfdoCoKO0vOLTEiEDI+C3FDSZ/vCeq13gMfYHN
tuhmEjvA9MMwKx0/kfKc28fQWPDDDgnAQ6cyS+9t4s4j6JuRm/rq4blKWGK8f8Ob
KrEFHt/J1uhLykGbgYFu0MSaldevjHJzqzkscHcifAA5SMWZuYn5dMCNJT+8Iadr
u0TSCvZQeN3HceNCN2Liodpv/JqUn8qF5wGaUxZFcGdy5V+nR1PsQnguEd35Z1ai
rfqdE27KZYRC3xzO8wARAQABiQEfBBgBAgAJBQJctfPUAhsMAAoJELoBZuaY+mA1
NSUH/jUd12imDneXAMKt3ThlqXh1v0tPnawugaNHD3vibvgFYcyqQ+YbPMhRgUoc
hdTLbkqxkjEzfLhpzAA164AcP3/pDq+OCyyONNnt06LXxgGU2lJoTeRdSEsOFYxE
RnOUoW8qQoPWWk8ZmnMh/2VEuXeIjXMHNvdAWMn0gUfKDEeeCILpqkn4f4Sx4H5P
1Yf4JzgwYTfFocXDsQSsFrboAPOJVEm4E7zJfp62Uzs72+9NueHnZEnr4pVzCUIm
CxJrvQzGcJxc1eqbuCmI0zuFLRcgZUpO4a0IaDUsjhbG2PUTADgSAfgLihrvaiA+
xn/APcV8iSUjgKGcnQfuhhayxQk=
=C8ND
-----END PGP PUBLIC KEY BLOCK-----

[Valgrind-users] Valgrind-3.15.0.RC2 is available for testing

[Julian S. <js...@ac...>]

Thank you to everybody who tested RC1, sent reports and bug fixes.

RC2 is now available at
https://sourceware.org/pub/valgrind/valgrind-3.15.0.RC2.tar.bz2
(md5 = 672e065ec63ae127ee4439cd296fb142).  It contains fixes for
five minor regression test failures, but nothing major.

Unless any serious failures are reported in RC2, this is very likely
to morph into the final 3.15.0 release.

J

> On 08/04/2019 11:11, Julian Seward wrote:
>
> A first release candidate for 3.15.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.15.0.RC1.tar.bz2
> (md5 = 56d9f5e25615d48110da0aa5764d481e)
>
> Please give it a try on platforms that are important for you.  If no serious
> issues are reported, the 3.15.0 final release will happen on 12 April, that
> is, this coming Friday.
>
> J