valgrind-users — General discussion list for Valgrind users

[Valgrind-users] --32556:0:libcfile Valgrind: FATAL: Private file creation failed.

[Jessica L. <jes...@gm...>]

Not sure what to do. I'm new to Linux and Valgrind.

I'm on CLion, and I'm trying to run my code with Valgrind memcheck.
However I get the message.

--33110:0:libcfile Valgrind: FATAL: Private file creation failed.
   The current file descriptor limit is 1073741804.
   If you are running in Docker please consider
   lowering this limit with the shell built-in limit command.
--33110:0:libcfile Exiting now.

Re: [Valgrind-users] Valgrind runs way slower on faster PC

[Lev Y. <lyu...@gm...>]

Sure. Here we go:

perf stat on first PC (i7-6700K @ 4.00GHz x 8 CPU, 32GiB RAM):

        395,282.24 msec task-clock                       #    5.612 CPUs
utilized
         4,982,318      context-switches                 #   12.604 K/sec

         1,258,234      cpu-migrations                   #    3.183 K/sec

         1,698,192      page-faults                      #    4.296 K/sec

 1,558,005,376,132      cycles                           #    3.942 GHz

 1,085,678,118,192      instructions                     #    0.70  insn
per cycle
   130,242,817,239      branches                         #  329.493 M/sec

     1,513,065,695      branch-misses                    #    1.16% of all
branches

      70.439261508 seconds time elapsed
     351.168298000 seconds user
      44.239862000 seconds sys


perf stat on second PC (i7-10700 @ 2.90GHz x 16 CPU, 64GiB RAM):

        277,595.50 msec task-clock                       #    8.502 CPUs
utilized
         3,356,252      context-switches                 #   12.090 K/sec

           872,020      cpu-migrations                   #    3.141 K/sec

         1,671,597      page-faults                      #    6.022 K/sec

 1,257,017,696,457      cycles                           #    4.528 GHz

   590,118,043,095      instructions                     #    0.47  insn
per cycle
    70,240,995,962      branches                         #  253.034 M/sec

       734,712,605      branch-misses                    #    1.05% of all
branches

      32.651035006 seconds time elapsed
     254.315463000 seconds user
      23.384174000 seconds sys


On Mon, 10 Feb 2025 at 13:26, Simon Sobisch <sim...@gn...> wrote:

> Just out of interest: can you run
>
>      perf stat yourprog
>
> (depending on your setup that may need root or a temporary adjustment of
> the paranoid setting) on both machines and share the results - just to
> know what we're actually talking about...
>
> Simon
>
> Am 10.02.2025 um 11:02 schrieb Lev Yudalevich:
> > The program being tested is not single-threaded. In fact, it is
> > "extremely" multi-threaded. That's why I was expecting faster runs.
> >
> > On Mon, 10 Feb 2025 at 11:54, David Faure <fa...@kd...
> > <mailto:fa...@kd...>> wrote:
> >
> >     On Monday, 10 February 2025 09:44:39 Lev Yudalevich wrote:
> >      > My first PC has i7-6700K @ 4.00GHz x 8 CPU, 32GiB RAM
> >      > My second PC has i7-10700 @ 2.90GHz x 16 CPU, 64GiB RAM
> >      > Both machines have identical OS installation (Ubuntu 22.04.5 LTS)
> >     rest of
> >      > the software (toolchains etc).
> >      > However, running Valgrind (version 3.25.0.GIT) with the same test
> >     program
> >      > on a second (presumably more powerful) machine is more than twice
> >     slower
> >      > than running the same on the first machine. What can be a reason
> >     for this?
> >      > I'd really appreciate any hint/help/idea. Thank you. Lev.
> >
> >     2.9 GHz < 4.0 GHz so it seems to me the second PC has a slower CPU.
> >     Assuming that the program is single-threaded, this explains why the
> >     second
> >     machine is actually slower.
> >
> >     --
> >     David Faure, fa...@kd... <mailto:fa...@kd...>, http://
> >     www.davidfaure.fr <http://www.davidfaure.fr>
> >
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>

Re: [Valgrind-users] Valgrind runs way slower on faster PC

[Simon S. <sim...@gn...>]

Just out of interest: can you run

     perf stat yourprog

(depending on your setup that may need root or a temporary adjustment of 
the paranoid setting) on both machines and share the results - just to 
know what we're actually talking about...

Simon

Am 10.02.2025 um 11:02 schrieb Lev Yudalevich:
> The program being tested is not single-threaded. In fact, it is 
> "extremely" multi-threaded. That's why I was expecting faster runs.
> 
> On Mon, 10 Feb 2025 at 11:54, David Faure <fa...@kd... 
> <mailto:fa...@kd...>> wrote:
> 
>     On Monday, 10 February 2025 09:44:39 Lev Yudalevich wrote:
>      > My first PC has i7-6700K @ 4.00GHz x 8 CPU, 32GiB RAM
>      > My second PC has i7-10700 @ 2.90GHz x 16 CPU, 64GiB RAM
>      > Both machines have identical OS installation (Ubuntu 22.04.5 LTS)
>     rest of
>      > the software (toolchains etc).
>      > However, running Valgrind (version 3.25.0.GIT) with the same test
>     program
>      > on a second (presumably more powerful) machine is more than twice
>     slower
>      > than running the same on the first machine. What can be a reason
>     for this?
>      > I'd really appreciate any hint/help/idea. Thank you. Lev.
> 
>     2.9 GHz < 4.0 GHz so it seems to me the second PC has a slower CPU.
>     Assuming that the program is single-threaded, this explains why the
>     second
>     machine is actually slower.
> 
>     -- 
>     David Faure, fa...@kd... <mailto:fa...@kd...>, http://
>     www.davidfaure.fr <http://www.davidfaure.fr>
> 
> 
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind runs way slower on faster PC

[Lev Y. <lyu...@gm...>]

Now I got it. Thank you very much!

On Mon, 10 Feb 2025 at 12:17, Tobias Bading <tb...@we...> wrote:

> On 10. Feb 2025, at 11:04, Lev Yudalevich <lyu...@gm...> wrote:
>
> The program being tested is not single-threaded. In fact, it is
> "extremely" multi-threaded. That's why I was expecting faster runs.
>
>
> Your application does not run multi-threaded under Valgrind, see
> https://valgrind.org/docs/manual/manual-core.html#manual-core.pthreads.
>

Re: [Valgrind-users] Valgrind runs way slower on faster PC

[Tobias B. <tb...@we...>]

> On 10. Feb 2025, at 11:04, Lev Yudalevich <lyu...@gm...> wrote:
> The program being tested is not single-threaded. In fact, it is "extremely" multi-threaded. That's why I was expecting faster runs.

Your application does not run multi-threaded under Valgrind, see https://valgrind.org/docs/manual/manual-core.html#manual-core.pthreads.

Re: [Valgrind-users] Valgrind runs way slower on faster PC

[Lev Y. <lyu...@gm...>]

The program being tested is not single-threaded. In fact, it is "extremely"
multi-threaded. That's why I was expecting faster runs.

On Mon, 10 Feb 2025 at 11:54, David Faure <fa...@kd...> wrote:

> On Monday, 10 February 2025 09:44:39 Lev Yudalevich wrote:
> > My first PC has i7-6700K @ 4.00GHz x 8 CPU, 32GiB RAM
> > My second PC has i7-10700 @ 2.90GHz x 16 CPU, 64GiB RAM
> > Both machines have identical OS installation (Ubuntu 22.04.5 LTS) rest of
> > the software (toolchains etc).
> > However, running Valgrind (version 3.25.0.GIT) with the same test program
> > on a second (presumably more powerful) machine is more than twice slower
> > than running the same on the first machine. What can be a reason for
> this?
> > I'd really appreciate any hint/help/idea. Thank you. Lev.
>
> 2.9 GHz < 4.0 GHz so it seems to me the second PC has a slower CPU.
> Assuming that the program is single-threaded, this explains why the second
> machine is actually slower.
>
> --
> David Faure, fa...@kd..., http://www.davidfaure.fr
>

Re: [Valgrind-users] Valgrind runs way slower on faster PC

[David F. <fa...@kd...>]

On Monday, 10 February 2025 09:44:39 Lev Yudalevich wrote:
> My first PC has i7-6700K @ 4.00GHz x 8 CPU, 32GiB RAM
> My second PC has i7-10700 @ 2.90GHz x 16 CPU, 64GiB RAM
> Both machines have identical OS installation (Ubuntu 22.04.5 LTS) rest of
> the software (toolchains etc).
> However, running Valgrind (version 3.25.0.GIT) with the same test program
> on a second (presumably more powerful) machine is more than twice slower
> than running the same on the first machine. What can be a reason for this?
> I'd really appreciate any hint/help/idea. Thank you. Lev.

2.9 GHz < 4.0 GHz so it seems to me the second PC has a slower CPU.
Assuming that the program is single-threaded, this explains why the second 
machine is actually slower.

-- 
David Faure, fa...@kd..., http://www.davidfaure.fr

[Valgrind-users] Valgrind runs way slower on faster PC

[Lev Y. <lyu...@gm...>]

My first PC has i7-6700K @ 4.00GHz x 8 CPU, 32GiB RAM
My second PC has i7-10700 @ 2.90GHz x 16 CPU, 64GiB RAM
Both machines have identical OS installation (Ubuntu 22.04.5 LTS) rest of
the software (toolchains etc).
However, running Valgrind (version 3.25.0.GIT) with the same test program
on a second (presumably more powerful) machine is more than twice slower
than running the same on the first machine. What can be a reason for this?
I'd really appreciate any hint/help/idea. Thank you. Lev.

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

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

Is glibc compiled with debug info ?
Without a way to see where the problem happens in glibc, this will be difficult
to understand.
If/when you have glibc debug info, you might use valgrind --vgdb-error=0 and debug
glibc startup under valgrind+gdb

Alternatively, you might add -v -v -v -d -d -d to have more information produced by
valgrind, but that will likely not help much without glibc debug.

In the original mail, you show an extract of the error logs.
Was there any other error before ?
Because the problem might originate from an earlier error.

Finally, do you encounter the same problem with e.g. --tool=none or --tool=callgrind ?
(none will do no transformation to the guest process and callgrind will not replace
malloc/free, so that might give a hint).

Thanks
Philippe




On Thu, 2025-01-30 at 01:00 +0530, kiran hardas wrote:
> Yes Philippe, I did try out Valgrind 3.24, but it too gave same error.
> 
> Regards,
> Kiran H.
> 
> On Wed, Jan 29, 2025 at 11:56 PM Philippe Waroquiers <phi...@sk...>
> wrote:
> > The first thing to try is to compile and use a more recent valgrind version.
> > (3.18 is something like 4 years old while 3.24 is from Oct 24).
> > 
> > Thanks
> > Philippe
> > 
> > 
> > On Wed, 2025-01-29 at 19:03 +0530, kiran hardas wrote:
> > > Hi Team,
> > > 
> > > Good Evening,
> > > 
> > > I need some support in debugging an issue in Valgrind 3.18. 
> > > 
> > > I have an application which I am trying to check with Valgrind tool for memory
> > > issues. I
> > > have the valgrind source code which is compiled and built along with my application
> > > using same set of libraries. But while checking with valgrind tool i get an invalid
> > > address error in libc library (mostly implying null pointer dereferencing/free) and
> > > valgrind is terminating. I am unable to find the exact place in glibc code where
> > > this
> > > error is coming from and need any help which you can provide.
> > > 
> > > Please find further details below,
> > > 
> > > $ ./usr/test/bin/valgrind --version -v
> > > valgrind-3.18.1-42b08ed5bd-20211015
> > > 
> > > GNU/Linux 5.4
> > > Glibc 2.40
> > > gcc 14.2
> > > binutils 2.43
> > > 
> > > This same valgrind was working when i was using glibc 2.23 but giving this error
> > > when i
> > > upgraded glibc to 2.40
> > > For valgrind 3.18 i have applied rseq patches and nop code error (0x2E 0x8D 0xB4
> > > 0x26)
> > > patches also required for latest glibc 2.40.
> > > 
> > > Error log snippet:
> > > ------------------------
> > > ...
> > > ...
> > > ==13089==
> > > --13089-- REDIR: 0x1f749f60 (libc.so.6:???) redirected to 0x1e59bd70 (strcmp)
> > > ==13089== Jump to the invalid address stated on the next line
> > > ==13089==    at 0x0: ???
> > > ==13089==    by 0x1F607366: ??? (in /lib/libc-2.40.so)
> > > ==13089==    by 0x1F607423: (below main) (in /lib/libc-2.40.so)
> > > ==13089==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> > > ==13089==
> > > ==13089==
> > > ==13089== Process terminating with default action of signal 11 (SIGSEGV): dumping
> > > core
> > > ==13089==  Bad permissions for mapped region at address 0x0
> > > ==13089==    at 0x0: ???
> > > ==13089==    by 0x1F607366: ??? (in /lib/libc-2.40.so)
> > > ==13089==    by 0x1F607423: (below main) (in /lib/libc-2.40.so)
> > > ==13089==
> > > 
> > > 
> > > Approaches tried
> > > -----------------------
> > > 1. I reduced the optimisation level in glibc to -O1, but still no further symbol
> > > details
> > > are available
> > > 2. The core file generated for valgrind crash is also not showing any symbol details
> > > at
> > > crash point. (only showing ??)
> > > 3. Tried adding more option to valgrind like --track-origins=yes , --read-var-
> > > info=yes .
> > > But not giving any more info for the error.
> > > 
> > > 
> > > I would appreciate any pointers team can provide in debugging this issue.
> > > 
> > > Thanks in advance
> > > 
> > > Regards,
> > > Kiran H.
> > > 
> > > _______________________________________________
> > > Valgrind-users mailing list
> > > Val...@li...
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > 

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[kiran h. <kha...@gm...>]

Yes Philippe, I did try out Valgrind 3.24, but it too gave same error.

Regards,
Kiran H.

On Wed, Jan 29, 2025 at 11:56 PM Philippe Waroquiers <
phi...@sk...> wrote:

> The first thing to try is to compile and use a more recent valgrind
> version.
> (3.18 is something like 4 years old while 3.24 is from Oct 24).
>
> Thanks
> Philippe
>
>
> On Wed, 2025-01-29 at 19:03 +0530, kiran hardas wrote:
> > Hi Team,
> >
> > Good Evening,
> >
> > I need some support in debugging an issue in Valgrind 3.18.
> >
> > I have an application which I am trying to check with Valgrind tool for
> memory issues. I
> > have the valgrind source code which is compiled and built along with my
> application
> > using same set of libraries. But while checking with valgrind tool i get
> an invalid
> > address error in libc library (mostly implying null pointer
> dereferencing/free) and
> > valgrind is terminating. I am unable to find the exact place in glibc
> code where this
> > error is coming from and need any help which you can provide.
> >
> > Please find further details below,
> >
> > $ ./usr/test/bin/valgrind --version -v
> > valgrind-3.18.1-42b08ed5bd-20211015
> >
> > GNU/Linux 5.4
> > Glibc 2.40
> > gcc 14.2
> > binutils 2.43
> >
> > This same valgrind was working when i was using glibc 2.23 but giving
> this error when i
> > upgraded glibc to 2.40
> > For valgrind 3.18 i have applied rseq patches and nop code error (0x2E
> 0x8D 0xB4 0x26)
> > patches also required for latest glibc 2.40.
> >
> > Error log snippet:
> > ------------------------
> > ...
> > ...
> > ==13089==
> > --13089-- REDIR: 0x1f749f60 (libc.so.6:???) redirected to 0x1e59bd70
> (strcmp)
> > ==13089== Jump to the invalid address stated on the next line
> > ==13089==    at 0x0: ???
> > ==13089==    by 0x1F607366: ??? (in /lib/libc-2.40.so)
> > ==13089==    by 0x1F607423: (below main) (in /lib/libc-2.40.so)
> > ==13089==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> > ==13089==
> > ==13089==
> > ==13089== Process terminating with default action of signal 11
> (SIGSEGV): dumping core
> > ==13089==  Bad permissions for mapped region at address 0x0
> > ==13089==    at 0x0: ???
> > ==13089==    by 0x1F607366: ??? (in /lib/libc-2.40.so)
> > ==13089==    by 0x1F607423: (below main) (in /lib/libc-2.40.so)
> > ==13089==
> >
> >
> > Approaches tried
> > -----------------------
> > 1. I reduced the optimisation level in glibc to -O1, but still no
> further symbol details
> > are available
> > 2. The core file generated for valgrind crash is also not showing any
> symbol details at
> > crash point. (only showing ??)
> > 3. Tried adding more option to valgrind like --track-origins=yes
> , --read-var-info=yes .
> > But not giving any more info for the error.
> >
> >
> > I would appreciate any pointers team can provide in debugging this issue.
> >
> > Thanks in advance
> >
> > Regards,
> > Kiran H.
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>

Re: [Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

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

The first thing to try is to compile and use a more recent valgrind version.
(3.18 is something like 4 years old while 3.24 is from Oct 24).

Thanks
Philippe


On Wed, 2025-01-29 at 19:03 +0530, kiran hardas wrote:
> Hi Team,
> 
> Good Evening,
> 
> I need some support in debugging an issue in Valgrind 3.18. 
> 
> I have an application which I am trying to check with Valgrind tool for memory issues. I
> have the valgrind source code which is compiled and built along with my application
> using same set of libraries. But while checking with valgrind tool i get an invalid
> address error in libc library (mostly implying null pointer dereferencing/free) and
> valgrind is terminating. I am unable to find the exact place in glibc code where this
> error is coming from and need any help which you can provide.
> 
> Please find further details below,
> 
> $ ./usr/test/bin/valgrind --version -v
> valgrind-3.18.1-42b08ed5bd-20211015
> 
> GNU/Linux 5.4
> Glibc 2.40
> gcc 14.2
> binutils 2.43
> 
> This same valgrind was working when i was using glibc 2.23 but giving this error when i
> upgraded glibc to 2.40
> For valgrind 3.18 i have applied rseq patches and nop code error (0x2E 0x8D 0xB4 0x26)
> patches also required for latest glibc 2.40.
> 
> Error log snippet:
> ------------------------
> ...
> ...
> ==13089==
> --13089-- REDIR: 0x1f749f60 (libc.so.6:???) redirected to 0x1e59bd70 (strcmp)
> ==13089== Jump to the invalid address stated on the next line
> ==13089==    at 0x0: ???
> ==13089==    by 0x1F607366: ??? (in /lib/libc-2.40.so)
> ==13089==    by 0x1F607423: (below main) (in /lib/libc-2.40.so)
> ==13089==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==13089==
> ==13089==
> ==13089== Process terminating with default action of signal 11 (SIGSEGV): dumping core
> ==13089==  Bad permissions for mapped region at address 0x0
> ==13089==    at 0x0: ???
> ==13089==    by 0x1F607366: ??? (in /lib/libc-2.40.so)
> ==13089==    by 0x1F607423: (below main) (in /lib/libc-2.40.so)
> ==13089==
> 
> 
> Approaches tried
> -----------------------
> 1. I reduced the optimisation level in glibc to -O1, but still no further symbol details
> are available
> 2. The core file generated for valgrind crash is also not showing any symbol details at
> crash point. (only showing ??)
> 3. Tried adding more option to valgrind like --track-origins=yes , --read-var-info=yes .
> But not giving any more info for the error.
> 
> 
> I would appreciate any pointers team can provide in debugging this issue.
> 
> Thanks in advance
> 
> Regards,
> Kiran H.
> 
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] Need support in debugging Valgrind 3.18 glibc segv error

[kiran h. <kha...@gm...>]

Hi Team,

Good Evening,

I need some support in debugging an issue in Valgrind 3.18.

I have an application which I am trying to check with Valgrind tool for
memory issues. I have the valgrind source code which is compiled and built
along with my application using same set of libraries. But while checking
with valgrind tool i get an invalid address error in libc library (mostly
implying null pointer dereferencing/free) and valgrind is terminating. I am
unable to find the exact place in glibc code where this error is coming
from and need any help which you can provide.

Please find further details below,

$ ./usr/test/bin/valgrind --version -v
valgrind-3.18.1-42b08ed5bd-20211015

GNU/Linux 5.4
Glibc 2.40
gcc 14.2
binutils 2.43

This same valgrind was working when i was using glibc 2.23 but giving this
error when i upgraded glibc to 2.40
For valgrind 3.18 i have applied rseq patches and nop code error (0x2E 0x8D
0xB4 0x26) patches also required for latest glibc 2.40.

Error log snippet:
------------------------
...
...
==13089==
--13089-- REDIR: 0x1f749f60 (libc.so.6:???) redirected to 0x1e59bd70
(strcmp)
==13089== Jump to the invalid address stated on the next line
==13089==    at 0x0: ???
==13089==    by 0x1F607366: ??? (in /lib/libc-2.40.so)
==13089==    by 0x1F607423: (below main) (in /lib/libc-2.40.so)
==13089==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==13089==
==13089==
==13089== Process terminating with default action of signal 11 (SIGSEGV):
dumping core
==13089==  Bad permissions for mapped region at address 0x0
==13089==    at 0x0: ???
==13089==    by 0x1F607366: ??? (in /lib/libc-2.40.so)
==13089==    by 0x1F607423: (below main) (in /lib/libc-2.40.so)
==13089==


Approaches tried
-----------------------
1. I reduced the optimisation level in glibc to -O1, but still no
further symbol details are available
2. The core file generated for valgrind crash is also not showing any
symbol details at crash point. (only showing ??)
3. Tried adding more option to valgrind like --track-origins=yes
, --read-var-info=yes . But not giving any more info for the error.


I would appreciate any pointers team can provide in debugging this issue.

Thanks in advance

Regards,
Kiran H.

Re: [Valgrind-users] New --track-fds=new option expected behaviour

[Alexandra P. H. <aha...@re...>]

Thank you everyone for the feedback!

>
> > --track-fds=random.
>
> Is this really related to descriptor tracking, though?
>

Florian, you're right, I agree it's better to transform this feature into a
new option.

>
> I would expected a separate option, with a couple of choices:
>
>   min (the POSIX default)
>   max (what you call new)
>   oldest (first no reuse; after running out of numbers, oldest close first)
>   random
>   strict-max
>   strict-oldest
>   strict-random
>
>
> I'm proposing a new option then, called --modify-fds=[no,high]
no is a default and high is what I've been calling 'new' previously.
I'm going to start with these to for the beginning and we might add
additional
options later if needed.

I'm not sure if 'random' is really needed. Florian, do you have a use for
it?

Thank you,
Alexandra

Re: [Valgrind-users] New --track-fds=new option expected behaviour

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

> I'm trying to add a new option for the --track-fds.
> https://bugs.kde.org/show_bug.cgi?id=493433 

It seems to me that --track-fds=OPTION also should be aware
of the use of multiple fds for parallel processing at shell level.
User-level shell code creates a fan-out of multiple fds,
and instantiates one process per fd, with stdin re-directed
from the corresponding fd of the fan.
Stdout of the nest of processes is fanned-in
to a common fd by redirecting stdout from each process.
Then a shell loop directs its stdout into the proper fd
for each process.  Thus the supervising shell script
chooses which process in the pool gets which input, and
each input is processed by the selected process, running
in parallel with other pool processes on other inputs.

The important point is that --track-fds in any pool process
should ignore completely the other fds in the fan-out.
Of course each process can snoop and interfere
with those fds (data is flowing through them, too)
but proper coding avoids that.  In particular, each
pool process should NOT use close_range() which might
include a fanned-out fd for a different process.
[See also the manpage for 'bash' shell, section REDIRECTION:
    Each redirection that may be preceded by a file descriptor
    number may instead be preceded by a word of the form {varname}.
    In this case, for each redirection operator except >&- and <&-,
    the shell will allocate a file descriptor greater than or equal
    to 10 and assign it to varname. ]

Re: [Valgrind-users] New --track-fds=new option expected behaviour

[Florian W. <fw...@de...>]

* Alexandra Petlanova Hajkova:

> The other question is, how should the new option be called? Is "new" a good
> name for it? Other options could be --track-fds=high or even
> --track-fds=random.

Is this really related to descriptor tracking, though?

I would expected a separate option, with a couple of choices:

  min (the POSIX default)
  max (what you call new)
  oldest (first no reuse; after running out of numbers, oldest close first)
  random
  strict-max
  strict-oldest
  strict-random

The difference between the strict-* and plain variants would be that
the plain variants check first if any of 0, 1, 2 are unallocated.  In
that case, they are like min/POSIX.  I suspect that should fix pretty
much all compatibility issues with max/oldest/random modes.

[Valgrind-users] New --track-fds=new option expected behaviour

[Alexandra P. H. <aha...@re...>]

Hi,

I'm trying to add a new option for the --track-fds.
https://bugs.kde.org/show_bug.cgi?id=493433

Normally a newly recreated file descriptor gets the lowest available
number.
This might cause old file descriptor numbers to be reused and hide bad file
descriptor accesses (because the old number is new again). When using
--track-fds=new, the highest available file descriptor will be returned
opposed
to the lowest.

The question is, how should the new 'new' option work with the other
track-fds
options. --track-fds=yes will show still opened file descriptors excluding
stdin/out/err,
while --track-fds=all will show all the open fds, including the standard
ones.

I think, when --track-fds=new is specified, what's expected is only
returning the
highest available fd instead of the lowest available one. This means, if
you also
want to track file descriptors, you should use --track-fds=new,yes. But I'm
not
sure how to deal with 'all' here. I think it's not right 'new' should be
enabled
in a case of --track-fds=all. I propose to have 'new' as a completely
separate option.
This means, if I want to track *all* the opened file descriptors (including
the standard ones)
and also to be getting the highest file descriptors available when
opening/creating them, I'll
need to use --track-fds=new,all.

The other question is, how should the new option be called? Is "new" a good
name for it? Other options could be --track-fds=high or even
--track-fds=random.

Another option that should be added is "bad".
https://bugs.kde.org/show_bug.cgi?id=493434
Currently --track-fds=yes or --track-fds=all report both bad usage and
never closed file
descriptors. Sometimes users are only interested in bad file descriptor
usage errors, but
don't care about never close file descriptors.  Instead of making them
create suppressions
 for the never closed file descriptors we could have an --track-fds=bad mod
that only reports
 errors on bad usage. I think the "bad" option should also be independent
of "all" in the
same fashion I proposed "new" to be.

Another possibility would be to to keep --track-fds=[yes,no,all] and add
new --track-bad-fds=yes,
--track-leaky-fds=yes and --track-high-fds=yes.

I'm open to any suggestions.

Thank you,
Alexandra

Re: [Valgrind-users] assert on aarch64: m_redir.c vgPlain_redir_add_ifunc_target Assertion 'old' failed (revival #327427?)

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

See more progress in https://bugs.kde.org/show_bug.cgi?id=483711#c7 .

On arm64 Linux I have 32-bit arm recognized as a Secondary architecture,
and all the pieces build for both 64-bit and 32-bit.
64-bit memcheck works. 32-bit memcheck fails with
=====
$ $HOME/local/bin/valgrind ./hello32
valgrind: m_ume.c: can't open interpreter
=====
interpreter is /lib/ld-linux.so.3.
I have /lib/ld-linux-armhf.so.3 ; perhaps I can symlink them.

Yes, it works!  Well, sort of:
ERROR: ld.so: object 
'$HOME/local/libexec/valgrind/vgpreload_core-arm-linux.so' from 
LD_PRELOAD cannot be preloaded (internal error): ignored.
ERROR: ld.so: object 
'$HOME/local/libexec/valgrind/vgpreload_memcheck-arm-linux.so' from 
LD_PRELOAD cannot be preloaded (internal error): ignored.
./a.out: /lib/libc.so.6: version `GLIBC_2.34' not found (required by 
./a.out)
==25779==
==25779== HEAP SUMMARY:
==25779==     in use at exit: 0 bytes in 0 blocks
==25779==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==25779==
==25779== All heap blocks were freed -- no leaks are possible

Re: [Valgrind-users] assert on aarch64: m_redir.c vgPlain_redir_add_ifunc_target Assertion 'old' failed (revival #327427?)

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

>  So Android kernel refused ro run the 'execve'. Must be the layout of PT_LOAD,or the
> Section table, or the symbol table, or being "-static" (no shared
> libraries), or ...
> 

Forgot to include the complete segment layout:
=====
$ readelf --segments valgrind
Elf file type is EXEC (Executable file)
Entry point 0x4003ec
There are 11 program headers, starting at offset 64

Program Headers:
   Type           Offset             VirtAddr           PhysAddr
                  FileSiz            MemSiz              Flags  Align
   PHDR      0x0000000000000040 0x0000000000400040 0x0000000000400040
             0x0000000000000268 0x0000000000000268  R      0x8
   LOAD      0x0000000000000000 0x0000000000400000 0x0000000000400000
             0x0000000000000340 0x0000000000000340  R      0x4000
   LOAD      0x0000000000000340 0x0000000000400340 0x0000000000400340
             0x000000000005086c 0x000000000005086c  R E    0x4000
   LOAD      0x0000000000050bb0 0x0000000000450bb0 0x0000000000450bb0
             0x0000000000018cb4 0x0000000000018cb4  R      0x4000
   LOAD      0x000000000006c000 0x000000000046c000 0x000000000046c000
             0x0000000000000da8 0x0000000000001000  RW     0x4000
   LOAD      0x0000000000070000 0x0000000000470000 0x0000000000470000
             0x0000000000000ba0 0x000000000001dae8  RW     0x4000
   TLS       0x000000000006c000 0x000000000046c000 0x000000000046c000
             0x0000000000000008 0x0000000000000008  R      0x40
   GNU_RELRO 0x000000000006c000 0x000000000046c000 0x000000000046c000
             0x0000000000000da8 0x0000000000001000  R      0x1
   GNU_EH_FRAME 0x0000000000057e90 0x0000000000457e90 0x0000000000457e90
                0x0000000000002d84 0x0000000000002d84  R      0x4
   GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
             0x0000000000000000 0x0000000000000000  RW     0x0
   NOTE      0x00000000000002a8 0x00000000004002a8 0x00000000004002a8
             0x0000000000000098 0x0000000000000098  R      0x4

  Section to Segment mapping:
   Segment Sections...
    00
    01     .note.android.ident
    02     .rela.plt .text
    03     .rodata .eh_frame_hdr .eh_frame
    04     .tdata .preinit_array .init_array .fini_array .data.rel.ro 
.got .relro_padding
    05     .data .bss
    06     .tdata
    07     .tdata .preinit_array .init_array .fini_array .data.rel.ro 
.got .relro_padding
    08     .eh_frame_hdr
    09
    10     .note.android.ident
=====

Re: [Valgrind-users] assert on aarch64: m_redir.c vgPlain_redir_add_ifunc_target Assertion 'old' failed (revival #327427?)

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

>> Building proceeds until
>> =====  (Note "-m32")
>> $ gcc -m64 ... -static ... -m32 -o vgpreload_core-arm-linux.so \
>>       vgpreload_core_arm_linux_so_preloaded.o
>> ld.lld: error: unable to find library -lc
>> =====
>> which I workaround by running "gcc -v ...", to get the command line,
>> then manually running the 'ld' without the "-lc".  So gcc adding
>> "-lc" was not necessary?
> 
> 
> What is the full text of the line for linking vgpreload_core-arm-linux.so?

Moving the old outputs out of the way (vgpreload_core-arm-linux.so.save
and vgpreload_core-arm64-linux.so.save), and adding "-v" to what "make"
says when run from directory 'coregrind':
=====
$ gcc -v -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith 
-Wstrict-prototypes -Wmissing-declarations -Wno-unused-result 
-Wcast-align -Wcast-qual -Wwrite-strings -Wempty-body -Wformat 
-Wformat-signedness -Wformat-security -Wignored-qualifiers 
-Wenum-conversion -finline-functions -fno-stack-protector 
-fno-strict-aliasing -fno-builtin -Wno-cast-align -Wno-self-assign 
-Wno-tautological-compare  -O -g -fno-omit-frame-pointer 
-fno-strict-aliasing -fpic -fno-builtin    -nodefaultlibs -shared 
-Wl,-z,interpose,-z,initfirst -nostdlib  -m32   -o 
vgpreload_core-arm-linux.so vgpreload_core_arm_linux_so-vg_preloaded.o
clang version 19.1.5
Target: arm-unknown-linux-android24
Thread model: posix
InstalledDir: /data/data/com.termux/files/usr/bin
  "/data/data/com.termux/files/usr/bin/ld.lld" 
--sysroot=/data/data/com.termux/files -EL -z now -z relro -z 
max-page-size=4096 -X --hash-style=gnu 
-rpath=/data/data/com.termux/files/usr/arm-linux-androideabi/lib 
--eh-frame-hdr -m armelf_linux_eabi -shared -o 
vgpreload_core-arm-linux.so 
-L/data/data/com.termux/files/usr/arm-linux-androideabi/lib 
-L/system/lib -z interpose -z initfirst 
vgpreload_core_arm_linux_so-vg_preloaded.o
=====
and it succeeded (no complaint).  So I don't know where "-lc"
came from the first time.

I also ran that gcc command under "strace -f -e trace=open,openat -o 
strace.out" to see what filenames the linker was trying.
The strace gave 212 lines that all were 'openat',
and applying "grep libc" yields
=====
22993 openat(AT_FDCWD, "/data/data/com.termux/files/usr/lib/libc.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
22993 openat(AT_FDCWD, "/system/lib64/libc.so", O_RDONLY|O_CLOEXEC) = 4
22993 openat(AT_FDCWD, 
"/data/data/com.termux/files/usr/lib/libclang-cpp.so", 
O_RDONLY|O_CLOEXEC) = 5
22993 openat(AT_FDCWD, 
"/data/data/com.termux/files/usr/lib/libc++_shared.so", 
O_RDONLY|O_CLOEXEC) = 7
22993 openat(AT_FDCWD, 
"/dev/__properties__/u:object_r:libc_debug_prop:s0", 
O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = 3
22993 openat(AT_FDCWD, "/system/lib64/libc++.so", O_RDONLY|O_CLOEXEC) = 4
22994 openat(AT_FDCWD, "/data/data/com.termux/files/usr/lib/libc.so", 
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
22994 openat(AT_FDCWD, "/system/lib64/libc.so", O_RDONLY|O_CLOEXEC) = 4
22994 openat(AT_FDCWD, 
"/data/data/com.termux/files/usr/lib/libc++_shared.so", 
O_RDONLY|O_CLOEXEC) = 8
22994 openat(AT_FDCWD, 
"/dev/__properties__/u:object_r:libc_debug_prop:s0", 
O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = 3
22994 openat(AT_FDCWD, "/system/lib64/libc++.so", O_RDONLY|O_CLOEXEC) = 4
=====

>> =====
>> $ cd coregrind
>> $ ./valgrind
>> error: "./valgrind": executable's TLS segment is underaligned: \
>> alignment is 8 (skew 0), needs to be at least 64 for ARM64 Bionic
>> Aborted
>> $ echo $?
>> 134   ## error 6 (134 - 128) ENXIO
>> $
>> =====
>>
>> So now it's time to get the linker script from "ld --verbose ...",
>> then make TLS 64-byte aligned.   To be continued ...
> 
> Do the Google/Android folks have any Valgrind patches for these issues?

I ran "ld --verbose > android.lds" [notice not the same as 'ld.lld',
which did not recognize '--verbose'],
lopped off the prefix and suffix lines marked by "==========",
and changed one line to ".tdata : align(64)".  Then
adding "-T android.lds" to the linker command line that creates
'valgrind', and applying "readelf --segments" gave
=====
   TLS       0x000000000006c000 0x000000000046c000 0x000000000046c000
             0x0000000000000008 0x0000000000000008  R      0x40
=====
which did achieve 64-byte alignment in the Elf64_Phdr for TLS.

But 'vagrind' still won't run:
=====
$ gdb -q ./valgrind
Reading symbols from ./valgrind...
(gdb) x/5i _start   ## disassemble from entry point
    0x4003ec <_start>:	bti	j  ## legal target for indirect branch
    0x4003f0 <_start+4>:	mov	x29, #0x0                   	// #0
    0x4003f4 <_start+8>:	mov	x30, #0x0                   	// #0
    0x4003f8 <_start+12>:	mov	x0, sp
    0x4003fc <_start+16>:	b	0x400400 <_start_main>
(gdb) run
Starting program: 
/data/data/com.termux/files/home/valgrind/coregrind/valgrind
During startup program terminated with signal SIGSEGV, Segmentation fault.
(gdb) info proc
No current process: you must name one.
=====
and the process is empty: no registers.  So Android kernel refused
to perform the 'execve'.  Must be the layout of PT_LOAD, or the
Section table, or the symbol table, or being "-static" (no shared
libraries), or ...

Re: [Valgrind-users] assert on aarch64: m_redir.c vgPlain_redir_add_ifunc_target Assertion 'old' failed (revival #327427?)

[Paul F. <pj...@wa...>]

On 14-12-24 04:11, John Reiser wrote:
>> I've tried to build the last release but have not resolved the place 
>> why it tries to link against the non-existing libc and how to fix that...
> 
> Here are some workarounds:
> 
> I'm trying to build valgrind (memcheck) for 32-bit programs on Android
> running under 64-bit TermUX on 64-bit Android 14.  A fully-static 32-
> bit program created under Linux on [old] RaspberryPi does run
> under TermUX on my Samsung A9-Lite tablet with 3MB RAM!  All building
> for valgrind was done on the tablet.
> 
> Starting with "git clone; ./aclocal; ./configure --prefix=...";
> then in just a few minutes "make -j4" reaches
> =====
> $ gcc ... `m_coredump/coredump-elf.c
> m_coredump/coredump-elf.c:152:4: error: typedef redefinition with 
> different types ('struct Elf32_Nhdr' vs 'struct elf32_note')
>    152 |    Elf32_Nhdr;
>        |    ^
> /data/data/com.termux/files/usr/include/linux/elf.h:380:3: note: 
> previous definition is here
>    380 | } Elf32_Nhdr;
>        |   ^
> m_coredump/coredump-elf.c:775:17: warning: variable 'name' set but not 
> used [-Wunused-but-set-variable]
>    775 |    const HChar* name;
>        |                 ^
> =====
> 
> My usr/include/elf.h from ndk-root version 27c does have a Elf32_Nhdr,
> so I patch with
> =====
> diff --git a/coregrind/m_coredump/coredump-elf.c b/coregrind/m_coredump/ 
> coredump-elf.c
> index a4632d9e2..aa58e6f48 100644
> --- a/coregrind/m_coredump/coredump-elf.c
> +++ b/coregrind/m_coredump/coredump-elf.c
> @@ -140,8 +140,8 @@ static void fill_phdr(ESZ(Phdr) *phdr, const 
> NSegment *seg, UInt off, Bool write
>      phdr->p_align = VKI_PAGE_SIZE;
>   }
> 
> -#if defined(VGPV_arm_linux_android) || defined(VGPV_x86_linux_android) \
> -    || defined(VGPV_mips32_linux_android)
> +#if 0 && ( defined(VGPV_arm_linux_android) || 
> defined(VGPV_x86_linux_android) \
> +    || defined(VGPV_mips32_linux_android))
>   /* Android's libc doesn't provide a definition for this.  Hence: */
>   typedef
>      struct {
> =====


If elf.h doesn't indicate that it has a Elf32_Nhdr then we could add a 
configure check for that. See 
https://bugs.kde.org/show_bug.cgi?id=339861. Do we need to keep 
backwards compatibility with the old systems that didn't have Elf32_Nhdr?

> Building proceeds until
> =====  (Note "-m32")
> $ gcc -m64 ... -static ... -m32 -o vgpreload_core-arm-linux.so \
>       vgpreload_core_arm_linux_so_preloaded.o
> ld.lld: error: unable to find library -lc
> =====
> which I workaround by running "gcc -v ...", to get the command line,
> then manually running the 'ld' without the "-lc".  So gcc adding
> "-lc" was not necessary?


What is the full text of the line for linking vgpreload_core-arm-linux.so?

I don't know where -lc is coming from, maybe implicitly with lld and it 
needs -nostdlib.

Also I don't see how both -m32 and -m64 get added. In this case it seems 
harmless as the later -m32 will be taken.


> More building until (in directory coregrind):
> =====   (Note no "-m32")
> $ gcc -m64 ... -static ... -o valgrind \
>       valgrind-launcher-linux.o valgrind-m_debuglog.o
> ld.lld: error: unable to find library -lc
> =====
> 
> Next "dpkg --search libc.a" shows a nice-looking
>     usr/opt/ndk-multilib/aarch64-linux-android/lib/libc.a
> and manually adding that appears to succeed:
> =====
> $ cd /data/data/com.termux/files/home/valgrind/coregrind
> $ ld -o valgrind  valgrind-launcher-linux.o valgrind-m_debuglog.o \
> 
> /data/data/com.termux/files/usr/opt/ndk-multilib/aarch64-linux-android/ 
> lib/libc.a
> $ readelf --all --wide valgrind >valgrind.readelfcd ..
>     # 5744 lines; 10 Program headers; 29 Sections
> # Header      Offset   VirtAddr  PhysAddr  Fsiz  Msiz Flg  Align
> #  TLS       0x069870  0x271870  0x271870     8     8   R  0x8
> =====
> 
> But a trial run fails:
> =====
> $ cd coregrind
> $ ./valgrind
> error: "./valgrind": executable's TLS segment is underaligned: \
> alignment is 8 (skew 0), needs to be at least 64 for ARM64 Bionic
> Aborted
> $ echo $?
> 134   ## error 6 (134 - 128) ENXIO
> $
> =====
> 
> So now it's time to get the linker script from "ld --verbose ...",
> then make TLS 64-byte aligned.   To be continued ...

Do the Google/Android folks have any Valgrind patches for these issues?

A+
Paul

Re: [Valgrind-users] assert on aarch64: m_redir.c vgPlain_redir_add_ifunc_target Assertion 'old' failed (revival #327427?)

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

> I've tried to build the last release but have not resolved the place why 
> it tries to link against the non-existing libc and how to fix that...

Here are some workarounds:

I'm trying to build valgrind (memcheck) for 32-bit programs on Android
running under 64-bit TermUX on 64-bit Android 14.  A fully-static 32-
bit program created under Linux on [old] RaspberryPi does run
under TermUX on my Samsung A9-Lite tablet with 3MB RAM!  All building
for valgrind was done on the tablet.

Starting with "git clone; ./aclocal; ./configure --prefix=...";
then in just a few minutes "make -j4" reaches
=====
$ gcc ... `m_coredump/coredump-elf.c
m_coredump/coredump-elf.c:152:4: error: typedef redefinition with 
different types ('struct Elf32_Nhdr' vs 'struct elf32_note')
   152 |    Elf32_Nhdr;
       |    ^
/data/data/com.termux/files/usr/include/linux/elf.h:380:3: note: 
previous definition is here
   380 | } Elf32_Nhdr;
       |   ^
m_coredump/coredump-elf.c:775:17: warning: variable 'name' set but not 
used [-Wunused-but-set-variable]
   775 |    const HChar* name;
       |                 ^
=====

My usr/include/elf.h from ndk-root version 27c does have a Elf32_Nhdr,
so I patch with
=====
diff --git a/coregrind/m_coredump/coredump-elf.c 
b/coregrind/m_coredump/coredump-elf.c
index a4632d9e2..aa58e6f48 100644
--- a/coregrind/m_coredump/coredump-elf.c
+++ b/coregrind/m_coredump/coredump-elf.c
@@ -140,8 +140,8 @@ static void fill_phdr(ESZ(Phdr) *phdr, const 
NSegment *seg, UInt off, Bool write
     phdr->p_align = VKI_PAGE_SIZE;
  }

-#if defined(VGPV_arm_linux_android) || defined(VGPV_x86_linux_android) \
-    || defined(VGPV_mips32_linux_android)
+#if 0 && ( defined(VGPV_arm_linux_android) || 
defined(VGPV_x86_linux_android) \
+    || defined(VGPV_mips32_linux_android))
  /* Android's libc doesn't provide a definition for this.  Hence: */
  typedef
     struct {
=====

Building proceeds until
=====  (Note "-m32")
$ gcc -m64 ... -static ... -m32 -o vgpreload_core-arm-linux.so \
      vgpreload_core_arm_linux_so_preloaded.o
ld.lld: error: unable to find library -lc
=====
which I workaround by running "gcc -v ...", to get the command line,
then manually running the 'ld' without the "-lc".  So gcc adding
"-lc" was not necessary?

More building until (in directory coregrind):
=====   (Note no "-m32")
$ gcc -m64 ... -static ... -o valgrind \
      valgrind-launcher-linux.o valgrind-m_debuglog.o
ld.lld: error: unable to find library -lc
=====

Next "dpkg --search libc.a" shows a nice-looking
    usr/opt/ndk-multilib/aarch64-linux-android/lib/libc.a
and manually adding that appears to succeed:
=====
$ cd /data/data/com.termux/files/home/valgrind/coregrind
$ ld -o valgrind  valgrind-launcher-linux.o valgrind-m_debuglog.o \
 
/data/data/com.termux/files/usr/opt/ndk-multilib/aarch64-linux-android/lib/libc.a
$ readelf --all --wide valgrind >valgrind.readelfcd ..
    # 5744 lines; 10 Program headers; 29 Sections
# Header      Offset   VirtAddr  PhysAddr  Fsiz  Msiz Flg  Align
#  TLS       0x069870  0x271870  0x271870     8     8   R  0x8
=====

But a trial run fails:
=====
$ cd coregrind
$ ./valgrind
error: "./valgrind": executable's TLS segment is underaligned: \
alignment is 8 (skew 0), needs to be at least 64 for ARM64 Bionic
Aborted
$ echo $?
134   ## error 6 (134 - 128) ENXIO
$
=====

So now it's time to get the linker script from "ld --verbose ...",
then make TLS 64-byte aligned.   To be continued ...

Re: [Valgrind-users] assert on aarch64: m_redir.c vgPlain_redir_add_ifunc_target Assertion 'old' failed (revival #327427?)

[Paul F. <pj...@wa...>]

On 13/12/2024 16:26, Simon Sobisch wrote:
> Daear valgrind users and devs,
>
> Valgrind-3.22.0 and asserts reproducible on 
> aarch64-unknown-linux-android (with several applications) as follows:
>
> valgrind: 
> /home/builder/.termux-build/valgrind/src/coregrind/m_redir.c:796 (void 
> vgPlain_redir_add_ifunc_target(Addr, Addr)): Assertion 'old' failed.

This does look like https://bugs.kde.org/show_bug.cgi?id=327427

>
> host stacktrace:
> ==27034==    at 0x5802EB10: ??? (in 
> /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
> ==27034==    by 0x5802EE4B: ??? (in 
> /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
> ==27034==    by 0x5802EE27: ??? (in 
> /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
> ==27034==    by 0x58041BB3: ??? (in 
> /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
> ==27034==    by 0x5809247B: ??? (in 
> /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
> ==27034==    by 0x580A180B: ??? (in 
> /data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
> ==27034==    by 0xFFFFFFFFFFFFFFFF: ???
>
Unfortunately Valgrind has failed to read its own debuginfo, so this not 
much use to us.


> sched status:
>   running_tid=1
>
> Thread 1: status = VgTs_Runnable (lwpid 27034)
> ==27034==    at 0x5DE8460: ??? (in 
> /data/data/com.termux/files/usr/libexec/valgrind/vgpreload_core-arm64-linux.so)
> client stack range: [0x1FFEFF9000 0x1FFF000FFF] client SP: 0x1FFEFFCAC0
> valgrind stack range: [0x1002CBC000 0x1002DBBFFF] top usage: 12432 of 
> 1048576
>
>
> Following the output of the assert I've found
>     https://bugs.kde.org/show_bug.cgi?id=327427
> but the test w/wo --keep-debuginfos=yes / no showed the same 
> stacktrace in this case.
>
--keep-debuginfo, IIRC, is only related to keeping debuginfo for shared 
libraries that get loaded and unoaded.


> The application does not show any errors in other environments.
>
> In this environment we get a bunch of warnings
>    Conditional jump or move depends on uninitialised value(s)
>    Use of uninitialised value of size 8


You need to analyze them.


> in C posix functions from the binary 
> /apex/com.android.runtime/bin/linker64 (memcpy, strlen, ...) which I 
> _guess_ is not related to this error.
>

That could be due to Valgrind not redirecting those functions.


> Is there something that's "known" which I've overlooked (FAQ has no 
> entries on this, changelog from newer versions did not show anything 
> that seems related)?
>
>
> I've tried to build the last release but have not resolved the place 
> why it tries to link against the non-existing libc and how to fix that...
>

Sorry, but we don't have anyone that uses Android working on Valgrind as 
far as I know. Not much has been done that is Android specific for quite 
a while. aarch64 is getting some fixes and enhancements.


A+

Paul

[Valgrind-users] assert on aarch64: m_redir.c vgPlain_redir_add_ifunc_target Assertion 'old' failed (revival #327427?)

[Simon S. <sim...@gn...>]

Daear valgrind users and devs,

Valgrind-3.22.0 and asserts reproducible on 
aarch64-unknown-linux-android (with several applications) as follows:

valgrind: 
/home/builder/.termux-build/valgrind/src/coregrind/m_redir.c:796 (void 
vgPlain_redir_add_ifunc_target(Addr, Addr)): Assertion 'old' failed.

host stacktrace:
==27034==    at 0x5802EB10: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0x5802EE4B: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0x5802EE27: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0x58041BB3: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0x5809247B: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0x580A180B: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/memcheck-arm64-linux)
==27034==    by 0xFFFFFFFFFFFFFFFF: ???

sched status:
   running_tid=1

Thread 1: status = VgTs_Runnable (lwpid 27034)
==27034==    at 0x5DE8460: ??? (in 
/data/data/com.termux/files/usr/libexec/valgrind/vgpreload_core-arm64-linux.so)
client stack range: [0x1FFEFF9000 0x1FFF000FFF] client SP: 0x1FFEFFCAC0
valgrind stack range: [0x1002CBC000 0x1002DBBFFF] top usage: 12432 of 
1048576


Following the output of the assert I've found
     https://bugs.kde.org/show_bug.cgi?id=327427
but the test w/wo --keep-debuginfos=yes / no showed the same stacktrace 
in this case.


The application does not show any errors in other environments.

In this environment we get a bunch of warnings
    Conditional jump or move depends on uninitialised value(s)
    Use of uninitialised value of size 8
in C posix functions from the binary 
/apex/com.android.runtime/bin/linker64 (memcpy, strlen, ...) which I 
_guess_ is not related to this error.


Is there something that's "known" which I've overlooked (FAQ has no 
entries on this, changelog from newer versions did not show anything 
that seems related)?


I've tried to build the last release but have not resolved the place why 
it tries to link against the non-existing libc and how to fix that...


Any hints on the bug issue (or the linking) welcome,
Simon

Re: [Valgrind-users] Valgrind taking a lot of time trying to determine if there are memory leaks before it prints "leak summary".

[Wojciech B. <woj...@gm...>]

Hello again,

I was able to figure out the problem.

It turns out this range:
scan 0x53c4000-0x14dc4000 (262144000)
--00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel

Corresponds to the area that the application obtains with mmap().
It reserves 250 MB of memory and mmap() returns success both in the VM
and in the container.
Then the application checks if the whole region is accessible by
gradually memsetting it to 0, intercepting SIGSEGV and SIGBUS signals,
and then reporting how much of that range it was able to zero.
It turns out that in the case of the container, only 64MB of that is
accessible, and the application reports that as a warning that I
missed.
This limit is just a default docker uses.

All started working as soon as I specified shm_size=256MB in my docker
compose file.

Thank you for your help.

Kind regards,
Wojciech

On Tue, Dec 10, 2024 at 10:22 AM Wojciech Bocer
<woj...@gm...> wrote:
>
> Hello again,
>
> Thank both of you John and Paul for helping me out.
>
> I changed the mentioned macros and compiled valgrind. The outcome of
> the test is the same. However I can see additional debug output in the
> logs.
>
> There is a repeating pattern, Valgrind scans the same memory region
> and something happens there:
> scan 0x4fc1000-0x4fc4000 (12288)
> scan 0x53c4000-0x14dc4000 (262144000)
> --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2,
> EIP=0x0, eip=0x58002e8d, from kernel
>
> Now the valgrind will repeatedly output the last line.
>
> Below are some logs from 3 processes that produce extensive log files.
>
> Kind regards,
> Wojciech
>
> 1. Log file for process 3477 (260MB when valgrind killed):
>
> ==00:00:00:01.741 3477== Memcheck, a memory error detector
> ==00:00:00:01.741 3477== Copyright (C) 2002-2024, and GNU GPL'd, by
> Julian Seward et al.
> ==00:00:00:01.741 3477== Using Valgrind-3.24.0-fcdaa47426-20241101X
> and LibVEX; rerun with -h for copyright info
> ==00:00:00:01.741 3477== Command: bin/gm_server --master
> XXXXXXXXXXXXXXXXXXXXXXXX
> ==00:00:00:01.741 3477== Parent PID: 3461
> ==00:00:00:01.741 3477==
> --00:00:00:01.741 3477--
> --00:00:00:01.741 3477-- Valgrind options:
> --00:00:00:01.741 3477--    --log-file=/tmp/valgrind/memcheck-%p.log
> --00:00:00:01.741 3477--    --tool=memcheck
> --00:00:00:01.741 3477--    --leak-check=summary
> --00:00:00:01.741 3477--    --time-stamp=yes
> --00:00:00:01.741 3477--    --track-fds=no
> --00:00:00:01.741 3477--    --trace-signals=yes
> --00:00:00:01.741 3477--    --track-origins=no
> --00:00:00:01.741 3477--    --trace-children=yes
> --00:00:00:01.741 3477--
> --trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc
> --00:00:00:01.741 3477--    --vgdb=no
> --00:00:00:01.741 3477--    --error-limit=no
> --00:00:00:01.741 3477--    --verbose
> --00:00:00:01.741 3477-- Contents of /proc/version:
> --00:00:00:01.741 3477--   Linux version 6.11.9-100.fc39.x86_64
> (mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1
> 20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP
> PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024
> --00:00:00:01.741 3477--
> --00:00:00:01.741 3477-- Arch and hwcaps: X86, LittleEndian,
> x86-mmxext-sse1-sse2-sse3-lzcnt
> --00:00:00:01.741 3477-- Page sizes: currently 4096, max supported 4096
> --00:00:00:01.741 3477-- Valgrind library directory: /usr/local/libexec/valgrind
> --00:00:00:01.750 3477-- sys_sigaction: sigNo 12, new 0xfeae4d34, old
> 0x0, new flags 0x4000000
> --00:00:00:01.750 3477-- sys_sigaction: sigNo 10, new 0xfeae4d34, old
> 0x0, new flags 0x4000000
> --00:00:00:01.751 3477-- sys_sigaction: sigNo 15, new 0xfeae4d34, old
> 0x0, new flags 0x4000000
> --00:00:00:01.752 3477-- sys_sigaction: sigNo 13, new 0xfeae4d34, old
> 0x0, new flags 0x4000000
> --00:00:00:01.752 3477-- sys_sigaction: sigNo 2, new 0xfeae4d34, old
> 0x0, new flags 0x4000000
> --00:00:00:01.753 3477-- sys_sigaction: sigNo 17, new 0xfeae4d34, old
> 0x0, new flags 0x4000000
> --00:00:00:01.754 3477-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
> newset = 0x0 (NULL)
> --00:00:00:01.754 3477--        oldset=0xFEAE4FCC 0000000000000000
> --00:00:00:01.757 3477-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
> newset = 0xFEAE4EA0 (fffffffe7ffee115)
> --00:00:01:42.040 3477-- sys_sigaction: sigNo 11, new 0x82cfdeec, old
> 0x0, new flags 0x0
> --00:00:01:42.040 3477-- sys_sigaction: sigNo 7, new 0x82cfdeec, old
> 0x0, new flags 0x0
> --00:00:01:42.040 3477-- sys_sigaction: sigNo 4, new 0x82cfdee4, old
> 0x0, new flags 0x0
> --00:00:01:42.040 3477-- sys_sigaction: sigNo 8, new 0x82cfdee4, old
> 0x0, new flags 0x0
> --00:00:01:42.040 3477-- sys_sigaction: sigNo 31, new 0x82cfdedc, old
> 0x0, new flags 0x0
> ==00:00:01:42.065 3477==
> ==00:00:01:42.065 3477== HEAP SUMMARY:
> ==00:00:01:42.065 3477==     in use at exit: 2,440 bytes in 378 blocks
> ==00:00:01:42.065 3477==   total heap usage: 3,807 allocs, 3,429
> frees, 430,504 bytes allocated
> ==00:00:01:42.065 3477==
> ==00:00:01:42.065 3477== Searching for pointers to 378 not-freed blocks
> scan 0x30d000-0x5d4000 (2912256)
> ptr=0x502ac10 -> block 368
> ptr=0x503b100 -> block 373
> ptr=0x50200b0 -> block 299
> ptr=0x5020150 -> block 301
> ptr=0x50201f0 -> block 303
> ptr=0x5020600 -> block 316
> ptr=0x5020560 -> block 314
> ptr=0x503b160 -> block 374
> ptr=0x501fcf0 -> block 287
> ptr=0x501fd90 -> block 289
> ptr=0x501fc50 -> block 285
> ptr=0x503b100 -> block 373
> ptr=0x5018d80 -> block 0
> ptr=0x5018dd0 -> block 1
> ptr=0x5018e20 -> block 2
> ptr=0x5018e70 -> block 3
> ptr=0x5018ed0 -> block 4
> ptr=0x5018f40 -> block 5
> ptr=0x5018f90 -> block 6
> ptr=0x5018fe0 -> block 7
> ptr=0x5019030 -> block 8
> ptr=0x5019080 -> block 9
> ptr=0x50190d0 -> block 10
> ...
> ptr=0x503b3b0 -> block 376
> ptr=0x501a0f3 -> block 61
> scan 0x5d4000-0x5dd000 (36864)
> ptr=0x502ac10 -> block 368
> ptr=0x5024b70 -> block 352
> ptr=0x502a9d0 -> block 364
> ptr=0x502aa70 -> block 365
> ptr=0x502aa70 -> block 365
> ptr=0x502aac0 -> block 366
> ptr=0x501d850 -> block 236
> ptr=0x501d8a0 -> block 237
> scan 0x4036000-0x4037000 (4096)
> scan 0x4037000-0x4038000 (4096)
> scan 0x4837000-0x4839000 (8192)
> scan 0x483d000-0x483e000 (4096)
> scan 0x4858000-0x4859000 (4096)
> scan 0x4861000-0x4862000 (4096)
> scan 0x4872000-0x4873000 (4096)
> scan 0x4873000-0x4875000 (8192)
> scan 0x494c000-0x494f000 (12288)
> scan 0x494f000-0x4950000 (4096)
> scan 0x4d97000-0x4d99000 (8192)
> scan 0x4d99000-0x4d9b000 (8192)
> scan 0x4db8000-0x4db9000 (4096)
> scan 0x4fb2000-0x4fb3000 (4096)
> scan 0x4fb3000-0x4fb8000 (20480)
> scan 0x4fbc000-0x4fbd000 (4096)
> scan 0x4fc1000-0x4fc4000 (12288)
> scan 0x53c4000-0x14dc4000 (262144000)
> --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2,
> EIP=0x0, eip=0x58002e8d, from kernel
> --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2,
> EIP=0x0, eip=0x58002e8d, from kernel
> --00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2,
> EIP=0x0, eip=0x58002e8d, from kernel
>
> 2. Log file for process 3479 (335MB when valgrind killed):
>
> ==00:00:00:01.749 3479== Memcheck, a memory error detector
> ==00:00:00:01.749 3479== Copyright (C) 2002-2024, and GNU GPL'd, by
> Julian Seward et al.
> ==00:00:00:01.749 3479== Using Valgrind-3.24.0-fcdaa47426-20241101X
> and LibVEX; rerun with -h for copyright info
> ==00:00:00:01.749 3479== Command: bin/gm_server --master
> XXXXXXXXXXXXXXXXXXXXXXXX
> ==00:00:00:01.749 3479== Parent PID: 3461
> ==00:00:00:01.749 3479==
> --00:00:00:01.749 3479--
> --00:00:00:01.749 3479-- Valgrind options:
> --00:00:00:01.749 3479--    --log-file=/tmp/valgrind/memcheck-%p.log
> --00:00:00:01.749 3479--    --tool=memcheck
> --00:00:00:01.749 3479--    --leak-check=summary
> --00:00:00:01.749 3479--    --time-stamp=yes
> --00:00:00:01.749 3479--    --track-fds=no
> --00:00:00:01.749 3479--    --trace-signals=yes
> --00:00:00:01.749 3479--    --track-origins=no
> --00:00:00:01.749 3479--    --trace-children=yes
> --00:00:00:01.749 3479--
> --trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc
> --00:00:00:01.749 3479--    --vgdb=no
> --00:00:00:01.749 3479--    --error-limit=no
> --00:00:00:01.749 3479--    --verbose
> --00:00:00:01.749 3479-- Contents of /proc/version:
> --00:00:00:01.749 3479--   Linux version 6.11.9-100.fc39.x86_64
> (mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1
> 20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP
> PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024
> --00:00:00:01.749 3479--
> --00:00:00:01.749 3479-- Arch and hwcaps: X86, LittleEndian,
> x86-mmxext-sse1-sse2-sse3-lzcnt
> --00:00:00:01.749 3479-- Page sizes: currently 4096, max supported 4096
> --00:00:00:01.749 3479-- Valgrind library directory: /usr/local/libexec/valgrind
> --00:00:00:01.759 3479-- sys_sigaction: sigNo 12, new 0xfeae4cf4, old
> 0x0, new flags 0x4000000
> --00:00:00:01.759 3479-- sys_sigaction: sigNo 10, new 0xfeae4cf4, old
> 0x0, new flags 0x4000000
> --00:00:00:01.759 3479-- sys_sigaction: sigNo 15, new 0xfeae4cf4, old
> 0x0, new flags 0x4000000
> --00:00:00:01.760 3479-- sys_sigaction: sigNo 13, new 0xfeae4cf4, old
> 0x0, new flags 0x4000000
> --00:00:00:01.760 3479-- sys_sigaction: sigNo 2, new 0xfeae4cf4, old
> 0x0, new flags 0x4000000
> --00:00:00:01.760 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
> newset = 0x0 (NULL)
> --00:00:00:01.760 3479--        oldset=0xFEAE4FBC 0000000000000000
> --00:00:00:01.762 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
> newset = 0xFEAE4E60 (fffffffe7fffe115)
> --00:00:00:01.765 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
> newset = 0xFEAE4FBC (0000000000000000)
> --00:00:01:33.725 3479-- async signal handler: signal=15, vgtid=3479,
> tid=1, si_code=0, exitreason VgSrc_None
> --00:00:01:33.725 3479-- interrupted_syscall: tid=1, ip=0x580d540d,
> restart=False, sres.isErr=True, sres.val=4
> --00:00:01:33.725 3479--   completed, but uncommitted: committing
> --00:00:01:33.725 3479-- delivering signal 15 (SIGTERM):0 to thread 1
> --00:00:01:33.725 3479-- push_signal_frame (thread 1): signal 15
> ==00:00:01:33.725 3479==    at 0x4E6D47B: __clock_nanosleep_time64
> (clock_nanosleep.c:62)
> ==00:00:01:33.725 3479==    by 0x4E80024: __nanosleep64 (nanosleep.c:25)
> ==00:00:01:33.725 3479==    by 0x4E80024: nanosleep (nanosleep.c:42)
> ==00:00:01:33.725 3479==    by 0x4E92263: sleep (sleep.c:55)
> ==00:00:01:33.725 3479==    by 0x1CF4A9: harmony_process (harmony.c:1320)
> ==00:00:01:33.725 3479==    by 0x1D0E02: harmony_run (harmony.c:1811)
> ==00:00:01:33.725 3479==    by 0x29BDC3: main (main.c:1054)
> --00:00:01:33.726 3479-- VG_(sigframe_destroy) (thread 1): isRT=0
> valid magic; EIP=0x401b002
> --00:00:01:33.818 3479-- sys_sigaction: sigNo 11, new 0x82cfdeec, old
> 0x0, new flags 0x0
> --00:00:01:33.818 3479-- sys_sigaction: sigNo 7, new 0x82cfdeec, old
> 0x0, new flags 0x0
> --00:00:01:33.818 3479-- sys_sigaction: sigNo 4, new 0x82cfdee4, old
> 0x0, new flags 0x0
> --00:00:01:33.818 3479-- sys_sigaction: sigNo 8, new 0x82cfdee4, old
> 0x0, new flags 0x0
> --00:00:01:33.818 3479-- sys_sigaction: sigNo 31, new 0x82cfdedc, old
> 0x0, new flags 0x0
> ==00:00:01:33.833 3479==
> ==00:00:01:33.833 3479== HEAP SUMMARY:
> ==00:00:01:33.833 3479==     in use at exit: 2,440 bytes in 378 blocks
> ==00:00:01:33.833 3479==   total heap usage: 3,810 allocs, 3,432
> frees, 452,136 bytes allocated
> ==00:00:01:33.833 3479==
> ==00:00:01:33.833 3479== Searching for pointers to 378 not-freed blocks
> scan 0x30d000-0x5d4000 (2912256)
> ptr=0x502ac10 -> block 368
> ptr=0x503b100 -> block 373
> ptr=0x50200b0 -> block 299
> ptr=0x5020150 -> block 301
> ptr=0x50201f0 -> block 303
> ptr=0x5020600 -> block 316
> ptr=0x5020560 -> block 314
> ptr=0x503b160 -> block 374
> ptr=0x501fcf0 -> block 287
> ptr=0x501fd90 -> block 289
> ptr=0x501fc50 -> block 285
> ptr=0x503b100 -> block 373
> ptr=0x5018d80 -> block 0
> ptr=0x5018dd0 -> block 1
> ptr=0x5018e20 -> block 2
> ptr=0x5018e70 -> block 3
> ptr=0x5018ed0 -> block 4
> ptr=0x5018f40 -> block 5
> ptr=0x5018f90 -> block 6
> ptr=0x5018fe0 -> block 7
> ptr=0x5019030 -> block 8
> ptr=0x5019080 -> block 9
> ptr=0x50190d0 -> block 10
> ...
> ptr=0x503b3b0 -> block 376
> ptr=0x501a0f3 -> block 61
> scan 0x5d4000-0x5dd000 (36864)
> ptr=0x502ac10 -> block 368
> ptr=0x5024b70 -> block 352
> ptr=0x502a9d0 -> block 364
> ptr=0x502aa70 -> block 365
> ptr=0x502aa70 -> block 365
> ptr=0x502aac0 -> block 366
> ptr=0x501d850 -> block 236
> ptr=0x501d8a0 -> block 237
> scan 0x4036000-0x4037000 (4096)
> scan 0x4037000-0x4038000 (4096)
> scan 0x4837000-0x4839000 (8192)
> scan 0x483d000-0x483e000 (4096)
> scan 0x4858000-0x4859000 (4096)
> scan 0x4861000-0x4862000 (4096)
> scan 0x4872000-0x4873000 (4096)
> scan 0x4873000-0x4875000 (8192)
> scan 0x494c000-0x494f000 (12288)
> scan 0x494f000-0x4950000 (4096)
> scan 0x4d97000-0x4d99000 (8192)
> scan 0x4d99000-0x4d9b000 (8192)
> scan 0x4db8000-0x4db9000 (4096)
> scan 0x4fb2000-0x4fb3000 (4096)
> scan 0x4fb3000-0x4fb8000 (20480)
> scan 0x4fbc000-0x4fbd000 (4096)
> scan 0x4fc1000-0x4fc4000 (12288)
> scan 0x53c4000-0x14dc4000 (262144000)
> --00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2,
> EIP=0x0, eip=0x58002e8d, from kernel
> --00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2,
> EIP=0x0, eip=0x58002e8d, from kernel
> --00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2,
> EIP=0x0, eip=0x58002e8d, from kernel
>
> 3. Log file for process 3491 (142MB when valgrind killed):
>
> ==00:00:00:02.218 3491== Memcheck, a memory error detector
> ==00:00:00:02.218 3491== Copyright (C) 2002-2024, and GNU GPL'd, by
> Julian Seward et al.
> ==00:00:00:02.218 3491== Using Valgrind-3.24.0-fcdaa47426-20241101X
> and LibVEX; rerun with -h for copyright info
> ==00:00:00:02.218 3491== Command: bin/gm_server --master
> XXXXXXXXXXXXXXXXXXXXXXXX
> ==00:00:00:02.218 3491== Parent PID: 3461
> ==00:00:00:02.218 3491==
> --00:00:00:02.218 3491--
> --00:00:00:02.218 3491-- Valgrind options:
> --00:00:00:02.218 3491--    --log-file=/tmp/valgrind/memcheck-%p.log
> --00:00:00:02.218 3491--    --tool=memcheck
> --00:00:00:02.218 3491--    --leak-check=summary
> --00:00:00:02.218 3491--    --time-stamp=yes
> --00:00:00:02.218 3491--    --track-fds=no
> --00:00:00:02.218 3491--    --trace-signals=yes
> --00:00:00:02.218 3491--    --track-origins=no
> --00:00:00:02.218 3491--    --trace-children=yes
> --00:00:00:02.218 3491--
> --trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc
> --00:00:00:02.218 3491--    --vgdb=no
> --00:00:00:02.218 3491--    --error-limit=no
> --00:00:00:02.218 3491--    --verbose
> --00:00:00:02.218 3491-- Contents of /proc/version:
> --00:00:00:02.218 3491--   Linux version 6.11.9-100.fc39.x86_64
> (mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1
> 20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP
> PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024
> --00:00:00:02.218 3491--
> --00:00:00:02.218 3491-- Arch and hwcaps: X86, LittleEndian,
> x86-mmxext-sse1-sse2-sse3-lzcnt
> --00:00:00:02.218 3491-- Page sizes: currently 4096, max supported 4096
> --00:00:00:02.218 3491-- Valgrind library directory: /usr/local/libexec/valgrind
> --00:00:00:02.227 3491-- sys_sigaction: sigNo 12, new 0xfeae4d04, old
> 0x0, new flags 0x4000000
> --00:00:00:02.228 3491-- sys_sigaction: sigNo 10, new 0xfeae4d04, old
> 0x0, new flags 0x4000000
> --00:00:00:02.228 3491-- sys_sigaction: sigNo 15, new 0xfeae4d04, old
> 0x0, new flags 0x4000000
> --00:00:00:02.229 3491-- sys_sigaction: sigNo 13, new 0xfeae4d04, old
> 0x0, new flags 0x4000000
> --00:00:00:02.229 3491-- sys_sigaction: sigNo 2, new 0xfeae4d04, old
> 0x0, new flags 0x4000000
> --00:00:00:02.229 3491-- sys_sigaction: sigNo 17, new 0xfeae4d04, old
> 0x0, new flags 0x4000000
> --00:00:00:02.230 3491-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
> newset = 0x0 (NULL)
> --00:00:00:02.230 3491--        oldset=0xFEAE4FBC 0000000000000000
> --00:00:00:02.231 3491-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
> newset = 0xFEAE4E70 (fffffffe7ffee115)
> --00:00:02:02.494 3491-- sys_sigaction: sigNo 11, new 0x82cfdeec, old
> 0x0, new flags 0x0
> --00:00:02:02.494 3491-- sys_sigaction: sigNo 7, new 0x82cfdeec, old
> 0x0, new flags 0x0
> --00:00:02:02.494 3491-- sys_sigaction: sigNo 4, new 0x82cfdee4, old
> 0x0, new flags 0x0
> --00:00:02:02.494 3491-- sys_sigaction: sigNo 8, new 0x82cfdee4, old
> 0x0, new flags 0x0
> --00:00:02:02.494 3491-- sys_sigaction: sigNo 31, new 0x82cfdedc, old
> 0x0, new flags 0x0
> ==00:00:02:02.525 3491==
> ==00:00:02:02.525 3491== HEAP SUMMARY:
> ==00:00:02:02.525 3491==     in use at exit: 20,649 bytes in 576 blocks
> ==00:00:02:02.525 3491==   total heap usage: 5,562 allocs, 4,986
> frees, 595,523 bytes allocated
> ==00:00:02:02.525 3491==
> ==00:00:02:02.526 3491== Searching for pointers to 576 not-freed blocks
> scan 0x30d000-0x5d4000 (2912256)
> ptr=0x502ac10 -> block 377
> ptr=0x503b100 -> block 382
> ptr=0x50200b0 -> block 308
> ptr=0x5020150 -> block 310
> ptr=0x50201f0 -> block 312
> ptr=0x5020600 -> block 325
> ptr=0x5020560 -> block 323
> ptr=0x503b160 -> block 383
> ptr=0x501fcf0 -> block 296
> ptr=0x501fd90 -> block 298
> ptr=0x501fc50 -> block 294
> ptr=0x503b100 -> block 382
> ptr=0x5018d80 -> block 9
> ptr=0x5018dd0 -> block 10
> ...
> ptr=0x50b2770 -> block 558
> ptr=0x50b2880 -> block 560
> ptr=0x50b14d0 -> block 539
> ptr=0x50b09b0 -> block 538
> ptr=0x50a2f40 -> block 499
> scan 0x4036000-0x4037000 (4096)
> scan 0x4037000-0x4038000 (4096)
> scan 0x4837000-0x4839000 (8192)
> scan 0x483d000-0x483e000 (4096)
> scan 0x4858000-0x4859000 (4096)
> scan 0x4861000-0x4862000 (4096)
> scan 0x4872000-0x4873000 (4096)
> scan 0x4873000-0x4875000 (8192)
> scan 0x494c000-0x494f000 (12288)
> scan 0x494f000-0x4950000 (4096)
> scan 0x4d97000-0x4d99000 (8192)
> scan 0x4d99000-0x4d9b000 (8192)
> scan 0x4db8000-0x4db9000 (4096)
> scan 0x4fb2000-0x4fb3000 (4096)
> scan 0x4fb3000-0x4fb8000 (20480)
> scan 0x4fbc000-0x4fbd000 (4096)
> scan 0x4fc1000-0x4fc4000 (12288)
> scan 0x53c4000-0x14dc4000 (262144000)
> --00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2,
> EIP=0x0, eip=0x58002e8d, from kernel
> --00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2,
> EIP=0x0, eip=0x58002e8d, from kernel
> --00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2,
> EIP=0x0, eip=0x58002e8d, from kernel
>
> On Mon, Dec 9, 2024 at 8:28 AM Paul Floyd via Valgrind-users
> <val...@li...> wrote:
> >
> >
> >
> > On 05-12-24 14:19, Wojciech Bocer wrote:
> > > Hello,
> > >
> > > I have a problem with Valgrind taking a lot of time trying to
> > > determine if there are memory leaks before it exits.
> >
> >
> > Roughly speaking leak detection involves scanning though all accessible
> > memory using pointer-size alignment to look for any pointers to unfreed
> > memory blocks. This code does handle segfaults.
> >
> > I don't have any real idea why the combination of x86 and Docker gives
> > large numbers of segfaults and a major slowdown.
> >
> > I suggest that you get the source for Valgrind and set these macros in
> > mc_leakcheck.c to 1
> >
> >
> > // Define to debug the memory-leak-detector.
> > #define VG_DEBUG_FIND_CHUNK 0
> > #define VG_DEBUG_LEAKCHECK 0
> > #define VG_DEBUG_CLIQUE    0
> >
> > and then build Valgrind.
> >
> > A+
> > Paul
> >
> >
> >
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind taking a lot of time trying to determine if there are memory leaks before it prints "leak summary".

[Wojciech B. <woj...@gm...>]

Hello again,

Thank both of you John and Paul for helping me out.

I changed the mentioned macros and compiled valgrind. The outcome of
the test is the same. However I can see additional debug output in the
logs.

There is a repeating pattern, Valgrind scans the same memory region
and something happens there:
scan 0x4fc1000-0x4fc4000 (12288)
scan 0x53c4000-0x14dc4000 (262144000)
--00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel

Now the valgrind will repeatedly output the last line.

Below are some logs from 3 processes that produce extensive log files.

Kind regards,
Wojciech

1. Log file for process 3477 (260MB when valgrind killed):

==00:00:00:01.741 3477== Memcheck, a memory error detector
==00:00:00:01.741 3477== Copyright (C) 2002-2024, and GNU GPL'd, by
Julian Seward et al.
==00:00:00:01.741 3477== Using Valgrind-3.24.0-fcdaa47426-20241101X
and LibVEX; rerun with -h for copyright info
==00:00:00:01.741 3477== Command: bin/gm_server --master
XXXXXXXXXXXXXXXXXXXXXXXX
==00:00:00:01.741 3477== Parent PID: 3461
==00:00:00:01.741 3477==
--00:00:00:01.741 3477--
--00:00:00:01.741 3477-- Valgrind options:
--00:00:00:01.741 3477--    --log-file=/tmp/valgrind/memcheck-%p.log
--00:00:00:01.741 3477--    --tool=memcheck
--00:00:00:01.741 3477--    --leak-check=summary
--00:00:00:01.741 3477--    --time-stamp=yes
--00:00:00:01.741 3477--    --track-fds=no
--00:00:00:01.741 3477--    --trace-signals=yes
--00:00:00:01.741 3477--    --track-origins=no
--00:00:00:01.741 3477--    --trace-children=yes
--00:00:00:01.741 3477--
--trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc
--00:00:00:01.741 3477--    --vgdb=no
--00:00:00:01.741 3477--    --error-limit=no
--00:00:00:01.741 3477--    --verbose
--00:00:00:01.741 3477-- Contents of /proc/version:
--00:00:00:01.741 3477--   Linux version 6.11.9-100.fc39.x86_64
(mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1
20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP
PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024
--00:00:00:01.741 3477--
--00:00:00:01.741 3477-- Arch and hwcaps: X86, LittleEndian,
x86-mmxext-sse1-sse2-sse3-lzcnt
--00:00:00:01.741 3477-- Page sizes: currently 4096, max supported 4096
--00:00:00:01.741 3477-- Valgrind library directory: /usr/local/libexec/valgrind
--00:00:00:01.750 3477-- sys_sigaction: sigNo 12, new 0xfeae4d34, old
0x0, new flags 0x4000000
--00:00:00:01.750 3477-- sys_sigaction: sigNo 10, new 0xfeae4d34, old
0x0, new flags 0x4000000
--00:00:00:01.751 3477-- sys_sigaction: sigNo 15, new 0xfeae4d34, old
0x0, new flags 0x4000000
--00:00:00:01.752 3477-- sys_sigaction: sigNo 13, new 0xfeae4d34, old
0x0, new flags 0x4000000
--00:00:00:01.752 3477-- sys_sigaction: sigNo 2, new 0xfeae4d34, old
0x0, new flags 0x4000000
--00:00:00:01.753 3477-- sys_sigaction: sigNo 17, new 0xfeae4d34, old
0x0, new flags 0x4000000
--00:00:00:01.754 3477-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
newset = 0x0 (NULL)
--00:00:00:01.754 3477--        oldset=0xFEAE4FCC 0000000000000000
--00:00:00:01.757 3477-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
newset = 0xFEAE4EA0 (fffffffe7ffee115)
--00:00:01:42.040 3477-- sys_sigaction: sigNo 11, new 0x82cfdeec, old
0x0, new flags 0x0
--00:00:01:42.040 3477-- sys_sigaction: sigNo 7, new 0x82cfdeec, old
0x0, new flags 0x0
--00:00:01:42.040 3477-- sys_sigaction: sigNo 4, new 0x82cfdee4, old
0x0, new flags 0x0
--00:00:01:42.040 3477-- sys_sigaction: sigNo 8, new 0x82cfdee4, old
0x0, new flags 0x0
--00:00:01:42.040 3477-- sys_sigaction: sigNo 31, new 0x82cfdedc, old
0x0, new flags 0x0
==00:00:01:42.065 3477==
==00:00:01:42.065 3477== HEAP SUMMARY:
==00:00:01:42.065 3477==     in use at exit: 2,440 bytes in 378 blocks
==00:00:01:42.065 3477==   total heap usage: 3,807 allocs, 3,429
frees, 430,504 bytes allocated
==00:00:01:42.065 3477==
==00:00:01:42.065 3477== Searching for pointers to 378 not-freed blocks
scan 0x30d000-0x5d4000 (2912256)
ptr=0x502ac10 -> block 368
ptr=0x503b100 -> block 373
ptr=0x50200b0 -> block 299
ptr=0x5020150 -> block 301
ptr=0x50201f0 -> block 303
ptr=0x5020600 -> block 316
ptr=0x5020560 -> block 314
ptr=0x503b160 -> block 374
ptr=0x501fcf0 -> block 287
ptr=0x501fd90 -> block 289
ptr=0x501fc50 -> block 285
ptr=0x503b100 -> block 373
ptr=0x5018d80 -> block 0
ptr=0x5018dd0 -> block 1
ptr=0x5018e20 -> block 2
ptr=0x5018e70 -> block 3
ptr=0x5018ed0 -> block 4
ptr=0x5018f40 -> block 5
ptr=0x5018f90 -> block 6
ptr=0x5018fe0 -> block 7
ptr=0x5019030 -> block 8
ptr=0x5019080 -> block 9
ptr=0x50190d0 -> block 10
...
ptr=0x503b3b0 -> block 376
ptr=0x501a0f3 -> block 61
scan 0x5d4000-0x5dd000 (36864)
ptr=0x502ac10 -> block 368
ptr=0x5024b70 -> block 352
ptr=0x502a9d0 -> block 364
ptr=0x502aa70 -> block 365
ptr=0x502aa70 -> block 365
ptr=0x502aac0 -> block 366
ptr=0x501d850 -> block 236
ptr=0x501d8a0 -> block 237
scan 0x4036000-0x4037000 (4096)
scan 0x4037000-0x4038000 (4096)
scan 0x4837000-0x4839000 (8192)
scan 0x483d000-0x483e000 (4096)
scan 0x4858000-0x4859000 (4096)
scan 0x4861000-0x4862000 (4096)
scan 0x4872000-0x4873000 (4096)
scan 0x4873000-0x4875000 (8192)
scan 0x494c000-0x494f000 (12288)
scan 0x494f000-0x4950000 (4096)
scan 0x4d97000-0x4d99000 (8192)
scan 0x4d99000-0x4d9b000 (8192)
scan 0x4db8000-0x4db9000 (4096)
scan 0x4fb2000-0x4fb3000 (4096)
scan 0x4fb3000-0x4fb8000 (20480)
scan 0x4fbc000-0x4fbd000 (4096)
scan 0x4fc1000-0x4fc4000 (12288)
scan 0x53c4000-0x14dc4000 (262144000)
--00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel
--00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel
--00:00:01:42.342 3477-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel

2. Log file for process 3479 (335MB when valgrind killed):

==00:00:00:01.749 3479== Memcheck, a memory error detector
==00:00:00:01.749 3479== Copyright (C) 2002-2024, and GNU GPL'd, by
Julian Seward et al.
==00:00:00:01.749 3479== Using Valgrind-3.24.0-fcdaa47426-20241101X
and LibVEX; rerun with -h for copyright info
==00:00:00:01.749 3479== Command: bin/gm_server --master
XXXXXXXXXXXXXXXXXXXXXXXX
==00:00:00:01.749 3479== Parent PID: 3461
==00:00:00:01.749 3479==
--00:00:00:01.749 3479--
--00:00:00:01.749 3479-- Valgrind options:
--00:00:00:01.749 3479--    --log-file=/tmp/valgrind/memcheck-%p.log
--00:00:00:01.749 3479--    --tool=memcheck
--00:00:00:01.749 3479--    --leak-check=summary
--00:00:00:01.749 3479--    --time-stamp=yes
--00:00:00:01.749 3479--    --track-fds=no
--00:00:00:01.749 3479--    --trace-signals=yes
--00:00:00:01.749 3479--    --track-origins=no
--00:00:00:01.749 3479--    --trace-children=yes
--00:00:00:01.749 3479--
--trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc
--00:00:00:01.749 3479--    --vgdb=no
--00:00:00:01.749 3479--    --error-limit=no
--00:00:00:01.749 3479--    --verbose
--00:00:00:01.749 3479-- Contents of /proc/version:
--00:00:00:01.749 3479--   Linux version 6.11.9-100.fc39.x86_64
(mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1
20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP
PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024
--00:00:00:01.749 3479--
--00:00:00:01.749 3479-- Arch and hwcaps: X86, LittleEndian,
x86-mmxext-sse1-sse2-sse3-lzcnt
--00:00:00:01.749 3479-- Page sizes: currently 4096, max supported 4096
--00:00:00:01.749 3479-- Valgrind library directory: /usr/local/libexec/valgrind
--00:00:00:01.759 3479-- sys_sigaction: sigNo 12, new 0xfeae4cf4, old
0x0, new flags 0x4000000
--00:00:00:01.759 3479-- sys_sigaction: sigNo 10, new 0xfeae4cf4, old
0x0, new flags 0x4000000
--00:00:00:01.759 3479-- sys_sigaction: sigNo 15, new 0xfeae4cf4, old
0x0, new flags 0x4000000
--00:00:00:01.760 3479-- sys_sigaction: sigNo 13, new 0xfeae4cf4, old
0x0, new flags 0x4000000
--00:00:00:01.760 3479-- sys_sigaction: sigNo 2, new 0xfeae4cf4, old
0x0, new flags 0x4000000
--00:00:00:01.760 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
newset = 0x0 (NULL)
--00:00:00:01.760 3479--        oldset=0xFEAE4FBC 0000000000000000
--00:00:00:01.762 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
newset = 0xFEAE4E60 (fffffffe7fffe115)
--00:00:00:01.765 3479-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
newset = 0xFEAE4FBC (0000000000000000)
--00:00:01:33.725 3479-- async signal handler: signal=15, vgtid=3479,
tid=1, si_code=0, exitreason VgSrc_None
--00:00:01:33.725 3479-- interrupted_syscall: tid=1, ip=0x580d540d,
restart=False, sres.isErr=True, sres.val=4
--00:00:01:33.725 3479--   completed, but uncommitted: committing
--00:00:01:33.725 3479-- delivering signal 15 (SIGTERM):0 to thread 1
--00:00:01:33.725 3479-- push_signal_frame (thread 1): signal 15
==00:00:01:33.725 3479==    at 0x4E6D47B: __clock_nanosleep_time64
(clock_nanosleep.c:62)
==00:00:01:33.725 3479==    by 0x4E80024: __nanosleep64 (nanosleep.c:25)
==00:00:01:33.725 3479==    by 0x4E80024: nanosleep (nanosleep.c:42)
==00:00:01:33.725 3479==    by 0x4E92263: sleep (sleep.c:55)
==00:00:01:33.725 3479==    by 0x1CF4A9: harmony_process (harmony.c:1320)
==00:00:01:33.725 3479==    by 0x1D0E02: harmony_run (harmony.c:1811)
==00:00:01:33.725 3479==    by 0x29BDC3: main (main.c:1054)
--00:00:01:33.726 3479-- VG_(sigframe_destroy) (thread 1): isRT=0
valid magic; EIP=0x401b002
--00:00:01:33.818 3479-- sys_sigaction: sigNo 11, new 0x82cfdeec, old
0x0, new flags 0x0
--00:00:01:33.818 3479-- sys_sigaction: sigNo 7, new 0x82cfdeec, old
0x0, new flags 0x0
--00:00:01:33.818 3479-- sys_sigaction: sigNo 4, new 0x82cfdee4, old
0x0, new flags 0x0
--00:00:01:33.818 3479-- sys_sigaction: sigNo 8, new 0x82cfdee4, old
0x0, new flags 0x0
--00:00:01:33.818 3479-- sys_sigaction: sigNo 31, new 0x82cfdedc, old
0x0, new flags 0x0
==00:00:01:33.833 3479==
==00:00:01:33.833 3479== HEAP SUMMARY:
==00:00:01:33.833 3479==     in use at exit: 2,440 bytes in 378 blocks
==00:00:01:33.833 3479==   total heap usage: 3,810 allocs, 3,432
frees, 452,136 bytes allocated
==00:00:01:33.833 3479==
==00:00:01:33.833 3479== Searching for pointers to 378 not-freed blocks
scan 0x30d000-0x5d4000 (2912256)
ptr=0x502ac10 -> block 368
ptr=0x503b100 -> block 373
ptr=0x50200b0 -> block 299
ptr=0x5020150 -> block 301
ptr=0x50201f0 -> block 303
ptr=0x5020600 -> block 316
ptr=0x5020560 -> block 314
ptr=0x503b160 -> block 374
ptr=0x501fcf0 -> block 287
ptr=0x501fd90 -> block 289
ptr=0x501fc50 -> block 285
ptr=0x503b100 -> block 373
ptr=0x5018d80 -> block 0
ptr=0x5018dd0 -> block 1
ptr=0x5018e20 -> block 2
ptr=0x5018e70 -> block 3
ptr=0x5018ed0 -> block 4
ptr=0x5018f40 -> block 5
ptr=0x5018f90 -> block 6
ptr=0x5018fe0 -> block 7
ptr=0x5019030 -> block 8
ptr=0x5019080 -> block 9
ptr=0x50190d0 -> block 10
...
ptr=0x503b3b0 -> block 376
ptr=0x501a0f3 -> block 61
scan 0x5d4000-0x5dd000 (36864)
ptr=0x502ac10 -> block 368
ptr=0x5024b70 -> block 352
ptr=0x502a9d0 -> block 364
ptr=0x502aa70 -> block 365
ptr=0x502aa70 -> block 365
ptr=0x502aac0 -> block 366
ptr=0x501d850 -> block 236
ptr=0x501d8a0 -> block 237
scan 0x4036000-0x4037000 (4096)
scan 0x4037000-0x4038000 (4096)
scan 0x4837000-0x4839000 (8192)
scan 0x483d000-0x483e000 (4096)
scan 0x4858000-0x4859000 (4096)
scan 0x4861000-0x4862000 (4096)
scan 0x4872000-0x4873000 (4096)
scan 0x4873000-0x4875000 (8192)
scan 0x494c000-0x494f000 (12288)
scan 0x494f000-0x4950000 (4096)
scan 0x4d97000-0x4d99000 (8192)
scan 0x4d99000-0x4d9b000 (8192)
scan 0x4db8000-0x4db9000 (4096)
scan 0x4fb2000-0x4fb3000 (4096)
scan 0x4fb3000-0x4fb8000 (20480)
scan 0x4fbc000-0x4fbd000 (4096)
scan 0x4fc1000-0x4fc4000 (12288)
scan 0x53c4000-0x14dc4000 (262144000)
--00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel
--00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel
--00:00:01:34.000 3479-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel

3. Log file for process 3491 (142MB when valgrind killed):

==00:00:00:02.218 3491== Memcheck, a memory error detector
==00:00:00:02.218 3491== Copyright (C) 2002-2024, and GNU GPL'd, by
Julian Seward et al.
==00:00:00:02.218 3491== Using Valgrind-3.24.0-fcdaa47426-20241101X
and LibVEX; rerun with -h for copyright info
==00:00:00:02.218 3491== Command: bin/gm_server --master
XXXXXXXXXXXXXXXXXXXXXXXX
==00:00:00:02.218 3491== Parent PID: 3461
==00:00:00:02.218 3491==
--00:00:00:02.218 3491--
--00:00:00:02.218 3491-- Valgrind options:
--00:00:00:02.218 3491--    --log-file=/tmp/valgrind/memcheck-%p.log
--00:00:00:02.218 3491--    --tool=memcheck
--00:00:00:02.218 3491--    --leak-check=summary
--00:00:00:02.218 3491--    --time-stamp=yes
--00:00:00:02.218 3491--    --track-fds=no
--00:00:00:02.218 3491--    --trace-signals=yes
--00:00:00:02.218 3491--    --track-origins=no
--00:00:00:02.218 3491--    --trace-children=yes
--00:00:00:02.218 3491--
--trace-children-skip=*/awk,*/bash,*/chattr,*/chmod,*/curl,*/date,*/du,*/expr,*/grep,*/ip,*/locale,*/logger,*/mkdir,*/mv,*/rm,*/sed,*/sh,*/sort,*/touch,*/wc
--00:00:00:02.218 3491--    --vgdb=no
--00:00:00:02.218 3491--    --error-limit=no
--00:00:00:02.218 3491--    --verbose
--00:00:00:02.218 3491-- Contents of /proc/version:
--00:00:00:02.218 3491--   Linux version 6.11.9-100.fc39.x86_64
(mockbuild@03ca63968fb540ceb027c83bbfe793be) (gcc (GCC) 13.3.1
20240913 (Red Hat 13.3.1-3), GNU ld version 2.40-14.fc39) #1 SMP
PREEMPT_DYNAMIC Sun Nov 17 18:52:19 UTC 2024
--00:00:00:02.218 3491--
--00:00:00:02.218 3491-- Arch and hwcaps: X86, LittleEndian,
x86-mmxext-sse1-sse2-sse3-lzcnt
--00:00:00:02.218 3491-- Page sizes: currently 4096, max supported 4096
--00:00:00:02.218 3491-- Valgrind library directory: /usr/local/libexec/valgrind
--00:00:00:02.227 3491-- sys_sigaction: sigNo 12, new 0xfeae4d04, old
0x0, new flags 0x4000000
--00:00:00:02.228 3491-- sys_sigaction: sigNo 10, new 0xfeae4d04, old
0x0, new flags 0x4000000
--00:00:00:02.228 3491-- sys_sigaction: sigNo 15, new 0xfeae4d04, old
0x0, new flags 0x4000000
--00:00:00:02.229 3491-- sys_sigaction: sigNo 13, new 0xfeae4d04, old
0x0, new flags 0x4000000
--00:00:00:02.229 3491-- sys_sigaction: sigNo 2, new 0xfeae4d04, old
0x0, new flags 0x4000000
--00:00:00:02.229 3491-- sys_sigaction: sigNo 17, new 0xfeae4d04, old
0x0, new flags 0x4000000
--00:00:00:02.230 3491-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
newset = 0x0 (NULL)
--00:00:00:02.230 3491--        oldset=0xFEAE4FBC 0000000000000000
--00:00:00:02.231 3491-- do_setmask: tid = 1 how = 2 (SIG_SETMASK),
newset = 0xFEAE4E70 (fffffffe7ffee115)
--00:00:02:02.494 3491-- sys_sigaction: sigNo 11, new 0x82cfdeec, old
0x0, new flags 0x0
--00:00:02:02.494 3491-- sys_sigaction: sigNo 7, new 0x82cfdeec, old
0x0, new flags 0x0
--00:00:02:02.494 3491-- sys_sigaction: sigNo 4, new 0x82cfdee4, old
0x0, new flags 0x0
--00:00:02:02.494 3491-- sys_sigaction: sigNo 8, new 0x82cfdee4, old
0x0, new flags 0x0
--00:00:02:02.494 3491-- sys_sigaction: sigNo 31, new 0x82cfdedc, old
0x0, new flags 0x0
==00:00:02:02.525 3491==
==00:00:02:02.525 3491== HEAP SUMMARY:
==00:00:02:02.525 3491==     in use at exit: 20,649 bytes in 576 blocks
==00:00:02:02.525 3491==   total heap usage: 5,562 allocs, 4,986
frees, 595,523 bytes allocated
==00:00:02:02.525 3491==
==00:00:02:02.526 3491== Searching for pointers to 576 not-freed blocks
scan 0x30d000-0x5d4000 (2912256)
ptr=0x502ac10 -> block 377
ptr=0x503b100 -> block 382
ptr=0x50200b0 -> block 308
ptr=0x5020150 -> block 310
ptr=0x50201f0 -> block 312
ptr=0x5020600 -> block 325
ptr=0x5020560 -> block 323
ptr=0x503b160 -> block 383
ptr=0x501fcf0 -> block 296
ptr=0x501fd90 -> block 298
ptr=0x501fc50 -> block 294
ptr=0x503b100 -> block 382
ptr=0x5018d80 -> block 9
ptr=0x5018dd0 -> block 10
...
ptr=0x50b2770 -> block 558
ptr=0x50b2880 -> block 560
ptr=0x50b14d0 -> block 539
ptr=0x50b09b0 -> block 538
ptr=0x50a2f40 -> block 499
scan 0x4036000-0x4037000 (4096)
scan 0x4037000-0x4038000 (4096)
scan 0x4837000-0x4839000 (8192)
scan 0x483d000-0x483e000 (4096)
scan 0x4858000-0x4859000 (4096)
scan 0x4861000-0x4862000 (4096)
scan 0x4872000-0x4873000 (4096)
scan 0x4873000-0x4875000 (8192)
scan 0x494c000-0x494f000 (12288)
scan 0x494f000-0x4950000 (4096)
scan 0x4d97000-0x4d99000 (8192)
scan 0x4d99000-0x4d9b000 (8192)
scan 0x4db8000-0x4db9000 (4096)
scan 0x4fb2000-0x4fb3000 (4096)
scan 0x4fb3000-0x4fb8000 (20480)
scan 0x4fbc000-0x4fbd000 (4096)
scan 0x4fc1000-0x4fc4000 (12288)
scan 0x53c4000-0x14dc4000 (262144000)
--00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel
--00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel
--00:00:02:02.918 3491-- sync signal handler: signal=7, si_code=2,
EIP=0x0, eip=0x58002e8d, from kernel

On Mon, Dec 9, 2024 at 8:28 AM Paul Floyd via Valgrind-users
<val...@li...> wrote:
>
>
>
> On 05-12-24 14:19, Wojciech Bocer wrote:
> > Hello,
> >
> > I have a problem with Valgrind taking a lot of time trying to
> > determine if there are memory leaks before it exits.
>
>
> Roughly speaking leak detection involves scanning though all accessible
> memory using pointer-size alignment to look for any pointers to unfreed
> memory blocks. This code does handle segfaults.
>
> I don't have any real idea why the combination of x86 and Docker gives
> large numbers of segfaults and a major slowdown.
>
> I suggest that you get the source for Valgrind and set these macros in
> mc_leakcheck.c to 1
>
>
> // Define to debug the memory-leak-detector.
> #define VG_DEBUG_FIND_CHUNK 0
> #define VG_DEBUG_LEAKCHECK 0
> #define VG_DEBUG_CLIQUE    0
>
> and then build Valgrind.
>
> A+
> Paul
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users