valgrind-users — General discussion list for Valgrind users

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

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

On 3/21/25 09:06, kiran hardas wrote:
> Hi Paul/Team,
>
> Thank you for your suggestion. I added the entry for shmget function 
> in coregrind/m_syswrap/syswrap-x86-linux.c
> and the error got resolved for shmget function. Yes it is x86 linux 
> that is getting used. Similar errors came for shmat, shmdt, shmctl 
> functions.
> I added similar entries of those functions too in the table and 
> resolved the errors.
>
> Currently i am getting error from shmat function as "Invalid argument" 
> from my application code.
> The data pointer returned by shmat function is coming as 0xffffffff 
> which is -1 (error). I am calling the shmat as below
>  in my application code
>
> data = shmat(shmid, NULL, 0);            /* where data is a struct 
> pointer and shmid is 1 obtained by a successful shmget call */
>
> I verified the arguments for this shmat function and they seem to be 
> fine. Also checked for permission issues.
> I am suspecting memory issue which could be resulting in shmat attach 
> failure after running valgrind (have glibc 2.40).
>
> Would appreciate any advice/suggestion you can provide for this issue.
>
Hi

I'll have a look this weekend.

A+

Paul

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

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

Hi Paul/Team,

Thank you for your suggestion. I added the entry for shmget function in
coregrind/m_syswrap/syswrap-x86-linux.c
and the error got resolved for shmget function. Yes it is x86 linux that
is getting used. Similar errors came for shmat, shmdt, shmctl functions.
I added similar entries of those functions too in the table and resolved
the errors.

Currently i am getting error from shmat function as "Invalid argument" from
my application code.
The data pointer returned by shmat function is coming as 0xffffffff which
is -1 (error). I am calling the shmat as below
 in my application code

data = shmat(shmid, NULL, 0);            /* where data is a struct pointer
and shmid is 1 obtained by a successful shmget call */

I verified the arguments for this shmat function and they seem to be fine.
Also checked for permission issues.
I am suspecting memory issue which could be resulting in shmat attach
failure after running valgrind (have glibc 2.40).

Would appreciate any advice/suggestion you can provide for this issue.

Thanks in advance

On Sun, Mar 16, 2025 at 1:47 AM Paul Floyd via Valgrind-users <
val...@li...> wrote:

>
> On 3/12/25 22:40, kiran hardas wrote:
> > Hi Philippe/Team,
> >
> > Thank you Philippe for your suggestions, I was able to resolve the
> > earlier errors by adding additional valgrind options and loading the
> > symbol table.
> > In my application, few variables and a function pointer was
> > uninitialised which led to previous errors mentioned in earlier email.
> >
> > Proceeding further with my earlier activity, right now i am
> > seeing error related to unhandled syscall no. 395 in valgrind logs. I
> > thought to bring this up in this mail chain for your suggestions/inputs.
> >
> >
> > # ./usr/test/bin/valgrind --version -v
> > valgrind-3.24.0-fcdaa47426-20241101
> >
> > GNU/Linux 5.4
> > Glibc 2.40
> > gcc 14.2
> > binutils 2.43
> >
> >
> > Error snippet:
> >
> > --6423-- WARNING: unhandled x86-linux syscall: 395
> > ==6423==    at 0x1F757398: shmget (in /lib/libc-2.40.so
> > <http://libc-2.40.so>)
> > by 0xF597083: <application backtraces>
> > ...
> > ...
> > --6423-- You may be able to write your own handler.
> > --6423-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> > --6423-- Nevertheless we consider this a bug.  Please report
> > --6423-- it at http://valgrind.org/support/bug_reports.html.
> >
> > From my analysis of valgrind code, i can see the shmget wrappers are
> > present in coregrind/m_syswrap area, but still it is throwing such error.
> >
> > Any pointers or suggestions would be appreciated, Thanks.
> >
> Hi
>
> That looks like shmget on x86. Can you confirm that?
>
> If so could you build valgrind with this patch
>
> diff --git a/coregrind/m_syswrap/syswrap-x86-linux.c
> b/coregrind/m_syswrap/syswrap-x86-l
> inux.c
> index 50384817d..5c0b57789 100644
> --- a/coregrind/m_syswrap/syswrap-x86-linux.c
> +++ b/coregrind/m_syswrap/syswrap-x86-linux.c
> @@ -1621,6 +1621,8 @@static SyscallTableEntry syscall_table[] = {
>
>     GENX_(__NR_rseq,              sys_ni_syscall),       // 386
>
> +   LINX_(__NR_shmget,            sys_shmget),           // 395
> +
>     LINXY(__NR_clock_gettime64,   sys_clock_gettime64),  // 403
>     LINX_(__NR_clock_settime64,   sys_clock_settime64),  // 404
>
>
> and let us know if it works?
>
> It's likely that you will also need shmat shmctl and shmdt as well.
>
> A+
>
> Paul
>
>
>
>
> _______________________________________________
> 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

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

On 3/12/25 22:40, kiran hardas wrote:
> Hi Philippe/Team,
>
> Thank you Philippe for your suggestions, I was able to resolve the 
> earlier errors by adding additional valgrind options and loading the 
> symbol table.
> In my application, few variables and a function pointer was 
> uninitialised which led to previous errors mentioned in earlier email.
>
> Proceeding further with my earlier activity, right now i am 
> seeing error related to unhandled syscall no. 395 in valgrind logs. I 
> thought to bring this up in this mail chain for your suggestions/inputs.
>
>
> # ./usr/test/bin/valgrind --version -v
> valgrind-3.24.0-fcdaa47426-20241101
>
> GNU/Linux 5.4
> Glibc 2.40
> gcc 14.2
> binutils 2.43
>
>
> Error snippet:
>
> --6423-- WARNING: unhandled x86-linux syscall: 395
> ==6423==    at 0x1F757398: shmget (in /lib/libc-2.40.so 
> <http://libc-2.40.so>)
> by 0xF597083: <application backtraces>
> ...
> ...
> --6423-- You may be able to write your own handler.
> --6423-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
> --6423-- Nevertheless we consider this a bug.  Please report
> --6423-- it at http://valgrind.org/support/bug_reports.html.
>
> From my analysis of valgrind code, i can see the shmget wrappers are 
> present in coregrind/m_syswrap area, but still it is throwing such error.
>
> Any pointers or suggestions would be appreciated, Thanks.
>
Hi

That looks like shmget on x86. Can you confirm that?

If so could you build valgrind with this patch

diff --git a/coregrind/m_syswrap/syswrap-x86-linux.c 
b/coregrind/m_syswrap/syswrap-x86-l
inux.c
index 50384817d..5c0b57789 100644
--- a/coregrind/m_syswrap/syswrap-x86-linux.c
+++ b/coregrind/m_syswrap/syswrap-x86-linux.c
@@ -1621,6 +1621,8 @@static SyscallTableEntry syscall_table[] = {

    GENX_(__NR_rseq,              sys_ni_syscall),       // 386

+   LINX_(__NR_shmget,            sys_shmget),           // 395
+
    LINXY(__NR_clock_gettime64,   sys_clock_gettime64),  // 403
    LINX_(__NR_clock_settime64,   sys_clock_settime64),  // 404


and let us know if it works?

It's likely that you will also need shmat shmctl and shmdt as well.

A+

Paul

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

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

Hi Philippe/Team,

Thank you Philippe for your suggestions, I was able to resolve the earlier
errors by adding additional valgrind options and loading the symbol table.
In my application, few variables and a function pointer was uninitialised
which led to previous errors mentioned in earlier email.

Proceeding further with my earlier activity, right now i am seeing error
related to unhandled syscall no. 395 in valgrind logs. I thought to bring
this up in this mail chain for your suggestions/inputs.


# ./usr/test/bin/valgrind --version -v
valgrind-3.24.0-fcdaa47426-20241101

GNU/Linux 5.4
Glibc 2.40
gcc 14.2
binutils 2.43


Error snippet:

--6423-- WARNING: unhandled x86-linux syscall: 395
==6423==    at 0x1F757398: shmget (in /lib/libc-2.40.so)
by 0xF597083:  <application backtraces>
...
...
--6423-- You may be able to write your own handler.
--6423-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--6423-- Nevertheless we consider this a bug.  Please report
--6423-- it at http://valgrind.org/support/bug_reports.html.

>From my analysis of valgrind code, i can see the shmget wrappers are
present in coregrind/m_syswrap area, but still it is throwing such error.

Any pointers or suggestions would be appreciated, Thanks.




Regards,
Kiran H.

On Thu, Jan 30, 2025 at 1:54 AM Philippe Waroquiers <
phi...@sk...> wrote:

> 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] Valgrind runs way slower on faster PC

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

On 2/10/25 12:44 AM, 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.

Run "sudo dmidecode >dmidecode.out" and compare the cache sizes and
associativity.  Run "grep cache /proc/cpuinfo".  Also run "lscpu".
What is the TLB size?  Boot the standalone memtest86+ and check
the measured speed of caches and RAM.

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

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

On 10-02-25 09:44, 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.


Any patches to speed up Valgrind would be welcome ;-)


Seriously, one common mistake that I often see new users make is 
overdoing it with the Valgrind options. Just because Valgrind has many 
options doesn't mean that you should use them all. As a rule the more 
options you add the slower Valgrind will run.

I'm going to assume that it's memcheck that you are using.

If you're just running tests
----------------------------
Really minimise your use of options. You may need --trace-children=yes 
(and possibly --trace-children-skip= if your exe forks a lot of other 
processes), Don't check for leaks unless the leak summary says that you 
have leaks. Don't use --track-origins=yes until you have detected a 
"Conditional jump" error.

If you know you have an error and you want to debug it
------------------------------------------------------
This is where you want to start turning on options like
--track-origins=yes and --read-var-info=yes.

A+
Paul

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

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

> On 11 Feb 2025, at 04:38, Jessica Long <jes...@gm...> wrote:
> 
> 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.
> 


Hi

Are you using Docker?

If you are, here is what is happening. Valgrind tries to make itself invisible to the rest application that it is testing. Since Valgrind uses some files itself (e.g., for the log) it reserves for itself a small number of file descriptors. These files will use the highest possible file descriptors. In order that this seems (mostly) invisible Valgrind will also change the ‘resource limit’ for file descriptors ilimit is the API that developers should use to query things like file descriptor limits. On a real Linux instance the file descriptor limit is something sensible like 65536.

Enter Docker.

Docker screws up the file descriptor limit. For some reason, instead of using the same sensible limit that the host is using Docker sets the limit to the maximum theoretical limit (possibly by querying the kernel sysctl fs.file-max). In your case that is a billion files. So when Valgrind runs it will try to use file descriptors up around the 1 billion mark for its own use. When this happens the Linux kernel tries to extend the array of structures that it uses for files up to the file descriptor that Valgrind has requested. Typically that is an infeasibly large amount of memory, and the allocation request will fail. Valgrind gets back an error code (ENOMEM - not enough memory) and it terminates because it can’t continue without being able to use files.

Solutions

I don’t know if you can tell Docker to use a sensible file descriptor limit.

Otherwise, when you are running a shell inside Docker, before you run CLion, enter the command

ulimit -n 65536

(that is for sh and bash, csh has a similar command).

A+
Paul

[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
=====