Re: [Valgrind-users] valgind with LD_PRELOAD

[Philippe Waroquiers]

To further investigate, some more info might be useful, and some
actions below might help.

General info:
Which version of valgrind are you using ? On which platform ?

The function setup_client_env in initimg-linux.c is responsible
to modify LD_PRELOAD (as valgrind needs to add some values there).
To check this is working properly, you can do the below:
  * change Bool   debug   = False; to True
and/or
  * do:
LD_PRELOAD=x valgrind 
echo $LD_PRELOAD # this should show the modified by valgrind LD_PRELOAD
   (bash fails under valgrind, I tried with dash)

Please run with -v -v -v -d -d -d your program and examine the trace.
At least at the end of execution, you should find a trace
of the address space manager showing which files are mapped,
and that should contain your preloaded library.

If LD_PRELOAD is correct, but the lib is not mapped, then
you might trace ld.so using LD_DEBUG
(see man ld.so)

If the lib is loaded, but no signals seems to arrive,
you might try:
valgrind --trace-signals=yes sleep 10
and in another shell, send the signal to the valgrind pid
and observe the trace (which should show the signal arriving)
Then do the same but when valgrind runs your program.

Philippe



On Mon, 2018-03-05 at 11:12 +, Hari via Valgrind-users wrote:
> Hi John,
> 
> Thanks for your inputs. I tried both --trace-signals=yes and strace options 
> indicated but i could not see any traces of signal sent reaching my_process. 
> 
> I suspect if LD_PRELOAD itself did not happen with the following command to 
> my_process
> 
> LD_PRELOAD=./libfake.so valgrind ./my_process
> 
> Is there a different way to make sure that LD_PRELOAD done above is indeed 
> successful? I checked few online portals and i see /proc//maps (pid of 
> my_process) and i see references to the libfake.so. Does this confirm that 
> LD_PRELOAD is indeed successful? Is there any other way to trace where the 
> signal is reaching?
> 
> Thanks
> Hari
> 
> 
> On Wednesday, February 28, 2018, 9:43:29 AM GMT+5:30, John Reiser 
>  wrote:
> 
> 
> > LD_PRELOAD=./libfake.so ./my_process --> runs fine and prints memory stats
> > 
> > But,
> > 
> > LD_PRELOAD=./libfake.so valgrind ./my_process --> doesnt print the memory 
> > stats
> > 
> >  From few online blogs, i understand that valgrind does forward any signals 
> >to the child process that it is running on but it doesnt seem to work here.
> 
> There is no parent-child relationship between valgrind and ./my_process.
> Both valgrind and ./my_process run in the same address space as just one 
> process.
> The inter-process communication would be extremely expensive if valgrind
> and ./my_process did not share the same address space, and memcheck tracking
> of each memory access would be difficult if there were 2 threads of control.
> 
> The command-line parameter "--trace-signals=yes" causes valgrind to report on 
> signals.
> The Linux utility /usr/bin/strace also reports on signals.  (Probably use
> something like "strace -e trace=file" to reduce the syscalls that strace 
> reports;
> in particular 'read' and 'write' are usually heavily used and ignorable.)
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] ==10087== Unsupported clone() flags: 0x104011

[Philippe Waroquiers]

On Fri, 2018-04-13 at 18:27 +, Rachel Chen (rychen) wrote:
> Index: 
> third-party/src/valgrind/valgrind-3.4.1/coregrind/m_syswrap/syswrap-x86-linux.c
The release 3.4.1 is from 2009.
I suggest to upgrade to the last release (3.13.0), as it is unlikely
someone will be willing/able to provide support on this very old version.

Since 3.4.1, all this clone flags related code was heavily
restructured/reworked, and supports somewhat more combinations.

So, maybe 3.13.0 will solve your problem.
Feedback welcome ...

Philippe 


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Current git fails to compile on macOS

[Philippe Waroquiers]

On Fri, 2018-04-13 at 05:56 -0400, IMoL wrote:
> git-1f08787cf (of 11 April) fails to build on macOS:
> 
> m_syswrap/syswrap-generic.c:1797:26: error: variable has incomplete type 
> 'struct vki_semid64_ds'
>    struct vki_semid64_ds buf;
>                          ^
> m_syswrap/syswrap-generic.c:1797:11: note: forward declaration of 'struct 
> vki_semid64_ds'
>    struct vki_semid64_ds buf;
>           ^
> m_syswrap/syswrap-generic.c:1798:8: error: no member named 'buf64' in 'union 
> semun'
>    arg.buf64 = 
>    ~~~ ^
> 
> 
> Looks related to this commit from 1 April (git-54145019b):
> 
> "n-i-bz Fix possible stack trashing by semctl syscall wrapping" 
Can you try the attached patch ?
Thanks
Philippe
diff --git a/coregrind/m_syswrap/syswrap-generic.c 
b/coregrind/m_syswrap/syswrap-generic.c
index 5bb6f47df..8b3d6fc72 100644
--- a/coregrind/m_syswrap/syswrap-generic.c
+++ b/coregrind/m_syswrap/syswrap-generic.c
@@ -1794,13 +1794,20 @@ UInt get_sem_count( Int semid )
SysRes res;
 
 #  if defined(__NR_semctl)
+#  if defined(VGO_darwin)
+   /* Darwin has no specific 64 bit semid_ds, but has __NR_semctl. */
+   struct vki_semid_ds buf;
+   arg.buf = 
+#  else
struct vki_semid64_ds buf;
arg.buf64 = 
+#  endif
res = VG_(do_syscall4)(__NR_semctl, semid, 0, VKI_IPC_STAT, *(UWord *));
if (sr_isError(res))
   return 0;
 
return buf.sem_nsems;
+
 #  elif defined(__NR_semsys) /* Solaris */
struct vki_semid_ds buf;
arg.buf = 
@@ -1810,6 +1817,7 @@ UInt get_sem_count( Int semid )
   return 0;
 
return buf.sem_nsems;
+
 #  else
struct vki_semid_ds buf;
arg.buf = 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Current git fails to compile on macOS

[Philippe Waroquiers]

On Sat, 2018-04-14 at 13:37 -0400, IMoL wrote:
> Thank you Philippe.
> 
> That patch allows valgrind to compile on macOS.
thanks for the feedback, patch committed as
06cb991bcd9966b614cd672a7d6e26785f60f851

> 
> Still doesn't work for me, mind you, but at least it compiles again :-)
Someone with more Macos knowledge will have to step in ...

Philippe


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [help] I run the pocl , memcheck report this error (the red text), what it meant.

[Philippe Waroquiers]

On Thu, 2018-04-19 at 00:39 +, Wuweijia wrote:
> memcheck expensive sanity: distinguished_secondaries have changed
>  
> valgrind: external/valgrind/coregrind/m_scheduler/scheduler.c:2240 
> (vgPlain_sanity_check_general): Assertion 
> 'VG_TDICT_CALL(tool_expensive_sanity_check)' failed.
>  
> host stacktrace:
> ==4540==    at 0x3803AA8C: show_sched_status_wrk (m_libcassert.c:343)
> ==4540==    by 0x3803AD07: report_and_quit (m_libcassert.c:419)
> ==4540==    by 0x3803AD07: vgPlain_assert_fail (m_libcassert.c:485)
> ==4540==    by 0x3808119B: vgPlain_sanity_check_general (scheduler.c:2240)
> ==4540==    by 0x3808142F: vgPlain_scheduler (scheduler.c:1308)
> ==4540==    by 0x3808E307: thread_wrapper (syswrap-linux.c:103)
> ==4540==    by 0x3808E307: run_a_thread_NORETURN (syswrap-linux.c:156)
> ==4540==    by 0x3808E6CF: vgModuleLocal_start_thread_NORETURN 
> (syswrap-linux.c:325)
> ==4540==    by 0x380B4143: ??? (in 
> /system/lib64/valgrind/memcheck-arm64-linux)
> 
The above is a valgrind self-check/sanity check that detects an internal
corruption in its own internal memcheck data structure.
Never seen this assert failing up to now.

This might be 
   * a bug in valgrind itself 
   * (less likely) a nasty bug in your application that succeeded
  to corrupt valgrind memcheck data structures
  Was there any application error reported by Valgrind before this
  failing self-check ?
   * (less likely?) an hardware problem, such as failing memory ?

Philippe


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Massif xtree

[Philippe Waroquiers]

On Mon, 2018-03-19 at 22:31 +0100, Paul Floyd wrote:
> Hi
> 
> I’ve been using Massif recently and I gave the xtree output a go (using the 
> callgrind format output).
> 
> Am I right in saying that, by default, the stats given are for the entire run?
Yes.

>  This means that the total allocs/frees give a good idea of the memory churn 
> for the run.
Yes.

>  However, the ‘currently allocated’ will be that on program exit.
Yes.

> 
> Is there any easy way to get the ‘currently allocated’ snapshot at the moment 
> of the peak memory use?
Not that I see.

>  I guess that it’s possible to do one run to find the peak and then another 
> run and use the gdbserver and the xtmemory command.
Yes, that is currently the only way I see.

What could be done relatively easily is to add an option to massif to dump the
detailed snapshots in callgrind format.

Philippe


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Error when analysing pthreads code?

[Philippe Waroquiers]

Yo

On Thu, 2018-06-28 at 14:50 +0100, EML wrote:
> The program below creates two threads, in a detached state, and waits for 
> them to complete with 'pthread_exit'. Compile and run as:
> 
> > gcc -lpthread test.c
> > valgrind --leak-check=full a.out
> 
> valgrind-3.13.0 (compiled from source) reports no errors on some runs, and a 
> possible leak on other runs (560 bytes in 1 blocks), fairly randomly. On my 
> system, the ratio of error-free to bad runs is about 50/50.
> 
> Is this is a problem with valgrind, or my use of pthreads? Note that this 
> isn't the standard 'pthread_create' memory leak with joinable threads which 
> haven't been joined, since the threads are detached.  I'm compiling on Centos 
> 6.9, gcc 4.4.7. Thanks.

On my system, I systematically have the following possible leak:
==20923== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
==20923==at 0x4C2DB70: calloc (vg_replace_malloc.c:711)
==20923==by 0x4011EF1: allocate_dtv (dl-tls.c:322)
==20923==by 0x401287D: _dl_allocate_tls (dl-tls.c:539)
==20923==by 0x4E4100B: allocate_stack (allocatestack.c:580)
==20923==by 0x4E4100B: pthread_create@@GLIBC_2.2.5 (pthread_create.c:539)
==20923==by 0x108936: main (pth.c:19)

Assuming what you see is the same leak (always interesting to give the error
when you discuss an error :)), the possible leak disappears if I am adding
   sleep (10);
before
   pthread_exit(0);

So, it looks like pthread_exit (0) is executed in your case
when a detached thread has not yet cleaned up some of the memory
(the dtv array) used for its thread local storage.
And when this detached thread exits as the last one of the process,
no cleanup of this memory is done.

You can further investigate what happens by adding -v -v -v -d -d -d
and/or use some more options of memcheck to see what stack trace is releasing
this dtv memory when you add the sleep.

Philippe




--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Missing debug symbols

[Philippe Waroquiers]

On Mon, 2018-11-05 at 15:30 -0500, Shahbaz Youssefi wrote:
> Looks like I was slightly too quick to ask this question. The issue
> seems to be coming from the way LLD produces debugging information,
> and adding --no-resegment to LLD fixes the issue:
> 
> https://bugs.chromium.org/p/chromium/issues/detail?id=830706

 Note that the above references valgrind bug 384727,
duplicate of 395682, which is fixed in valgrind 3.14.

So, if you upgrade to latest valgrind release, it should
work without --no-resegment.

Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [Valgrind-developers] valgrind-3.14.0.RC2 is available for testing

[Philippe Waroquiers]

If you try to build the RC2 but from the git repository,
does that work better ?

If the same git version builds/runs ok, then it is probably
just a tar ball packaging problem ...

Philippe


On Thu, 2018-10-04 at 14:41 -0700, Jonathan Leffler wrote:
> Hi,
> 
> What is the intended support status of macOS 10.13.x High Sierra?  What about 
> macOS 10.14 Mojave?
> 
> Some time ago, I downloaded an interim version of Valgrind from Git (git 
> pull) and amongst other files there was a darwin17.supp file . That seems to 
> be missing from the 3.14.0.RC2 tar file.  Consequently, although it 
> configured OK on macOS 10.13.6, it failed to build at a very early stage.  
> I've not yet tried the build on Mojave, but that would presumably fail 
> because of a missing darwin18.supp file.
> 
> The commit I have that has worked on macOS 10.13.x was:
> 
> commit 92d6a538862a784156ee5fff297eb7daba733127 (HEAD -> master, 
> origin/master, origin/HEAD)
> Author: Rhys Kidd 
> Date:   Sun Jun 3 12:40:13 2018 -0400
> 
>     Fix missing kevent_qos syscall (macOS 10.11). bz#383723
> 
> The version built on High Sierra ran on Mojave, but had a new set of warnings 
> — extensive ones.  I assume these should simply be built into a suppressions 
> file for Mojave, in the absence of any better solution.
> 
> 
> On Wed, Oct 3, 2018 at 8:54 AM Julian Seward  wrote:
> > Greetings.
> > 
> > Per the subject line, valgrind-3.14.0.RC2 is available for testing, at:
> > 
> >   ftp://sourceware.org/pub/valgrind/valgrind-3.14.0.RC2.tar.bz2
> >   https://sourceware.org/pub/valgrind/valgrind-3.14.0.RC2.tar.bz2
> >   (md5 = e92f8816973396edd6d0cbcd820ccca0)
> > 
> > Please give it a try on systems, and in configurations, which are important
> > for you, and report any failures (and successes!) here.  I propose to make 
> > the
> > final 3.14.0 release on Tuesday 9 October if no serious breakage is 
> > reported.
> > 
> > As ever, the NEWS file in the tarball lists the new features and fixed bugs 
> > in
> > this release.
> > 
> > J
> > 
> > 
> > ___
> > Valgrind-developers mailing list
> > valgrind-develop...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
> > 
> 
> 
> -- 
> Jonathan Leffler   #include 
> Guardian of DBD::Informix - v2015.1101 - http://dbi.perl.org
> "Blessed are we who can laugh at ourselves, for we shall never cease to be 
> amused."
> ___
> Valgrind-developers mailing list
> valgrind-develop...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Detecting all dangling pointers at exit

[Philippe Waroquiers]

On Wed, 2018-12-26 at 10:15 +, Kumara, Asanka wrote:
> Hi,
> Is there a way to detect ALL dangling pointers (at exit) in valgrind ?
>  
> e.g.
>  
> char* globalVar;
>  
> void main()
> {
>    char* z1 = new char[10];
>    char* z2 = z1;
>    globalVar = z2;
>  
>    delete[] z1;
>  
> }
>  
> At exit of the program say that “globalVar” holds a pointer to a freed memory.
No, this feature does not exist.

I do not think that it would be very difficult to implement: it would basically
be the same algorithm as the leak search, but instead of searching for pointers
pointing at allocated blocks, the search should find the pointers pointing
at recently freed blocks.
That being said, it means that you will only find the dangling pointers
pointing in the recently freed blocks list, as dimensioned with
  --freelist-vol=  volume of freed blocks queue [2000]

So, you would only have a guarantee to detect ALL dangling pointers if
the free list volume is big enough to hold all blocks that were freed during
the run of the program.

And of course, as valgrind implements an optimistic leak search, you would
get an 'optimistic dangling pointer search' : on a 64 bits platform, any 
aligned 8 bytes
(e.g. integer, char array, ...) might be considered by 'luck' as pointing to
a recently freed block, giving a false positive dangling pointer.

Philippe
 


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Suggestion for vgdb

[Philippe Waroquiers]

On Tue, 2018-11-20 at 10:35 +0100, Ivo Raisr wrote:
> Il giorno lun 19 nov 2018 alle ore 16:53 David Faure  ha 
> scritto:
> > 
> > When using vgdb (e.g. `valgrind --vgdb-error=0 myprog`)
> > and there's a valgrind warning for an uninitialized read, on a line like
> > if (a || b)
> > 
> > The question that happens then is, of course, was it a or b that was
> > uninitialized. If one uses vgdb to print the values of a and b, it won't
> > necessarily be obvious (e.g. two bools, both happen to show as "false", with
> > only one actually uninitialized). This makes me wonder, wouldn't it be
> > possible for vgdb to output a warning when doing "print a" or "print b" from
> > gdb and the value is marked as uninitialized?
> > 
> > If I understand the architecture correctly, this should be possible to
> > implement, right?
> 
> I do not want to estimate how feasible would be to implement this feature.
> Patches are welcome, of course.
> 
> But you can use an existing feature:
> http://valgrind.org/docs/manual/mc-manual.html#mc-manual.machine
> http://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
> 
> This will give you what (I think) you want.
Yes, using e.g. the monitor command xb allows to look at the V bits:
you need to know the address (and len) of the value you want to look at.
If a value is in a register, then you have to print the shadow register.

For what concerns automatically printing warnings when GDB prints
a 'non initialised' value:
I think this is not very easy, and will likely give
many false positives :
the valgrind gdbserver has no idea why GDB asks to read some
memory and/or asks to read the registers. In particular, GDB will
very likely often read all the registers (including the one having
uninitialised values). The GDB protocol also does not allow to
read individual bits, and so, when a part of a byte is not initialised
(but correctly so, i.e. not used by the program), printing the variable
will give a warning.

So, in summary, would be a nice thing to do, but I see no way to
do it properly.

Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Callgrind complains about debug symbols missing

[Philippe Waroquiers]

On Mon, 2018-09-17 at 22:14 +0200, Alexander Brock wrote:
> On 9/17/18 7:26 PM, Julian Seward wrote:
> > > valgrind: m_debuginfo/debuginfo.c:738 (check_CFSI_related_invariants):
> > > Assertion 'cfsi_fits' failed.
> > 
> > Is that really still failing?  I thought that got comprehensively fixed
> > in the past few weeks.  Can you re-try?
We had a problem with all Qt applications, failing with
  Bug 393146 - failing assert "is_DebugInfo_active(di)" 
which is (I believe) fully fixed.

However, this cfsi_fits failing looks to be something different,
i.e. the (not yet fixed) bug  :
  Bug 398028 - Assertion `csfi_fits` failing in simple C program with embedded 
Julia code. 

(I guess it might be related to using a newer gcc, or a newer glibc,
or something else new, seeing the versions reported).

If you have a small reproducer, you might look at the last comment
of the bug https://bugs.kde.org/show_bug.cgi?id=398028
and attach the traces with the suggested debug switches.

That might help to see (guess) what is wrong.

Thanks

Philippe

> 
> I ran "git pull" (no new commits, latest commit is
> 97365bada64c27a40004c55793ff8988e59adf35) and re-tried with a couple of
> executables in my project, each fail:
> 
> http://paste.debian.net/1043013/
> 
> It doesn't matter if I use callgrind or memcheck, here is the output for
> memcheck:
> 
> http://paste.debian.net/1043014/
> 
> Alexander
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How can valgrind prevent Segmentation fault?

[Philippe Waroquiers]

On Sat, 2019-01-26 at 17:12 -0600, Peng Yu wrote:
> Hi,
> 
> I have an executable. If I just run on its own, there will be
> segmentation fault. But if I run it using valgrind, it finishes
> successfully. Does anybody how can this happen? How to debug such a
> program? Thanks.
Is valgrind reporting some errors ?
If yes, which kind of errors ?
Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] location of stack allocation printed a at 0x8B43AF0: ??? ...

[Philippe Waroquiers]

On Fri, 2019-03-22 at 10:21 +0100, Matthias Apitz wrote:
> El día Thursday, March 21, 2019 a las 10:44:54PM +0100, Philippe Waroquiers 
> escribió:
> 
> > On Thu, 2019-03-21 at 20:00 +0100, Matthias Apitz wrote:
> > > Hello,
> > > 
> > > Why are only the '???' marks printed for the localtion of the stack
> > > allocation? This is with 3.18.0 on Linux x64:
> > 
> > 3.18.0 ?
> > Last release is 3.14.
> 
> Yep. Sorry, this was a typo. I have 3.14.0, compiled by my own on SuSE
> Linux SLES 12.
> 
> > > ==24390== Conditional jump or move depends on uninitialised value(s)
> > > ==24390==at 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215)
> > > ==24390==by 0x8B8069C: SRVCatSearchMedia (SRVCatSearchMedia.c:579)
> > > ==24390==by 0x74D3683: SlnpRunModule (SLNPInterpreter.c:567)
> > > ==24390==by 0x74D31C7: SlnpInterpreter (SLNPInterpreter.c:287)
> > > ==24390==by 0x414543: SlnpMainLoop (OPServer.c:874)
> > > ==24390==by 0x413ED3: OPServer (OPServer.c:258)
> > > ==24390==by 0x413792: main (OPDaemon.c:407)
> > > ==24390==  Uninitialised value was created by a stack allocation
> > > ==24390==at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so)
> > > ==24390==
> > > 
> > > /home/sisis/guru # file libcopz39.so
> > > libcopz39.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
> > > dynamically linked, 
> > > BuildID[sha1]=eb1d460ebb565dedfe48bf5f534d2c097d9ca59c, with debug_info, 
> > > not stripped
> > > 
> > > The *.o files in the shared lib have been compiled with 'gcc -m64 -g ...'
> > 
> > Can you check what file/line nr corresponds to 0x8B43AF0,
> > using another tool (gdb, or whatever) ?
> 
> I have to check how to convert he addr 0x8B43AF0 into a line:

What I am typically doing is the following:
   valgrind --vgdb-error=1 

(assuming that is the first reported error).
Then valgrind will stop and wait for GDB to connect.
Then do the following:
gdb
target remote | vgdb  
info line *0x8B43AF0

When you do that when attached to the running executable, that will
guarantee that the shared lib address translation is done using
the address at which it is currently loaded.

If GDB equally tells that there is no source/line nr, then I guess
that is the best valgrind can do.

Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] VEX temporary storage exhausted

[Philippe Waroquiers]

On Thu, 2019-03-21 at 23:30 +0100, Yuri D'Elia wrote:
> On Thu, Mar 21 2019, Philippe Waroquiers wrote:
> > Strange.
> > The only thing I see that can cause this failure is VexTransOutputFull.
> > 
> > So, the next trial is to bump x10
> > m_translate.c N_TMPBUF
> > 
> > You have to edit similarly the 6 in VG_(add_to_transtab)
> 
> This seems to have worked.
> 
> What now, though?
Humph, so functionally, valgrind seems to work, but needs an unexpectedly
big amount of memory to handle some piece of code.

The best is to file a bug on bugzilla, attaching more information.
My knowledge in this area is relatively limited, but I think that
the below should give the needed info:

Use the unpatched valgrind (so as to reproduce the problem/crash).
run a first time:
  valgrind --trace-flags= 

This will output a bunch of lines such as:
...
 SB 1789 (evchecks 8650) [tid 1] 0x4f833a7 free_mem+231 UNKNOWN_OBJECT+0x0
 SB 1790 (evchecks 8651) [tid 1] 0x4f832ae free_slotinfo+110 
UNKNOWN_OBJECT+0x0
...

Then rerun with
valgrind --trace-flags= --trace-notbelow=X 
where X is one or two numbers before the SB that causes the crash.

File a bug on bugzilla, attaching the resulting trace, and
add the relevant details, such as indicating that increasing the 2 constants
bypasses the problem.

thanks

Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Crash under ARM64

[Philippe Waroquiers]

On Fri, 2019-04-05 at 20:53 +0200, Paulo Matos via Valgrind-users wrote:
> disInstr(arm64): unhandled instruction 0xD538
...
> Could this really be a problem with valgrind, or am I missing something?
> 
> If I should raise a bug or add more info please let me know.

Searching on 'disInstr(arm64): unhandled instruction 0xD538'
points e.g. at https://bugs.kde.org/show_bug.cgi?id=381556
which is marked as fixed.

So, first thing to try is to test with the latest release (3.14)
and/or the GIT version.

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion 'sizeof(TTEntryC) <= 88' failed.

[Philippe Waroquiers]

You should upgrade to a recent valgrind version (e.g. compile
the last official release 3.14, or even the git version).
See bug https://bugs.kde.org/show_bug.cgi?id=362935

Philippe



commit 7a8129795c5c4e0465ac48989dc6cd755b5d0a66
Author: Julian Seward 
AuthorDate: Thu Jul 21 12:47:51 2016 +
Commit: Julian Seward 
CommitDate: Thu Jul 21 12:47:51 2016 +

Fix incorrect assertion re sizeof TTEntryC on arm-linux.  Fixes #362935.


git-svn-id: svn://svn.valgrind.org/valgrind/trunk@15912


On Sun, 2019-03-17 at 08:59 -0400, Jeffrey Walton wrote:
> Hi Everyone,
> 
> I'm working on a Tinker Board
> (https://www.asus.com/us/Single-Board-Computer/Tinker-Board/). It is a
> Cortex-A17 with Debian 9.8. Debian provides Valgrind 3.12.
> 
> $ valgrind ./test.exe
> ==8876== Memcheck, a memory error detector
> ==8876== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
> ==8876== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright 
> info
> ==8876== Command: ./test.exe
> ==8876==
> 
> valgrind: m_transtab.c:2459 (vgPlain_init_tt_tc): Assertion
> 'sizeof(TTEntryC) <= 88' failed.
> Segmentation fault
> 
> A quick pass in the bug tracker did not show hits for the error, so
> I'm guessing it has not been reported.
> 
> $ apt-cache show valgrind
> Package: valgrind
> Source: valgrind (1:3.12.0~svn20160714-1)
> Version: 1:3.12.0~svn20160714-1+b1
> Installed-Size: 29965
> Maintainer: Alessandro Ghedini 
> Architecture: armhf
> ...
> 
> I can provide remote access to the board. I need authorized_keys.
> 
> Jeff
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] VEX temporary storage exhausted

[Philippe Waroquiers]

On Tue, 2019-03-19 at 19:05 +0100, Yuri D'Elia wrote:
> Hi everyone. It looks like the impossible happened. I was attempting to
> blindly run valgrind on debian unstable against slic3r-pe (mostly c++,
> which itself uses wxWidgets 3.1), both freshly compiled using gcc 8.3
> and got the following:
> 
> $ valgrind ./src/slic3r-gui
> ==19253== Memcheck, a memory error detector
> ==19253== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==19253== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==19253== Command: ./src/slic3r-gui
> ==19253==
> VEX temporary storage exhausted.
> Pool = TEMP,  start 0x59640548 curr 0x59b04c90 end 0x59b05087 (size 500)
> 
> vex: the `impossible' happened:
>VEX temporary storage exhausted.
> Increase N_{TEMPORARY,PERMANENT}_BYTES and recompile.
> vex storage: T total 5219676632 bytes allocated
> vex storage: P total 512 bytes allocated
> 
> valgrind: the 'impossible' happened:
>LibVEX called failure_exit().
> 
> host stacktrace:
> ==19253==at 0x580480A4: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x580481B7: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x5804840B: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x5804842A: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x5805EEB4: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x5814153A: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x581415BD: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x581E405C: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x581CE277: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x581CF618: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x5813EB58: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x58061976: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x580A524B: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x580A71EF: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> ==19253==by 0x580F5D80: ??? (in 
> /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
A 'classically' installed valgrind will give file and linenr in the host 
backtrace/

> 
> sched status:
>   running_tid=1
> 
> Thread 1: status = VgTs_Runnable (lwpid 19253)
> ==19253==at 0x541A124: (anonymous 
> namespace)::wxPNGImageData::DoLoadPNGFile(wxImage*, 
> (ab/libwx_gtk3u_core-3.1.so.2.0.0)
> ...
> ...
> 
> Is that the kind of impossible that I should fix by increasing the
> buffer, or it's the kind of impossible you want to know more about? ;)

The easiest is to increase the constants significantly (e.g. * 10)
and recompile/retest.  If after that it works, then it would be nice to
understand why your application needs so much temporary space.
(and maybe have an idea of really how much your app needs).

If that does not solve the problem, then I guess a small reproducer will
help to investigate ...

Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind hangs on my RHEL-7 box

[Philippe Waroquiers]

Some more info is needed to guess what the problem
could be.

Debug your program when running under valgrind using
   gdb + vgdb.

Compare the behaviour e.g. with gdb+vgdb between the non working
system and a working system
and/or compare the -v -v -v -d -d -d traces.


Philippe

On Tue, 2019-03-19 at 09:42 -0600, Matthew Bettencourt via Valgrind-users wrote:
> When I run a real program valgrind hangs on my redhat desktop, however I 
> can run on other systems with the same executable.
> 
> 
> I ran
> 
> 
> valgrind -v -v -v -d -d -d myprog.exe
> 
> 
> and it spits out a lot of output and then sits there for many minutes, 
> I've let it sit for overnight and no progress.
> 
> 
> I'm guessing some system configuration, but I googled and looked around 
> and didn't see anything that could cause this..
> 
> 
> The last set of output is below, but it doesn't lend any clue to me..
> 
> --2921-- di_notify_mmap-4: noting details in DebugInfo* at 0x100920A7E0
> --2921-- di_notify_mmap-5: achieved accept state for 
> /projects/sems/install/rhel7-x86_64/sems/compiler/gcc/7.2.0/openmpi/1.10.1/lib/openmpi/mca_grpcomm_bad.so
> --2921-- Reading syms from 
> /projects/sems/install/rhel7-x86_64/sems/compiler/gcc/7.2.0/openmpi/1.10.1/lib/openmpi/mca_grpcomm_bad.so
> --2921--    svma 0x000e10, avma 0x002fe04e10
> --2921-- cfsi range rx-mappings coverage check: Covered 
> 0x0-0x
> --2921-- di_notify_mmap-0:
> --2921-- di_notify_mmap-1: 0x30007000-0x30807fff rw-
> --2921:1: aspacem allocated valgrind thread stack at 0x100abec000 size 
> 1064960
> --2921:2:  stacks   register [start-end] [0x30008000-0x30806FFF] as stack 1
> --2921:1:syswrap- run_a_thread_NORETURN(tid=2): pre-thread_wrapper
> --2921:1:syswrap- thread_wrapper(tid=2): entry
> --2921-- di_notify_mmap-0:
> --2921-- di_notify_mmap-1: 0x4022000-0x4026fff rw-
> 
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] VEX temporary storage exhausted

[Philippe Waroquiers]

On Wed, 2019-03-20 at 00:01 +0100, Yuri D'Elia wrote:
> On Tue, Mar 19 2019, Philippe Waroquiers wrote:
> > > ==19253==by 0x580A524B: ??? (in 
> > > /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> > > ==19253==by 0x580A71EF: ??? (in 
> > > /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> > > ==19253==by 0x580F5D80: ??? (in 
> > > /usr/lib/x86_64-linux-gnu/valgrind/memcheck-amd64-linux)
> > 
> > A 'classically' installed valgrind will give file and linenr in the host 
> > backtrace/
> 
> I don't have valgrind debugging symbols currently installed.
> 
> > The easiest is to increase the constants significantly (e.g. * 10)
> > and recompile/retest.  If after that it works, then it would be nice to
> > understand why your application needs so much temporary space.
> > (and maybe have an idea of really how much your app needs).
> 
> Could this buffer be made tunable in the future?
> I so far always used a pre-compiled version of valgrind.
I do not think that this would be particularly difficult,
but up to now, the preferred approach was always to just have
a big enough fixed size, and increase it when an unexpected
set of instructions implies a bigger size.

Note that compiling valgrind from source is quite easy, in particular
if you use a release: there is almost no dependencies.
Starting from the git repository is only slightly more complex
(you need auto tools etc).

So, I recommend compiling from sources for a case like this.

> 
> > If that does not solve the problem, then I guess a small reproducer will
> > help to investigate ...
> 
> This is not something I wrote, although there's a double-free I wanted
> to investigate. It's also not a small program, linking with quite a few
> large libraries.
> 
> But it's all fully OSS. I could provide the binaries or a VM with the
> executable pre-loaded if somebody is interested in having a look.

Easiest thing to try initially is to recompile with a bigger size.

Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] location of stack allocation printed a at 0x8B43AF0: ??? ...

[Philippe Waroquiers]

On Thu, 2019-03-21 at 20:00 +0100, Matthias Apitz wrote:
> Hello,
> 
> Why are only the '???' marks printed for the localtion of the stack
> allocation? This is with 3.18.0 on Linux x64:
3.18.0 ?
Last release is 3.14.

> 
> ==24390== Conditional jump or move depends on uninitialised value(s)
> ==24390==at 0x8B5DC3A: CatTmFilterExclude (CATTmFilter.c:215)
> ==24390==by 0x8B8069C: SRVCatSearchMedia (SRVCatSearchMedia.c:579)
> ==24390==by 0x74D3683: SlnpRunModule (SLNPInterpreter.c:567)
> ==24390==by 0x74D31C7: SlnpInterpreter (SLNPInterpreter.c:287)
> ==24390==by 0x414543: SlnpMainLoop (OPServer.c:874)
> ==24390==by 0x413ED3: OPServer (OPServer.c:258)
> ==24390==by 0x413792: main (OPDaemon.c:407)
> ==24390==  Uninitialised value was created by a stack allocation
> ==24390==at 0x8B43AF0: ??? (in /home/sisis/guru/libcopz39.so)
> ==24390==
> 
> /home/sisis/guru # file libcopz39.so
> libcopz39.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
> dynamically linked, BuildID[sha1]=eb1d460ebb565dedfe48bf5f534d2c097d9ca59c, 
> with debug_info, not stripped
> 
> The *.o files in the shared lib have been compiled with 'gcc -m64 -g ...'

Can you check what file/line nr corresponds to 0x8B43AF0,
using another tool (gdb, or whatever) ?

Thanks

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] VEX temporary storage exhausted

[Philippe Waroquiers]

On Wed, 2019-03-20 at 23:20 +0100, Yuri D'Elia wrote:
> On Wed, Mar 20 2019, Philippe Waroquiers wrote:
> > Easiest thing to try initially is to recompile with a bigger size.
> 
> After bumping buffers 10x, I get this:
> 
> ==14645== Memcheck, a memory error detector
> ==14645== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==14645== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
> ==14645== Command: ./src/slic3r-gui
> ==14645==
> 
> valgrind: m_translate.c:1815 (vgPlain_translate): Assertion 'tres.status == 
> VexTransOK' failed.

Strange.
The only thing I see that can cause this failure is VexTransOutputFull.

So, the next trial is to bump x10
m_translate.c N_TMPBUF 

You have to edit similarly the 6 in VG_(add_to_transtab)

Philippe


> 
> host stacktrace:
> ==14645==at 0x58049D7C: show_sched_status_wrk (m_libcassert.c:369)
> ==14645==by 0x58049E97: report_and_quit (m_libcassert.c:440)
> ==14645==by 0x5804A034: vgPlain_assert_fail (m_libcassert.c:506)
> ==14645==by 0x58064ECC: vgPlain_translate (m_translate.c:1815)
> ==14645==by 0x580AAD4A: handle_chain_me (scheduler.c:1134)
> ==14645==by 0x580ACDCF: vgPlain_scheduler (scheduler.c:1483)
> ==14645==by 0x580FF770: thread_wrapper (syswrap-linux.c:103)
> ==14645==by 0x580FF770: run_a_thread_NORETURN (syswrap-linux.c:156)
> 
> sched status:
>   running_tid=1
> 
> Thread 1: status = VgTs_Runnable (lwpid 14645)
> ==14645==at 0x541E124: (anonymous 
> namespace)::wxPNGImageData::DoLoadPNGFile(wxImage*, (anonymous 
> namespace)::wxPNGInfoStruct&) [clone .constprop.45] (in 
> /usr/local/stow/wxWidgets-3.1.2/lib/libwx_gtk3u_core-3.1.so.2.0.0)
> ==14645==by 0x541F1B2: wxPNGHandler::LoadFile(wxImage*, wxInputStream&, 
> bool, int) (in 
> /usr/local/stow/wxWidgets-3.1.2/lib/libwx_gtk3u_core-3.1.so.2.0.0)
> ==14645==by 0x5400A93: wxImage::DoLoad(wxImageHandler&, wxInputStream&, 
> int) (in /usr/local/stow/wxWidgets-3.1.2/lib/libwx_gtk3u_core-3.1.so.2.0.0)
> ...
> 
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] massif problem - Unknown option: --undef-value-errors=no

[Philippe Waroquiers]

--undef-value-errors is not a massif option, it is a memcheck option.

So, it is completely normal that massif reports that this is an
unknown option.

If you want to have the list of options massif understands,
you have to do:
  valgrind --tool=massif --help

If you do not specify a tool, then valgrind defaults to memcheck.

Note that you can also prefix options with the tool they are
aimed at.
So, e.g. 
  valgrind --tool=massif --memcheck:undef-value-errors=no executable
does not complain.

Philippe

On Sat, 2019-02-16 at 15:20 +0200, / via Valgrind-users wrote:
> Hi people, I get the following error when I try to invoke "massif" in 
> the most simple manner:
> 
> valgrind: Unknown option: --undef-value-errors=no
> valgrind: Use --help for more information or consult the user manual.
> 
> Command to reproduce the error:
> 
> valgrind --verbose --tool=massif executable
> 
> where executable was the program i wanted to check (compiled with -g)
> 
> even a simple
> 
> valgrind --verbose --tool=massif /bin/bash
> 
> produces the same error
> 
> ** Valgrind version:
> valgrind-3.14.0
> 
> Fedora, linux 4.18.19-100
> 
> Many thanks,
> a.
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] massif problem - Unknown option: --undef-value-errors=no

[Philippe Waroquiers]

On Sat, 2019-02-16 at 17:49 +0200, / via Valgrind-users wrote:
> valgrind: Unknown option: --undef-value-errors=no
> valgrind: Use --help for more information or consult the user manual.

valgrind --help indicates:
 ...
 Extra options read from ~/.valgrindrc, $VALGRIND_OPTS, ./.valgrindrc

So, I guess that you have this option --undef-value-errors=no in one of the 
above.

Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] massif problem - Unknown option: --undef-value-errors=no

[Philippe Waroquiers]

On Sat, 2019-02-16 at 18:08 +0200, / wrote:
> My mistake, you are right, I had aliased valgrind to use 
> --undef-value-errors=no
> 
> thanks for your help and sorry for wasting your time.
No problem.

BTW, the 'tool prefix' for arguments (e.g. --memcheck:undef-value-errors=no)
was designed so that you can do such alias, but in a way that will work
with whatever tool.

Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind Finds More Dynamic Allocations than Inte Pin

[Philippe Waroquiers]

On Fri, 2019-02-08 at 21:02 +0330, Ahmad Nouralizadeh wrote:
> Thanks David,
> But heaptrack even reports a larger number: 153 MB!
> 
> On Fri, Feb 8, 2019 at 8:09 PM David Faure  wrote:
> > On vendredi 8 février 2019 16:32:50 CET Ahmad Nouralizadeh wrote:
> > > Hi,
> > > I wrote a really simple Pin tool to calculate the number of dynamically
> > > allocated bytes in a program. I instrumented GIMP with this tool and it
> > > reported 77 MB of allocations. I did the same experiment with Valgrind
> > > which reported 117 MB.
> > > My Pin tool is similar to the example in Pin. It searches for malloc(),
> > > calloc() and memalign() in each loaded image and adds instructions before
> > > them to calculate the total size of the allocations.
> > > I am really confused and need help!

What I suggest is to try with much smaller executables and investigate
when you see a difference.

For example, do the following in a valgrind build:
   valgrind --xtree-memory=full ./memcheck/tests/trivialleak
This will output the total allocations observed by valgrind.
It will also produce a file xtmemory.kcg.
that gives the detailed information about the malloc/free calls
(to visualise with kcachegrind).

Compare this with what is given by the 2 other measurements.
Try with somewhat more complex programs if you see no difference,
till you find a difference with (let's hope) something simple
enough that you can understand where the difference is coming from.

With valgrind, you can also trace all the malloc/free calls
using --trace-malloc=yes.

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Does valgrind work with Boehm garbage collector?

[Philippe Waroquiers]

On Sun, 2019-02-17 at 20:51 -0600, Peng Yu wrote:
> Hi,
> 
> I have the follow flex code using Boehm garbage collector.
> http://www.hboehm.info/gc/gcinterface.html
> 
> The program is compiled with the following commands.
> 
> $ flex -o main.l.c main.l
> $ clang -I. -DGC_DEBUG -Wall -pedantic -g -c -o main.l.o main.l.c #
> rapidstring.h is in .
> $ clang main.l.o -lgc -lfl -o main.l.exe
> $ dsymutil main.l.exe
> 
> rapidstring.h can be downloaded here.
> 
> https://raw.githubusercontent.com/boyerjohn/rapidstring/master/include/rapidstring.h
> 
> The following commands show that without using valgrind, the program
> runs OK. But if valgrind is used, the program will cause a
> segmentation fault.
> 
> Is it because valgrind does not work with a garbage collector?
It would not be very amasing that memcheck (that replaces malloc) would
conflict with something like Boehm gc, that for sure does strange
things with malloc replacement itself.

You might first try with --tool=none to see if the basis of valgrind+boehm gc 
works.

Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

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

[Philippe Waroquiers]

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

(or the same doc in the valgrind you compiled)

Philippe

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


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How to find memory leaks from an running application

[Philippe Waroquiers]

On Thu, 2019-06-20 at 11:04 +0530, subhasish Karmakar wrote:
> Hi,
> 
> I have an application running on embedded linux.
> After running for hours my application causes out of memory issue.
> How can I get memory leak report periodically when the application is running?
> It's a process with "while(1)" loop.

You can search leaks with valgrind while your program is running.

Different techniques can be used for that:
  * Inside your code, you add calls to client requests
such as VALGRIND_DO_LEAK_CHECK
  * From the shell, you can use 'vgdb' to launch
a leak search using the monitor request 'leak check'
  * Using gdb+vgdb, you can also launch such a leak check.
Compared to the previous techniques, the advantage is
that you can just put breakpoints where you want, and
launch leak searches when a breakpoints is reached.
You can also explore the 'logical leaks' (increase of
memory due to still reachable memory) using the monitor
request 'who_points_at'.

Note that these leak searches can show a 'delta leak' report,
i.e. pinpoint at the new allocations since the previous leak
search.

See user manual for more details, e.g.
http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
and 
http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver

Philippe

 


___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Getting SIGKILL to work in MariaDB

[Philippe Waroquiers]

On Tue, 2019-08-13 at 16:54 +0300, Michael Widenius wrote:

> I can try that at once. Thanks.
> Testing...
> hm.. It would be good to describe in README_DEVELOPERS how to generate the
> autoconfigure scripts.  Now it says one to run 'make dist', which will
> not work out of the box.
README has a section "Building and installing it".
It looks like README_DEVELOPERS should start with the same title,
and reference the README section.

> Same problem with README.solaris. Please add that one should run first
> 'autogen.sh' and then configure.
README.solaris has a pointer to the README file in the "Compilation" section,
but again that can be made more precise.

I will improve both files to add the relevant reference to README.



> Currently the kill signal is never sent to the process and the process
> continues to run.
Yes, that is the bug 409141 (fixed in the git version).

> 
> > You can avoid this interception by instead doing something like
> >system("kill -9 me");
> > as no way valgrind will be able to intercept this.
> > (of course, me has to be the pid of the calling process).
> 
> In this case the process, in this case mysqld, needs to know who it's
> 'father' process is.
> This is a bit hard to provide to mysqld, as we only know the pid after
> valgrind is started with mysqld as an option.  Another issue is that
> mysqld doesn't know if it's run under valgrind or not and it should
> only kill it's parent if it's valgrind.
Not sure I understand, so I will explain what I understood:
You used to have in a process some lines of code sending SIGKILL
to itself, so as to commit suicide ("hard exit").
Due to bug 409141, when running under valgrind, this hangs.
You have bypassed the problem by rather sending SIGFPE, but you would
like to go back to SIGKILL.
With the fix to 409141, sending SIGKILL again really kills
the process.

The remaining problem is that SIGKILL is still causing a leak search
to be done.

To really have an "hard exit", you can replace the lines of code sending SIGKILL
by the following 3 lines:
  char cmd[1000];
  sprintf(cmd, "kill -9 %d", getpid());
  system (cmd);
With this, you really have a "hard exit".

> (Assuming I understood correctly what you meant with  calling process;
> I think you mean the 'valgrind' process in this case)
Note that when a process "runs under valgrind", there is still only one
single process, which contains both the valgrind code and the code of
the program being run "under valgrind".
So, I am not sure to understand why there is anything
special to do related to parent process when running under valgrind.

> 
> > > Please open a bug at https://bugs.kde.org/enter_bug.cgi?product=valgrind
> > > and attach a minimal test case if at all possible.
> 
> Will try to create a test case, but it's not that easy as for simple
> programs valgrind seams to pass KILL forwards.  Maybe this is only a
> problem with threaded programs.
> 
> https://www.mail-archive.com/valgrind-users@lists.sourceforge.net/msg06862.html
> seams to highlight the same problem.
As far as I can see, this message and your problem of hanging after sending
SIGKILL is the bug 409141.
And you have double checked the git version also fixes the hanging bug.
So, IMO, there is no need to have another reproducer.


> I have now tested with 10.3.16.GIT from today and did run it with
> --trace-signals=yes.
> In this case the SIGKILL is sent to the process and the process is
> killed so it looks
> like the bugs is fixed. Great!
> However one problem still reminds. After the kill, we still get a
> report of leaks which
> is not that relevant when a process is killed hard.
> Hope you will figure out a way to stop this report!
Well, the valgrind signal sending interception code has rather be explicitly
designed to do various "end of life actions" (such as run the leak search)
when a process terminates or dies, including the case where a process
sends a fatal signal to itself.

It is of course possible to implement something to really have a "hard exit"
and/or disable leak search.  What is the best feature/way to do that is not
(yet) clear to me: a more general approach such as loading a supp file
or allow to change valgrind parameters is more attractive than e.g.
a very specialised request such as VALGRIND_HARD_EXIT();

In the meantime, if my understanding is correct,
   system ("kill -9 ..."); 
as explained above gives a hard exit without allowing valgrind to
intercept the signal and do a leak search or any other closing actions.

If that does not work/is not usable, then I have missed something in
what you are trying to do.

Further comments welcome ...

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Getting SIGKILL to work in MariaDB

[Philippe Waroquiers]

On Mon, 2019-08-12 at 13:49 +0100, Tom Hughes wrote:
> On 12/08/2019 13:15, Michael Widenius wrote:
> 
> > The request I would like you to consider is to do one of the following:
> > - Ensure that sending a sigkill works and in this case there should
> > not be any valgrind leak report.
What version of Valgrind are you using ?

I recently fixed (10 of July) in the git repository a bug with an infinite loop
or a hang when a process sends a signal to itself.

See bugs 409141 and 409367.

So, you might test with a recent git version of Valgrind.

> > - Add an api call where we could specify that we don't want any leak
> > reports from now on.  If this would exist then I could call this when
> > we are about to send the SIGFPE/SIGKILL signal to the server.
A stackoverflow discussion led to a suggestion to have a
monitor command/client request to load a new suppression file.
This would allow to load a supp file suppressing all leaks.

Allowing to load a suppression file via a client request might be useful
in other circumstances (the stackoverflow case was to avoid any leak
search when a program fails between a fork and an exec, but it
could be used to suppress flexibly whatever kind of errors and/or
automatically load a supp file e.g. when loading a shared lib).

Alternatively, the only reason why valgrind can do a leak search
when your process calls "kill (me, 9);"
is that valgrind is intercepting the syscall and does a leak
search before really self-killing.

You can avoid this interception by instead doing something like
   system("kill -9 me");
as no way valgrind will be able to intercept this.
(of course, me has to be the pid of the calling process).

Philippe



> 
> Please open a bug at https://bugs.kde.org/enter_bug.cgi?product=valgrind
> and attach a minimal test case if at all possible.
> 
> Also the output of running valgrind with --trace-signals=yes would be
> a good thing to provide.
> 
> Tom
> 



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Getting SIGKILL to work in MariaDB

[Philippe Waroquiers]

On Wed, 2019-08-21 at 14:44 +0200, Philippe Waroquiers wrote:
> On Mon, 2019-08-12 at 15:15 +0300, Michael Widenius wrote:
> > Something like the following would be very useful:
> > VALGRIND_IGNORE_LEAKS(VALGRIND_LEAK_INDIRECT | VALGRIND_LEAK_DEFINITE...)
> See patch attached to https://bugs.kde.org/show_bug.cgi?id=411134
> This patch allows to change various command line options after
> startup, including the options telling if/how to do a leak search.
Patch pushed today to the Valgrind git repository as 3a803036.

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Getting SIGKILL to work in MariaDB

[Philippe Waroquiers]

On Mon, 2019-08-12 at 15:15 +0300, Michael Widenius wrote:
> Something like the following would be very useful:
> VALGRIND_IGNORE_LEAKS(VALGRIND_LEAK_INDIRECT | VALGRIND_LEAK_DEFINITE...)
See patch attached to https://bugs.kde.org/show_bug.cgi?id=411134
This patch allows to change various command line options after
startup, including the options telling if/how to do a leak search.

Feedback welcome ...

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind: Heap block lo/hi size mismatch when trying to debug a C++ program running inside Docker container

[Philippe Waroquiers]

On Tue, 2019-11-12 at 20:18 -0800, Karthik Jayaraman wrote:
> 
> Thread 47: status = VgTs_Runnable (lwpid 1861)
> ==1747==at 0x4C2922D: free (vg_replace_malloc.c:540)
> ==1747==by 0x9A7CB7B: __libc_freeres (in /usr/lib64/libc-2.17.so)
> ==1747==by 0x4A24739: _vgnU_freeres (vg_preloaded.c:77)
> 
> client 
> stack range: ??? client SP: 0x289569C8
> 
> valgrind 
> stack range: [0x1009516000 0x1009615FFF] top usage: 5064 of 1048576
> 
> But the interesting fact is, it works wonderfully well when same binary is 
> running outside the container (on a VM). If my source binary has a memory 
> link (as per Valgrind FAQs) I am puzzled as to why I am not encountering the 
> issue when not running in a container. 

You are using the massif tool. Massif does not detect leaks or errors,
it rather produces a report about the memory used (evolution, peak, ...).

The above seems to be a crash at the time your program terminates,
as the glibc __libc_freeres is called by valgrind function _vgnU_freeres
at exit.

If your program crashes at exit in __libc_freeres, it is recommended
to use --run-libc-freeres=no: the user manual indicates to use this
for buggy glibc. See user manual for more details.

The fact that it crashes inside a docker and not in another environment
might be explained by different glibc version or (as John said) because
of another layout of the memory.

Philippe
 






___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] kill the process cause system crash

[Philippe Waroquiers]

On Thu, 2019-12-19 at 17:32 +, Rachel Chen (rychen) wrote:
> Hi Philippe,
> 
> Thanks for your help!
> 
> I am running this on a linux switch.
What CPU ? What version of linux ?

>  The Valgrind I am using is 2.15.
2.15 is not a known valgrind version. 
The valgrind version can be retrieved doing:  valgrind --version
Recent valgrind will give a more extended version doing:  valgrind --version -v

>  There is no error message/output when the crash happens.
It was not clear to me that the whole system (kernel) crashed,
I thought you were speaking about your "application system" crashing.

valgrind is supposed to be a 'normal' user level process, so if ever
valgrind crashes the kernel, then that is a kernel bug :).
Note that valgrind takes a lot of resources (memory/cpu),
that might put some stress on the system.

>  But I noticed after the system bootup again, the valgrind log file seems do 
> have some info there...
> 
> I will check the link below to see if I can trigger memory leak search 
> without killing the process. 
Ok.
Note that the given links document the last released version of valgrind.
Philippe

> 
> Thanks,
> Rachel
> 
> 
> On 12/18/19, 10:42 PM, "Philippe Waroquiers"  
> wrote:
> 
> On Thu, 2019-12-19 at 00:19 +, Rachel Chen (rychen) via 
> Valgrind-users wrote:
> > Hello,
> >  
> > I am using Valgrind to debug a memory leak. Somehow when I try to kill 
> the process to get the log file with memory leak, it crash the system. I am 
> using the following command to get the pid and kill the pid:
> >  
> > Ps -ef | grep valgrind. è to get the pid
> > Kill 
> >  
> > Any idea what might be wrong here? Thanks for the help in advance!
> >  
> > Thanks,
> > Rachel
> 
> Some more information is needed :
>   * which platform ?
>   * which version of valgrind ?
>   * what is the error message/output when the crash happens ?
> 
> Note that you can trigger memory leak search from the shell (or from gdb)
> by using vgdb, without killing your process.
> 
> See the below links for more information.
> 
> 
> http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.valgrind-monitor-commands
> 
> 
> http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-commandhandling
> 
> 
> http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
> 
> Philippe
> 
> 
> 
> 



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] kill the process cause system crash

[Philippe Waroquiers]

On Thu, 2019-12-19 at 00:19 +, Rachel Chen (rychen) via Valgrind-users 
wrote:
> Hello,
>  
> I am using Valgrind to debug a memory leak. Somehow when I try to kill the 
> process to get the log file with memory leak, it crash the system. I am using 
> the following command to get the pid and kill the pid:
>  
> Ps -ef | grep valgrind. è to get the pid
> Kill 
>  
> Any idea what might be wrong here? Thanks for the help in advance!
>  
> Thanks,
> Rachel

Some more information is needed :
  * which platform ?
  * which version of valgrind ?
  * what is the error message/output when the crash happens ?

Note that you can trigger memory leak search from the shell (or from gdb)
by using vgdb, without killing your process.

See the below links for more information.

http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.valgrind-monitor-commands

http://www.valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver-commandhandling

http://www.valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Calling arbitrary guest functions

[Philippe Waroquiers]

You might find some inspiration by reading the function final_tidyup
in coregrind/m_main.c.

final_tidyup is calling some client code part of malloc library.

Philippe


On Thu, 2020-03-05 at 11:27 -0500, Derrick McKee wrote:
> My intent is to write a tool that waits for another process to write
> client addresses to a pipe, and then execute the specified function
> with a fixed number of arguments.  I'm unconcerned about whether the
> specified function actually has the assumed arity or not, though.  I
> tried the following, but it seems that the function is not called.
> However, this is what I am wanting to do.
> -
> static void SE_(start_client_code)(ThreadId tid, ULong blocks_dispatched) {
>   if (!client_running && tid == client_thread_id) {
> VG_(umsg)
> ("Thread %u is starting executing at instruction 0x%lx with "
>  "blocks_dispatched=%llu\n",
>  tid, VG_(get_IP)(tid), blocks_dispatched);
> client_running = True;
> VG_(umsg)("Thread %u is about to call target function\n", tid);
> OrigFn fn;
> fn.nraddr = (Addr)0x401145; // Function address in client
> CALL_FN_v_v(fn);  // Assume no arguments are passed in
> VG_(umsg)("Thread %u returned\n", tid);
> client_running = False;
>   }
> }
> 
> static void SE_(pre_clo_init)(void) {
> 
> VG_(track_start_client_code)(SE_(start_client_code));
> }
> 
> VG_DETERMINE_INTERFACE_VERSION(SE_(pre_clo_init))
> --
> Reading the documentation, it seems that CALL_FN_v_v should be called
> from the client code, but I want to use my tool with any binary.  I
> also tried using the VG_(set_IP) function (admittedly against the
> valgrind tool contract), but that seemingly didn't work either.  Any
> other thoughts, or is this just something I cannot do with valgrind?
> 
> On Tue, Mar 3, 2020 at 11:01 AM Derrick McKee  wrote:
> > I am also interested in instrumenting the guest binary, as well as
> > change which guest function I execute at run time.  So LD_PRELOAD
> > won't help me here.
> > 
> > On Tue, Mar 3, 2020 at 10:41 AM John Reiser  wrote:
> > > > I am trying to make a tool that intercepts the call to main, and then
> > > > call an arbitrary function within the guest with arbitrary function
> > > > arguments.
> > > 
> > > This can be done without valgrind by using LD_PRELOAD environment variable
> > > and RTLD_NEXT (see "man dlsym"):
> > > 
> > >  LD_PRELOAD=main_interceptor.so  ./my_app args...
> > > 
> > > where main_interceptor.so is a shared library that has a function main()
> > > and that can call the original main() by using dlsym(RTLD_NEXT, "main").
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > 
> > > ___
> > > Valgrind-users mailing list
> > > Valgrind-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> > 
> > 
> > --
> > Derrick McKee
> > Phone: (703) 957-9362
> > Email: derrick.mc...@gmail.com
> 
> 



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How to disable leak check from inside a program

[Philippe Waroquiers]

On Fri, 2020-05-22 at 15:22 +0300, Michael Widenius wrote:
> Hi!
> I have searched documentation, internet and header files like
> memcheck.h, but not found a solution:
> 
> When running the MariaDB test suite under valgrind, we sometimes may
> get a core dump.  In this case, the leaked memory report can be very
> long and will be totally useless.
> 
> What would help a lot is to have a VALGRIND request, like
> VALGRIND_DO_CLIENT_REQUEST_STMT, that we could use in our signal
> handler to turn off leak checking.
> 
> Is that possible and if not, is that something that could get
> implemented in the future?
> Is this something that anyone else has ever requested ?
> 
> Regards,
> Monty

Hello,

The next version of valgrind is almost ready (Release Candidate was produced
a few days ago).

This release contains a feature to dynamically change many options.

You can obtain the list of dynamically changeable options doing:

 valgrind --help-dyn-options

For memcheck, this gives the below help.
Based on this, you should be able to obtain what you need.

Hope this helps

Philippe


valgrind --help-dyn-options
Some command line settings are "dynamic", meaning they can be changed
while Valgrind is running, like this:
From the shell, using vgdb. Example:
  $ vgdb "v.clo --trace-children=yes --child-silent-after-fork=no"
From a gdb attached to the valgrind gdbserver. Example:
  (gdb) monitor v.clo --trace-children=yes --child-silent-after-fork=no"
From your program, using a client request. Example:
  #include 
  VALGRIND_CLO_CHANGE("--trace-children=yes");
  VALGRIND_CLO_CHANGE("--child-silent-after-fork=no");

  dynamically changeable options:
-v --verbose -q --quiet -d --stats --vgdb=no --vgdb=yes --vgdb=full
--vgdb-poll --vgdb-error --vgdb-stop-at --error-markers --show-error-list -s
--show-below-main --time-stamp --trace-children --child-silent-after-fork
--trace-sched --trace-signals --trace-symtab --trace-cfi --debug-dump=syms
--debug-dump=line --debug-dump=frames --trace-redir --trace-syscalls
--sym-offsets --progress-interval --merge-recursive-frames
--vex-iropt-verbosity --suppressions --trace-flags --trace-notbelow
--trace-notabove --profile-flags --gen-suppressions=no
--gen-suppressions=yes --gen-suppressions=all --errors-for-leak-kinds
--show-leak-kinds --leak-check-heuristics --show-reachable
--show-possibly-lost --freelist-vol --freelist-big-blocks --leak-check=no
--leak-check=summary --leak-check=yes --leak-check=full --ignore-ranges
--ignore-range-below-sp --show-mismatched-frees
valgrind: Use --help for more information.



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] correct self-modifying-code for Valgrind

[Philippe Waroquiers]

Valgrind has a lot of heuristics to optimise the speed of the JIT-ted code.
One of these heuristics is to chase jumps/calls to known destination.

This is somewhat similar to inlining performed by the compiler,
but performed by valgrind at runtime, when it encounters a new call/jump.

In this case, the function f1 is inlined twice following this heuristic.
So, the second inlining is using the modified function.

If you disable chasing, then the code prints twice the same value:
  valgrind --tool=none --smc-check=none --vex-guest-chase=no ...
produces twice 4660 as output.

Also, if you do a loop 
  for (int j = 0; j < 2; j++) {
 f1();
  here modify f1 code
  }

then valgrind inserts only once the code of f1, and it prints twice the same
value, whatever the parameter --vex-guest-chase

The code that does the self modifying code check is in the function 
needs_self_check
in m_translate.c.  This function is called by VEX.

Philippe


On Fri, 2020-08-28 at 12:15 +0200, Duc Nguyen wrote:
> Hello everyone,
> 
> I am trying the self-modifying-code check of Valgrind but I am not sure if I 
> understand the definition of  self-modifying-code in Valgrind correctly. 
> 
> I had prepared an example (see below) that has function f1 that is first 
> executed in main, outputs something (number 4660). Afterward, two 
> instructions of f1 are modified, and f1 is then executed one more time. It 
> then outputs something (number 22068) that is different from the first time. 
> 
> When I run Valgrind with --smc-check=all and  --smc-check=none I do not see 
> any difference in the outputs of Valgrind e.g., both times f1 produces 
> different numbers (e.g., self-modifying-code successfully runs despite the 
> --smc-check if turned on or off)
> 
> Could someone please let me know if this behavior is expected from Valgrind?
> 
> I further looked into the source code and found 
> valgrind\VEX\priv\guest_generic_bb_to_IR.c that generates the code to check. 
> However, I do not know where such a check is executed. It would be great if 
> somebody knows where such a check takes place, and where we can modify the 
> source code to just simply say e.g., self-modifying-code is found.
> 
> Thank you very much in advance.
> 
> Best regards,
> Duc
> 
> 
> =
> Self-modifying-code example
> ---
> 
> 
> 
> #include 
> #include 
> #include 
> 
> __asm__( ".text" );
> __asm__( ".align 4096" );
> 
> void f1( void )
> {
>   printf( "%d\n", 0x1234 );
> }
> void f2( void ){
>   printf("this is just a dummy function");
> }
> 
> int main( void )
> {
>   int rc;
>   int pagesize;
>   char *p;
>   int i;
> 
>   printf( "f1=0x%08X.\n", f1 );
> 
>   f1( );
> 
>   pagesize = sysconf( _SC_PAGE_SIZE );
>   printf( "pagesize=%d (0x%08X).\n", pagesize, pagesize );
>   if( pagesize == -1 )
> return( 2 );
> 
>   p = (char*) f1;
>   rc = mprotect( p, pagesize, PROT_READ | PROT_WRITE | PROT_EXEC );
>   printf( "rc=%d.\n", rc );
>   if( rc != 0 )
> return( 2 );
>   printf( "'mprotect()' succeeded.\n" );
> 
> 
>   for( i = 0; i+1 < (size_t) f2- (size_t)f1; i++ ) {
>  if( ((char*) f1)[ i ] == 0x34  && ((char*) f1)[ i+1 ] == 0x12 ) {
>  
>  ((char*) f1)[ i+1 ] =0x78;//here performs self-modifying-code
>  ((char*) f1)[ i+1 ] =0x56;//here performs self-modifying-code
>  }
>}
>   
>   f1( );//here the output of f1 will be different from the first f1() call
> 
>   printf( "Call succeeded.\n" );
>   return( 0 );
> }
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] valgrind always fails with out of memory

[Philippe Waroquiers]

On Tue, 2020-09-08 at 14:09 +0200, Mario Emmenlauer wrote:
> On 08.09.20 12:25, Mario Emmenlauer wrote:
> > On 08.09.20 12:04, Mario Emmenlauer wrote:
> > > The error I get most frequently is (full output attached in log.txt)
> > > ==32== Valgrind's memory management: out of memory:
> > > ==32==newSuperblock's request for 6864695621860790272 bytes 
> > > failed.
> > > ==32==  114,106,368 bytes have already been mmap-ed ANONYMOUS.
> > 
> > Argh! After sending the email, I went through the stack trace for
> > the hundredth time, and spotted the use of "zlib". And indeed, when
> > replacing my own zlib 1.2.11 with the system zlib 1.2.11, valgrind
> > works as expected!
> > 
> > Does that make sense? Is zlib used by valgrind itself? And why could
> > my debug build differ (so much) from the system zlib that it breaks
> > valgrind? I double-checked and its the identical source code from
> > Ubuntu, just missing two or three patches.
> 
> So it seems I can (partially) answer my own question: when valgrind
> is used on an executable that links zlib built with -ggdb3, then it
> does not work (due to aforementioned error). Keeping all other debug-
> settings except -ggdb3 works still fine.
> 
> I have no clue as to _why_ this may happen, but I hope it can be
> helpful to other people running into the same issue.
zlib is not used by the valgrind tools. In fact, valgrind tools
do not use any library (even not libc).

The above newSuperblock trace shows that a *huge* block is requested.
As this bug only happens when you use -ggdb3, this is likely a problem
in the debuginfo reader of valgrind: some debug info generated by 
-ggdb3 is very probably not handled properly.

I have recompiled libz with -ggdb3, but no problem when running this
lib under valgrind.

We might have a more clear idea of what happens on your side 
by adding some trace.

The best is to file a bug on bugzilla, and attach the output of
running valgrind with -d -d -d -v -v -v.

That might give some information about what is wrong
and possibly some more detailed trace can then be activated.

Thanks
Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] massif & counts per type

[Philippe Waroquiers]

On Fri, 2020-09-11 at 12:38 +0200, Milian Wolff wrote:
> And finally, with heaptrack it is also not yet easily doable to get a diff 
> between two time stamps. Also a feature I've long thought about implementing, 
> but never got around to...
Note that valgrind allows to report a "delta/diff" memory heap status e.g.
under memcheck. See memcheck leak_check monitor command.

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] massif & counts per type

[Philippe Waroquiers]

On Thu, 2020-09-10 at 15:26 +0200, folkert wrote:
> Hi,
> 
> How can I obtain the number of mallocs per type in a time-frame using
> massif? I'm NOT interested in the total in use, I would like to know how
> often type x is allocated between t+1 and t+2.
You could run your application under valgrind + gdb/vgdb.
You can then put breakpoints at relevant places to trigger them at
t+1 and t+2.

You can then e.g. run with memcheck and have delta malloc info
being reported, using the memcheck monitor command leak_check.
This command can show the delta "alloc/free" since the previous
call.

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Use of valgrind with microthreading

[Philippe Waroquiers]

On Fri, 2020-08-14 at 19:16 +0200, Mark Wielaard wrote:
> Hi Shachar,
> 
> On Fri, Aug 14, 2020 at 06:35:14PM +0300, Shachar Shemesh wrote:
> > I am writing my own C++ microthreading library. At the very first switch, I
> > get the following message from Valgrind:
> > 
> > ==15122== Warning: client switching stacks?  SP change: 0x1ffeffe788 -->
> > 0x75d0f80
> > ==15122==  to suppress, use: --max-stackframe=137298630664 or
> > greater
> > 
> > 
> > I understand that valgrind needs to know where the stack starts and ends. I
> > am wondering whether is any way I can tell it that information. Since I'm
> > writing the library, what I was thinking was compiling the library with a
> > special flag saying "you're running with valgrind", and then have my library
> > call a valgrind function that says "This is the new stack range, this is the
> > old one".
> >  
> > Is there such a thing? If so, how do I interface with it?
> 
> Yes, there is such a thing. The valgrind client request mechanism:
> https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq
> 
> It does have various VALGRIND_STACK_* macros to signal use of user
> threads/stacks. But note that the documentations says:
> Warning: Unfortunately, this client request is unreliable and best avoided.
> Unfortunately I don't know why that is, or what alternative mechanisms there 
> are.

I also do not know what the 'unreliable' doc warning points at.
Searching in bugzilla, there are a few bugs that are related to such STACK 
requests:
Bug 202463 - VALGRIND_STACK_{REGISTER,DEREGISTER,CHANGE} are unreliable 
Bug 133154 - crash when using client requests to register/deregister stack

However, some years ago, I did various improvements to the stack handling code
in order to better support running valgrind under valgrind: the inner valgrind 
is
using such client requests to inform the outer valgrind about the inner stacks.

So, IMO, these requests should (could?) work reasonably well.

Philippe

 




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind installation on AIX environment

[Philippe Waroquiers]

Hello

Support for AIX was removed I believe in 2011.

Philippe


On Thu, 2020-12-17 at 12:31 +, SHAIKH Mohammadshaeeque wrote:
> Hello Valgrind Team,
>  
> I am interested to use Valgrind tool to detect memory leak issue on AIX for 
> C++ programs,
> I want to know whether Valgrind tools supports for below type of specs 
> environment?
>  
> AIX 7.1
> System Model: IBM,8284-22A
> Processor Type: PowerPC_POWER8
> Processor Implementation Mode: POWER 7
> CPU Type: 64-bit
> Kernel Type: 64-bit
> Xlc compiler
> dbx debugger
>  
> If yes then, please suggest to install on AIX which modification is needed on 
> configure.sh file or other modifications.
>  
> Please provide your input.
>  
> Thanks,
> Mohammadshaeeque SHAIKH.
>  
>  
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Why valgrind tool massif does not print xtree callstack? (arm)

[Philippe Waroquiers]

Strange ... 'v.info scheduler' shows that valgrind can compute a correct guest
stack trace, but the output file is not correct.

It looks like with gdb+vgdb, you cannot put a breakpoint on a redirected 
function:
 valgrind/massif redirects malloc function to its own implementation, and so
 the breakpoint is not reached (at least for me, on amd64 platform).

Also, the host stack trace is empty in the below 'v.info scheduler' output.


Does memcheck give the same unexpected behaviour for its (leak) reports ?

What does memcheck give if you use --xtree-memory=full ?

Can you try the same gdb+vgdb+ break malloc experiment using --tool=none ?

Thanks

Philippe



On Mon, 2020-12-14 at 10:26 +0100, Łukasz Bolda wrote:
> I'm using valgrind 3.14.0 from 
> http://ftp.debian.org/debian/pool/main/v/valgrind/
> Cause it's stable version.
> 
> I did not compile this application.
> 
> Right now i'm trying latest valgrind 3.16.1 and it changed from this:
> 99.87% (20,675,133B) (heap allocation functions) malloc/new/new[], 
> --alloc-fns, etc.
> ->99.87% (20,675,133B) 0x: ???
> 
> to this (different app, but the only change is from 0x to 0x0):
> 99.82% (46,610B) (heap allocation functions) malloc/new/new[], --alloc-fns, 
> etc.
> ->99.82% (46,610B) 0x0: ???
> 
> 
> Using "(gdb) break malloc" and then "(gdb) bt"produces regular callstack
> 
> 
> Also using  gdb+vgdb is producing correct backtrace:
> (gdb) monitor v.info scheduler
> 
> Host stacktrace:
> ==1543== at 0x5800B148: ??? (in 
> /home/root/lbolda/vg16/usr/lib/arm-linux-gnueabihf/valgrind/massif-arm-linux)
> 
> sched status:
>   running_tid=1
> 
> Thread 1: status = VgTs_Runnable (lwpid 1543)
> ==1543==  at 0x42826: service_main(int, char const**, bool) 
> (serviceMain.cpp:155)
> ==1543==  by 0x41D1F: main (serviceMain.cpp:17)
> client stack range: [0x7DDE5000 0xDDE8FFF] client SP: 0x7DDE86A8
> valgrind stack range: [0x41E82000 0x41F81FFF] top usage: 25600 of 1048576
> 
> Thread 2: status = VgTs_WaitSys syscall 285 (lwpid 1560)
> (...)
> Thread 3: status = VgTs_WaitSys syscall 285 (lwpid 1561)
> (...)
> 
> 
> Thank you for helping me!
> 
> Best regards,
> Łukasz Bolda
> 
> 
> -Original Message-
> From: Philippe Waroquiers  
> Sent: Friday, December 11, 2020 4:31 PM
> To: Łukasz Bolda ; 
> valgrind-users@lists.sourceforge.net
> Subject: Re: [Valgrind-users] Why valgrind tool massif does not print xtree 
> callstack? (arm)
> 
> Which version of valgrind are you using ?
> You much better should use the last released version (or a more recent GIT 
> version).
> 
> Have you compiled your application with -g ?
> 
> In case you debug your native executable with gdb and put a break on malloc, 
> is gdb backtrace command giving a good stack trace ?
> 
> If you then debug using  gdb+vgdb your executable running under valgrind, is 
> then the gdb backtrace correct ?
> And when positioned on the break point, what is the output of
>(gdb) monitor v.info scheduler
> 
> Thanks
> Philippe
> 
> On Fri, 2020-12-11 at 15:02 +0100, Łukasz Bolda wrote:
> > Hello!
> > This is my first message on this list, so I'd like to say hi to everyone!
> > 
> > I'm profiling my software using valgrind tool massif  on arm hardware 
> > with parameters like this:
> > valgrind --tool=massif --massif-out-file=massif.out.%p 
> > --xtree-memory=full --verbose MY_BIN
> > 
> > Unfortuatelly i do not receive any callstack in the results:
> > ms_print massif.out.1234
> > (...)
> > 99.87% (20,675,133B) (heap allocation functions) malloc/new/new[], 
> > --alloc-fns, etc.
> > ->99.87% (20,675,133B) 0x: ???
> > 
> > 
> > What sould i do to receive full callstacks from massif?
> > 
> > Same thing happens when i'm using this tool on system binary for eg. ls.
> > Only 0x is present.
> > 
> > On my x86 machine everything runs fine.
> > 
> > Greetings,
> > Łukasz Bolda
> > 
> > 
> > 
> > 
> > ___
> > Valgrind-users mailing list
> > Valgrind-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Why valgrind tool massif does not print xtree callstack? (arm)

[Philippe Waroquiers]

Which version of valgrind are you using ?
You much better should use the last released version (or a more recent GIT 
version).

Have you compiled your application with -g ?

In case you debug your native executable with gdb and put a break on malloc,
is gdb backtrace command giving a good stack trace ?

If you then debug using  gdb+vgdb your executable running under valgrind,
is then the gdb backtrace correct ?
And when positioned on the break point, what is the output of
   (gdb) monitor v.info scheduler

Thanks
Philippe

On Fri, 2020-12-11 at 15:02 +0100, Łukasz Bolda wrote:
> Hello!
> This is my first message on this list, so I'd like to say hi to everyone!
> 
> I'm profiling my software using valgrind tool massif  on arm hardware with
> parameters like this:
> valgrind --tool=massif --massif-out-file=massif.out.%p --xtree-memory=full
> --verbose MY_BIN
> 
> Unfortuatelly i do not receive any callstack in the results:
> ms_print massif.out.1234
> (...)
> 99.87% (20,675,133B) (heap allocation functions) malloc/new/new[],
> --alloc-fns, etc.
> ->99.87% (20,675,133B) 0x: ???
> 
> 
> What sould i do to receive full callstacks from massif?
> 
> Same thing happens when i'm using this tool on system binary for eg. ls.
> Only 0x is present.
> 
> On my x86 machine everything runs fine.
> 
> Greetings,
> Łukasz Bolda
> 
> 
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Malloc/free in different threads

[Philippe Waroquiers]

Hello,

No, valgrind/memcheck leak search is not impacted by the fact that one thread 
allocates
some memory and that the release/free is done by another thread.
That should not lead to a definite leak.

So, if Valgrind tells that there are definite leaks, that is likely real leaks
to be investigated.

Philippe


On Fri, 2020-12-18 at 14:53 +, Saurabh T wrote:
> Sorry I forgot to say the false positives are for memory leaks ("definitely 
> lost").
> 
> 
> From: Saurabh T 
> Sent: Friday, December 18, 2020 9:44 AM
> To: Valgrind 
> Subject: [Valgrind-users] Malloc/free in different threads 
>  
> Hi, I believe I am seeing lots of false positives in valgrind if I call 
> free() on a different thread from the one that called malloc() - 
> the pointers are exchanged between threads safely in between. Is this a known 
> issue, or am I doing something wrong? Thank you.
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] How to include the Valgrind stack traces in a stand-alone debug version?

[Philippe Waroquiers]

On Mon, 2021-05-24 at 10:31 -0700, Martin Licht via Valgrind-users wrote:
> Hello,
> 
> I think the Valgrind stack tracer is pretty great and I would like to use it 
> as a substitute for `backtrace` in my C++ debug builds.
> 
> A blog post by Nicholas Nethercote (Using Valgrind to get stack traces) 
> describes a similar idea:
> https://blog.mozilla.org/nnethercote/2011/01/11/using-valgrind-to-get-stack-traces/
> 
> However, while this is already fairly elegant, I am wondering whether this 
> can be done without invoking the program under valgrind.
> 
> If the Valgrind stack tracer were a simple #include that would be best. 
> Alternatively, a means of including any necessary valgrind framework into the 
> debug build would be helpful. I appreciate your feedback.
The valgrind unwinder is very fast, so having it as a "standalone" library that 
can be
linked to a normal executable and used outside of the valgrind JIT framework 
would
be really nice. 

However, I think this unwind logic/code has a lot of dependencies
to other parts of valgrind (debug info reader, address space manager, valgrind 
own malloc
library, valgrind log and debug framework, ...).

So, clearly not a small task to 'cleanly' lib-ify the valgrind unwinder,
in particular if this library must then be usable both in a valgrind context 
and in a
'native' context.

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] No used_suppression in verbose memcheck output

[Philippe Waroquiers]

If you use xml output, the used suppressions are only output when
you give the option --show-error-list=yes.

With xml, increasing the verbosity will not show the used suppressions.
Likewise, when xml output is selected, no ERROR SUMMARY is output
(and probably some other textual output is similarly not produced in xml).

The idea is that xml output is used by front end applications that will
use the relevant options (such as --show-error-list=yes) to select
what to show.

Of course, other choices of when to output what would be possible.
The current state is like it is partially based on history.

For more details of what is output for errors, summary and used suppressions,
you can look at the function VG_(show_all_errors) in file m_errormgr.c

Philippe



On Tue, 2021-06-29 at 16:20 +, Mallove, EthanX A wrote:
> Hello,
>  
> I’ve intentionally created a memory leak in my application by adding a 
> malloc() without a corresponding free(), but it seems to be suppressed by 
> this block of my .supp file:
>  
> {
> libc-2
> Memcheck:Leak
> ...
> obj:*/libc-2.17.so
> }
>  
> When I remove the above from my suppression file, I see the  leak in 
> the output XML.
>  
> But when the libc suppression is active, why isn’t there a “used_suppression” 
> line in the -v output?
>  
> Thank you,
> Ethan
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Segfault / wxWidgets & Boost

[Philippe Waroquiers]

Looks a little bit difficult to tell anything precise based on the info you 
provide.

As general guidelines:
  * If the server segfaults, you should have a core dump to debug and see what 
went wrong.
If core dump is disabled (e.g. check ulimit -a), you might also just
attach with gdb and have gdb stop when the segfault is encountered.
  * And of course, you can try to run your program under valgrind.
Philippe

On Fri, 2021-03-26 at 13:22 -0400, John A wrote:
> Hey y'all,
> 
> I am attempting to solve a unique problem with our inhouse software. The
> main client and server are C/C++. There is also a GUI server using wxWidgets
> 3.1.
> 
> Any guidance to this would be helpful: many or 1 client(s) are begun and
> connect locally or via TCP to the server GUI instance. When a client
> disconnects, the server GUI segfaults.
> 
> We're using Boost 1.74/1.76 (rc2)
> 
> Best regards,
> John
> 
> aronetics.com
> We Speak ITR
> +1-216/307-5760
> 
> 
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Unable to setup valgrind on Android

[Philippe Waroquiers]

It is a very long time I did not compile valgrind for android
(and when I did it years ago, I used an android emulator), so likely
I will not be able to help much.

Did you read and follow the README.android instructions ?
(sounds a little bit unexpected that the below error message seems
to indicate you have a rooted x86-linux smartphone).

So, in particular, check the output of the configure step,
as mentioned in README.android.

Philippe


On Thu, 2021-04-08 at 05:07 +0530, Nikhil Agrawal wrote:
> Hi everyone,
> I am new to the usage of Valgrind. I am getting this error when I executed 
> ./valgrind on my adb shell on rooted smartphone.
> > valgrind: failed to start tool 'memcheck' for platform 'x86-linux': No such 
> > file or directory
> 
> May I know how to resolve it. It will be a big help for my research work.
> -- 
> Nikhil Agrawal,
> MTech(Research) Student,
> Computer Science and Automation Department
> IISc Bangalore-560012
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Can't extend stack during signal delivery : too small or bad protection modes

[Philippe Waroquiers]

If you are not using the last release of valgrind, you might try with the last 
release.

Wondering if the problem also happens with other tools (e.g.  --tool=none).


Otherwise, you could try to debug your application when running under valgrind
when it encounters the problem.
Eg. use arguments --vgdb=full --vgdb-error=1 --vgdb-stop-at=exit,valgrindabexit
(assuming the below is the first error you encounter. If not, you should first 
fix your
code to solve the errors previously reported by valgrind).


You could also compare the valgrind trace between a succesful run and an 
unsuccesful run,
with e.g. the valgrind debug switches -v -v -v -d -d -d --trace-signals=yes
and see if you detect a difference between the 2 runs.
Note that with the above switches, you should see some debug log of the signal 
handling
and of the stack extension mechanism.

Hope this helps

Philippe


On Mon, 2022-03-14 at 11:30 -0400, Narayanan Iyer via Valgrind-users wrote:
> One correction (not sure it matters). I believe the application uses 1.25Mb 
> of stack space at the time of the failure (not .25 as I had originally 
> mentioned).
> 
> Narayanan.
> 
> -Original Message-
> From: Narayanan Iyer [mailto:n...@yottadb.com] 
> Sent: Monday, March 14, 2022 11:27 AM
> To: valgrind-users@lists.sourceforge.net
> Cc: 'Narayanan Iyer' 
> Subject: Can't extend stack during signal delivery : too small or bad 
> protection modes
> 
> Hi,
> 
> While running the automated test suite (which has hundreds of tests) for my 
> application with valgrind, I occasionally see failures like the following in 
> some of the tests.
> 
> ==29753== Can't extend stack to 0x1ffeec7948 during signal delivery for 
> thread 1:
> ==29753==   too small or bad protection modes
> ==29753== 
> ==29753== Process terminating with default action of signal 11 (SIGSEGV): 
> dumping core
> ==29753==  Access not within mapped region at address 0x1FFEEC7948
> ==29753==at 0x4849FD8: strncpy (in 
> /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
> ==29753==by 0x489AE7C: cli_get_sub_quals (sr_unix/cli_parse.c:593)
> ==29753==by 0x489ABC3: parse_arg (sr_unix/cli_parse.c:0)
> ==29753==by 0x489BD6E: parse_triggerfile_cmd (sr_unix/cli_parse.c:1128)
> ==29753==by 0x4BD2377: trigger_parse (sr_unix/trigger_parse.c:1416)
> ==29753==by 0x4B12152: trigger_update_rec (sr_unix/trigger_update.c:1386)
> ==29753==by 0x4B16171: trigger_update_rec_helper 
> (sr_unix/trigger_update.c:2171)
> ==29753==by 0x4B163B9: trigger_update (sr_unix/trigger_update.c:2224)
> ==29753==by 0x4B86385: op_fnztrigger (sr_port/op_fnztrigger.c:248)
> ==29753==by 0x5ABA384: _ydboctoplanhelpers (in 
> YDBOcto/build/src/_ydbocto.so)
> ==29753==by 0x1774F1EF: ???
> ==29753==by 0xAAA9: ???
> ==29753==  If you believe this happened as a result of a stack
> ==29753==  overflow in your program's main thread (unlikely but
> ==29753==  possible), you can try to increase the size of the
> ==29753==  main thread stack using the --main-stacksize= flag.
> ==29753==  The main thread stack size used in this run was 268435456.
> ==29753== Invalid write of size 8
> ==29753==at 0x483A124: _vgnU_freeres (in 
> /usr/libexec/valgrind/vgpreload_core-amd64-linux.so)
> ==29753==  Address 0x1ffeec8808 is on thread 1's stack
> 
> If I rerun just the failing test, it passes fine. Every time the list of 
> tests that fail keeps changing. If I run the test without valgrind, it passes 
> all the time.
> 
> Originally I got a failure with the --main-stacksize set to 16Mb so I bumped 
> it to 256Mb. And I still keep getting this failure at different tests. I also 
> set the ulimit for stacksize to 256Mb just in case and I still see the 
> failures.
> 
> The application is a single-threaded application and I know for sure it does 
> not use anywhere near 256Mb of stack space. The stack trace shown above keeps 
> changing across the many random failures but in all of those stack traces, I 
> believe only around .25Mb of stack space would be used at the most. 
> 
> In this application, a SIGALRM signal would happen every 1 second or so. The 
> application does not set up any alternate stack (i.e. no sigaltstack() call). 
> Not sure if that can be related to the random failure or not.
> 
> This is on a Ubuntu 20.04 system. And my application was compiled with gcc.
> 
> Not sure how to debug this further. Any help in this regard is appreciated.
> 
> Thanks,
> Narayanan.
> 
> 
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] See the address of leaked memory

[Philippe Waroquiers]

You can do that by using the interactive leak search available via valgrind + 
gdb + vgdb.

See e.g. 
https://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands
in particular the "monitor block_list" command.


Philippe


On Thu, 2022-01-27 at 15:06 -0600, Corey Minyard wrote:
> Is there any way in valgrind where you can see the address of leaked
> memory in the leak report, the address the program would have seen?
> That would make a leak much easier for me to debug.
> 
> Thanks,
> 
> -corey
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unable to read core generated by valgrind in gdb / aarch64

[Philippe Waroquiers]

On Sun, 2022-09-04 at 00:14 +0200, Tomas Vondra wrote:
> 
> Clearly, this is not an issue valgrind is meant to detect (like invalid 
> memory access, etc.) but an application issue. I've tried reproducing it 
> without valgrind, but it only ever happens with valgrind - my theory is 
> it's some sort of race condition, and valgrind changes the timing in a 
> way that makes it much more likely to hit. I need to analyze the core to 
> inspect the state more closely, etc.
> 
> Any ideas what I might be doing wrong? Or how do I load the core file?

Rather than have the core dump and analyse it, you might interactively debug
your program under valgrind.
E.g. you might put a breakpoint on the assert or at some interesting points
before the assert.

See 
https://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver
for more info.

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] memcheck is getting SIGKILLed before leak report is output

[Philippe Waroquiers]

On Wed, 2022-08-31 at 17:42 +, Bresalier, Rob (Nokia - US/Murray Hill) 
wrote:
> > When running memcheck on a massive monolith embedded executable
> > (237MB stripped, 1.8GiB unstripped), after I stop the executable under
> > valgrind I see the "HEAP SUMMARY" but then valgrind dies before any leak
> > reports are printed. The parent process sees that the return status of
> > memcheck is that it was SIGKILLed (status returned in waitpid call is '9').
> 
> We found that removing a call to _exit(0) made it so that valgrind is no 
> longer
> SIGKILLED.
> 
> Any ideas why using _exit(0) may get rid of valgrind getting SIGKILLed?
> 
> Previously exit(0) was called, without the leading underscore, but changed it 
> to
> _exit(0) to really make sure no memory was being deallocated. This worked 
> well on a
> different process, so we carried it over to this one, that is why we did it.
> 
> Even with exit(0) (no underscore), in this process there is not much 
> deallocation going
> on in exit handlers, so have lots of doubts that valgrind/memcheck was using 
> too much
> memory and invoking the OOM killer.
> 
> Using strace and dmesg while we had _exit(0) in use didn't show that OOM 
> killer was
> SIGKILLing valgrind.
> 
> I also tried reducing number of callers from 12 to 6 when using _exit(0), 
> still got the
> SIGKILL.
> 
> Also tried using a system that had an additional 4GByte of memory, and also 
> got the
> SIGKILL there.
> 
> So I have many doubts that Valgrind was getting SIGKILLed due to too much 
> memory usage.
> 
> Don't know why removing _exit(0) got rid of the SIGKILL. Was wondering if 
> anyone had any
> ideas?
Normally, if it is the OOM that kills a process, you should find a trace of 
this in the
system logs.

I do not understand what you mean by reducing the nr of callers from 12 to 6.
What are these callers ? Is that some threads of the process you are
running under valgrind ?

And just in case: are you using the last version of Valgrind ?

You might use "strace" on valgrind to see what is going on at the time _exit(0) 
is called.
You might also start valgrind with some debug trace e.g.  -d -d -d -d -v -v -v 
-v

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Valgrind not finding issue with writing/reading past array?

[Philippe Waroquiers]

Valgrind does not check out of bound write in arrays, unless these arrays are 
malloc-ed
(and so valgrind can detect the write out of the limit of the malloc-ed block).

Valgrind used to contain an experimental tool (sgcheck) that did such stack 
array checks,
but it had several limitations and problems, and was removed.

Thanks
Philippe

On Mon, 2022-09-26 at 14:13 -0600, Grant Schoep wrote:
> So I noticed something in my code that looked wrong to me, but valgrind 
> didn't report
> anything. I made a small example of it, and still no findings. I'm sure this 
> code is
> reading/writing past its array. But valgind doesn't say anything. 
> 
> I'm I not understanding something or is this a bug.
> 
> Using:
>  valgrind-3.19.0, gcc 4.8.5, CentOS 7
> 
> I also tried
> valgrind-3.19.0, gcc 7.3.1, Amazon Linux 2
> 
> Here is the code.
> --
> #include 
> #include 
> 
> int main()
> {
>    char retStr[32];
>    
>    // this is bad right? 40 bytes when above was 32?
>    memset(retStr, 'F', 40);
>       
>    // These are "writing"  past the allocated memory?
>    retStr[32] = 'A';
>    retStr[33] = 'B';
>    
>    // These should be fine
>    printf("***  retStr is %c\n", retStr[30]);
>    printf("***  retStr is %c\n", retStr[31]);
>    
>    // These are reading past allocated memory?
>    printf("***  retStr is %c\n", retStr[32]);
>    printf("***  retStr is %c\n", retStr[33]);
> 
>    return 0;
> }
> ---
> 
> 
> Compiled:
> "gcc filename.cxx"
> 
> Ran via this command
> "valgrind ./a.out"
> 
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] callgrind.out file size is zero

[Philippe Waroquiers]

As a wild guess: looks like your application is doing fork and exec.
You might try to add then  --trace-children=yes 
  (and possibly if needed you should use --trace-children-skip=.. if tracing
   all children is too much).

Otherwise, try first with a very simple standalone program
e.g. something like:
   for (int i = 0; i < 1000; i++)
printf ("hello world %d\n", i);

see if that works, and compare the debug trace of the very simple working
case with the more complex non working case.

Philippe


On Tue, 2022-10-18 at 12:54 +, Mahin Pandya wrote:
> Hi All,
>  
> I am tying to use Valgrind to generate code profiling, generated 
> callgrind.out.2199511
> file is of zero size. After enabling the debug log below message is displayed:
>  
> ...
>  SB 2759 (evchecks 30598) [tid 1] 0x415b170 execve 
> /usr/lib/x86_64-linux-gnu/libc-
> 2.31.so+0xe3170
> --1314389:1: syswrap Exec of /devsrc/wineinst/bin/wine64-preloader
> --1314389:1:  gdbsrv remote_finish (reason orderly_finish) 1030 -1
> --1314389:1:  gdbsrv 1314389 (creator 1314389) maybe unlinking
> ...
>  
> Any idea why it does not generate profiling data? I am new to Valgrind, so 
> not sure may
> have missed obvious things. Any pointers/suggestion are welcome.
> Thanking you.
>  
> regards,
> Mahin
>  
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.20.0.RC1 is available for testing

[Philippe Waroquiers]

I have started running valgrind on valgrind (outer/inner setup).
Results should be available tomorrow evening or so ...
For the first few tests, seems ok.

Just one strange thing:
The outer valgrind crashes on the below test (while the native run of this test 
is ok).
(this is on gcc farm gcc186).

Not very clear to me how the ld-linux.so.2 redirection could be ok in native 
mode,
but would not be ok when the same valgrind runs as an outer.
In any case, this is not blocking.

More complete results will follow ...

Philippe

cachegrind/tests/x86/fpu-28-108.outer.log:10:valgrind:  Fatal error at startup: 
a function redirection
cachegrind/tests/x86/fpu-28-108.outer.log:11:valgrind:  which is mandatory for 
this platform-tool combination
cachegrind/tests/x86/fpu-28-108.outer.log:12:valgrind:  cannot be set up.  
Details of the redirection are:
cachegrind/tests/x86/fpu-28-108.outer.log:13:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:14:valgrind:  A must-be-redirected 
function
cachegrind/tests/x86/fpu-28-108.outer.log:15:valgrind:  whose name matches the 
pattern:  strlen
cachegrind/tests/x86/fpu-28-108.outer.log:16:valgrind:  in an object with 
soname matching:   ld-linux.so.2
cachegrind/tests/x86/fpu-28-108.outer.log:17:valgrind:  was not found whilst 
processing
cachegrind/tests/x86/fpu-28-108.outer.log:18:valgrind:  symbols from the object 
with soname: ld-linux.so.2
cachegrind/tests/x86/fpu-28-108.outer.log:19:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:20:valgrind:  Possible fixes: (1, 
short term): install glibc's debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:21:valgrind:  package on this 
machine.  (2, longer term): ask the packagers
cachegrind/tests/x86/fpu-28-108.outer.log:22:valgrind:  for your Linux 
distribution to please in future ship a non-
cachegrind/tests/x86/fpu-28-108.outer.log:23:valgrind:  stripped ld.so (or 
whatever the dynamic linker .so is called)
cachegrind/tests/x86/fpu-28-108.outer.log:24:valgrind:  that exports the 
above-named function using the standard
cachegrind/tests/x86/fpu-28-108.outer.log:25:valgrind:  calling conventions for 
this platform.  The package you need
cachegrind/tests/x86/fpu-28-108.outer.log:26:valgrind:  to install for fix (1) 
is called
cachegrind/tests/x86/fpu-28-108.outer.log:27:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:28:valgrind:On Debian, Ubuntu:
 libc6-dbg
cachegrind/tests/x86/fpu-28-108.outer.log:29:valgrind:On SuSE, openSuSE, 
Fedora, RHEL:   glibc-debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:30:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:31:valgrind:  Note that if you are 
debugging a 32 bit process on a
cachegrind/tests/x86/fpu-28-108.outer.log:32:valgrind:  64 bit system, you will 
need a corresponding 32 bit debuginfo
cachegrind/tests/x86/fpu-28-108.outer.log:33:valgrind:  package (e.g. 
libc6-dbg:i386).
cachegrind/tests/x86/fpu-28-108.outer.log:34:valgrind:  
cachegrind/tests/x86/fpu-28-108.outer.log:35:valgrind:  Cannot continue -- 
exiting now.  Sorry.

On Thu, 2022-10-20 at 01:52 +0200, Mark Wielaard wrote:
> Greetings.
> 
> A first release candidate for 3.20.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.20.0.RC1.tar.bz2
> (md5 = 981b9276536843090700c1268549186e)
> 
> Please give it a try on platforms that are important for you.  If no
> serious issues are reported, the 3.20.0 final release will happen on
> 22 October.
> 
> 
> 
> ___
> Valgrind-developers mailing list
> valgrind-develop...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] [Valgrind-developers] Valgrind-3.20.0.RC1 is available for testing

[Philippe Waroquiers]

On Sun, 2022-10-23 at 00:11 +0200, Mark Wielaard wrote:
> Hi Philippe,
> 
> On Sat, Oct 22, 2022 at 02:58:28PM +0200, Philippe Waroquiers wrote:
> > I have started running valgrind on valgrind (outer/inner setup).
> > Results should be available tomorrow evening or so ...
> > For the first few tests, seems ok.
> > 
> > Just one strange thing:
> > The outer valgrind crashes on the below test (while the native run of this 
> > test is ok).
> > (this is on gcc farm gcc186).
> > 
> > Not very clear to me how the ld-linux.so.2 redirection could be ok in 
> > native mode,
> > but would not be ok when the same valgrind runs as an outer.
> > In any case, this is not blocking.
> > 
> > More complete results will follow ...
> 
> Thanks. I have no theory for the outer valgrind crash. But it doesn't
> seem blocking indeed. I am also still running some tests. Please let
> me know of further results. And do the actual release on Monday
> (unless some regression blocker turns up).
> 
> Cheers,
> 
> Mark
> 

For the crash of the outer valgrind: there is in fact some debug info really
missing on gcc186 (also for the inner) for the 32 bits version.

I have looked at the results of this outer/inner setup and found nothing that
seems problematic.

Note that analysis the outer logs is always painful, as the outer reports as 
"bugs"
the fact the inner uses e.g. some invalid memory because the guest
program run by the inner is designed to test the usage of such invalid memory.

Thanks
Philippe








___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] memcheck is getting SIGKILLed before leak report is output

[Philippe Waroquiers]

On Fri, 2022-08-05 at 15:34 +, Bresalier, Rob (Nokia - US/Murray Hill) 
wrote:
> > If finding memory leaks is the only goal (for instance, if you are 
> > satisfied that
> > memcheck has found all the overrun blocks, uninitialized reads, etc.) then
> > https://github.com/KDE/heaptrack  is the best tool.  
> 
> Thanks! I didn't know about heaptrack. I will look definitely into that. Does 
> heaptrack
> also show  the 'still reachable' types of leaks that memcheck does?
> 
> Any chance that the 'massif' tool would survive the OOM killer? This may be 
> easier for
> me to get going as I already have valgrind built.
> 
> Is there anything that can be done with memcheck to make it consume less 
> memory?
You might be interested in looking at the slides of the FOSDEM presentation
  'Tuning Valgrind for your workload'
https://archive.fosdem.org/2015/schedule/event/valgrind_tuning/attachments/slides/743/export/events/attachments/valgrind_tuning/slides/743/tuning_V_for_your_workload.pdf

There are several things you can do to reduce memcheck memory usage.

Note also that you can also run leak search while your program runs,
either via memcheck client requests or from the shell, using vgdb.

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] memcheck is getting SIGKILLed before leak report is output

[Philippe Waroquiers]

> 
> > Is there anything that can be done with memcheck to make it consume less 
> > memory?
> 
> No.
In fact, Yes :).
Or more precisely, yes, memory can be somewhat reduced :).
See my other mail.

Philippe




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Timer delete

[Philippe Waroquiers]

On Fri, 2022-11-11 at 18:13 +0100, Paul Floyd wrote:
> 
> On 11/11/22 17:47, Domenico Panella wrote:
> > Hi,
> > 
> > I am getting a memory leak in my program about timer_delete function.
> > 
> > According valgrind output,
> > 
> > It seems that the timer_delete function doesn't release the memory.
> > 
> > ==18483== HEAP SUMMARY:
> > ==18483== in use at exit: 272 bytes in 1 blocks
> > ==18483==   total heap usage: 54 allocs, 53 frees, 9,354 bytes allocated
> > ==18483==
> > ==18483== 272 bytes in 1 blocks are possibly lost in loss record 1 of 1
> > ==18483==    at 0x48475FF: calloc (vg_replace_malloc.c:1328)
> > ==18483==    by 0x4012075: _dl_allocate_tls (in /lib64/ld-2.36.so)
> > ==18483==    by 0x491EB49: pthread_create@@GLIBC_2.34 (in 
> > /lib64/libc-2.36.so)
> > ==18483==    by 0x492922D: __timer_start_helper_thread (in 
> > /lib64/libc-2.36.so)
> > ==18483==    by 0x4922E66: __pthread_once_slow (in /lib64/libc-2.36.so)
> > ==18483==    by 0x4928D3A: timer_create@@GLIBC_2.34 (in 
> > /lib64/libc-2.36.so)
> > ==18483==    by 0x401711: main (main.c:224)
> > ==18483==
> > ==18483== LEAK SUMMARY:
> > ==18483==    definitely lost: 0 bytes in 0 blocks
> > ==18483==    indirectly lost: 0 bytes in 0 blocks
> > ==18483==  possibly lost: 272 bytes in 1 blocks
> > ==18483==    still reachable: 0 bytes in 0 blocks
> > ==18483== suppressed: 0 bytes in 0 blocks
> > ==18483==
> > ==18483== For lists of detected and suppressed errors, rerun with: -s
> > ==18483== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
> > 
> > What do i wrong?
> 
> Which OS and CPU?
> 
> Is this repeatable?
> 
> It's possible that this is some memory that ought to be freed by the 
> glibc freeres function.
Possibly --sim-hints=no-nptl-pthread-stackcache might help (if I re-read the 
manual entry
for this sim-hint).

Philippe






___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Timer delete

[Philippe Waroquiers]

On Sat, 2022-11-12 at 12:21 +0100, Paul Floyd wrote:

> Philiipe wrote:
> > Possibly --sim-hints=no-nptl-pthread-stackcache might help (if I
> > re-read the manual entry for this sim-hint).
> 
> 
> As the manpage says, the pthread stackcache stuff is mainly for Helgrind.



> 
> I don't see how this would affect a leak though.

This sim-hint also influences memcheck behaviour related to __thread (i.e. tls) 
variables.
Here is the extract of the doc:
"When using the memcheck tool, disabling the cache ensures the memory used by 
glibc to 
handle __thread variables is directly released when a thread terminates."
(at least that was likely true in 2014, when the above was written).


> 
> I did some tests to check that __libc_freeres is being called (and it is 
> being called).
> 
> So my conclusion is that there are two problems
> 1. Some cleanup code missing in __libc_freeres that is causing this leak 
> (libc problem)
> 2. no-stackcache not working. This is more a Valgrind problem, but it 
> does rely on twiddling libc internals, so it's not too surprising that 
> it breaks. That needs work on the Valgrind side.
Yes, the cache disabling is quite hacky, as mentionnd in the doc:
"Valgrind disables the cache using some internal
 knowledge of the glibc stack cache implementation and by
 examining the debug information of the pthread
 library. This technique is thus somewhat fragile and might
 not work for all glibc versions. This has been successfully
 tested with various glibc versions (e.g. 2.11, 2.16, 2.18)
 on various platforms."



As you indicate, it looks broken on the more recent glibc version you tried.

Philippe



___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Recursive `who-points-at`

[Philippe Waroquiers]

On Fri, 2023-02-24 at 10:42 -0700, User 10482 wrote:
> Dear All,
> 
> I am looking to fix dangling pointer issue and was pleasantly surprised to 
> find the
> `who-points-at` functionality in valgrind which tells the stack variable 
> names (assuming
> --read-var-info=yes) and any addresses on heap with holding the searched 
> address.
> [link](https://valgrind.org/docs/manual/mc-manual.html#mc-manual.monitor-commands)
> 
> The tool is just splendid but I wish there was some way to do it recursively 
> on the heap
> addresses (i.e who-points-at on the output of previous who-points-at) until 
> we get the
> stack variable names holding the dangling pointers; something like how 
> core-analyzer's
> `ref` command does. [link](
> https://core-analyzer.sourceforge.net/index_files/Page600.html).

Yes, a recursive who-points-at would be a nice thing to have.
I have added this on my list of things to do (one day, whenever I have time :().


> 
> On a side note, is there a way to know which variable/type a heap address 
> points to?
> That will be helpful too.
The only information valgrind has about a (live) heap block is the stack trace 
that
allocated it.
Valgrind does not know the type of the object for which this memory was 
allocated.
Unclear to me how that can be implemented (at least without support of the 
compiler).

> 
> Thanks and have a good day!
> 
> best,
> Abhi
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Regarding use of Lackey to trace midway execution of a program

[Philippe Waroquiers]

If you are envisaging to modify valgrind, you could take some inspiration from 
the way
callgrind can dynamically activate/de-activate tracing.

See callgrind manual command line options and client requests for more details

Philippe


On Wed, 2023-02-08 at 17:47 +1100, Eliot Moss wrote:
> On 2/8/2023 4:10 PM, SAI GOVARDHAN M C PES1UG19EC255PESU ECE Student wrote:
> > Hi,
> > 
> > We are students working on memory access analysis, using the Lackey tool in 
> > Valgrind.
> > Our memory trace results in a large log file, and we need the trace from 
> > discrete points of 
> > execution (between 40-60%).
> > Instead of logging completely, and splitting manually, is there a way we 
> > can modify the Lackey 
> > command to pick from a desired point in the execution?
> > 
> > For reference, the command we use is
> > $ valgrind --tool=lackey --trace-mem=yes --log-file=/path_to_log ./program
> > 
> > We need to modify this to command to trace from 40-60% of the program
> 
> If you know the approximate number of memory accesses, you could do something
> as simple as:
> 
> valgrind ... | tail +n XXX | head -n YYY
> 
> to start after XXX lines of output and stop after producing YYY lines.  You
> could do something more sophisticated using, say, gawk, to trigger on a
> particular address being accessed, e.g., as an instruction fetch.
> 
> This will all slow things down a bit, but might accomplish your goals.
> 
> I'm not claiming there isn't some sophisticated way to tell valgrind when
> to start tracing, either.  Also, nobody is stopping you from customizing
> the tool yourself :-) ... a mere exercise in programming, no?
> 
> Best wishes - EM
> 
> 
> ___
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users




___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users