valgrind-users — General discussion list for Valgrind users

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

[Michael W. <mic...@gm...>]

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

Re: [Valgrind-users] Program crashes with valgrind

[James R. <jam...@gm...>]

On Wed, May 20, 2020 at 5:04 PM Tom Hughes <to...@co...> wrote:

> On 20/05/2020 17:01, James Read wrote:
> >
> >
> > On Wed, May 20, 2020 at 2:31 PM Tom Hughes <to...@co...
> > <mailto:to...@co...>> wrote:
> >
> >     On 20/05/2020 14:23, James Read wrote:
> >
> >      > I'm trying to use valgrind to track down a memory leak in my web
> >      > crawling application. The problem is my application runs just fine
> >      > without valgrind but when I run it under valgrind the program
> >     crashes
> >      > before it has a chance to crawl any websites. Any ideas why this
> >      > behaviour could happen?
> >
> >     On the basis of the information supplied I'd say it was
> >     caused by excess neutron flux in the discombobulator.
> >
> >     Seriously, if you want anybody to actually try and answer
> >     your question then you'll have to provide some actual
> >     information like, what exactly it says...
> >
> >
> > A typical run of my program gives the following output:
> >
> > Redis server: :0
> > Mongo server: 127.0.0.1:27017 <http://127.0.0.1:27017>
> > URL file: links/links-2
> > Max connections: 1000
> > Selected JUST CRAWLER MODE
> >
> > Parsed sites: 132 ^C
> > Crawler thread exiting.
> > Exiting.
> >
> > But with valgrind ./crawler -c I get the following output:
> >
> > ==415433== Memcheck, a memory error detector
> > ==415433== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et
> al.
> > ==415433== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright
> > info
> > ==415433== Command: ./crawler -c
> > ==415433==
> > Redis server: :0
> > Mongo server: 127.0.0.1:27017 <http://127.0.0.1:27017>
> > URL file: links/links-2
> > Max connections: 1000
> > Selected JUST CRAWLER MODE
> > ==415433== Warning: ignored attempt to set SIGKILL handler in
> sigaction();
> > ==415433==          the SIGKILL signal is uncatchable
> > setrlimit() failed
> > ==415433==
> > ==415433== HEAP SUMMARY:
> > ==415433==     in use at exit: 37,773 bytes in 92 blocks
> > ==415433==   total heap usage: 6,112 allocs, 6,020 frees, 460,106 bytes
> > allocated
> > ==415433==
> > ==415433== LEAK SUMMARY:
> > ==415433==    definitely lost: 0 bytes in 0 blocks
> > ==415433==    indirectly lost: 0 bytes in 0 blocks
> > ==415433==      possibly lost: 0 bytes in 0 blocks
> > ==415433==    still reachable: 37,773 bytes in 92 blocks
> > ==415433==         suppressed: 0 bytes in 0 blocks
> > ==415433== Rerun with --leak-check=full to see details of leaked memory
> > ==415433==
> > ==415433== For lists of detected and suppressed errors, rerun with: -s
> > ==415433== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> >
> > As you can see no Parsed sites: value message just crashes and burns.
>
> I don't see any crash there, just a program that has chosen to exit.
>
> Does your code exit when setrlimit fails? What sort of limit is it
> trying to set? My guess is that it's trying to play with RLIMIT_NOFILE
> in a way that would encroach on valgrind's reserved descriptors so
> valgrind is refusing the request and your program is then chooding
> to exist rather than continue.
>
>
Good guess. Will comment out that code and try to run without.

James Read


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

Re: [Valgrind-users] Program crashes with valgrind

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

On 20/05/2020 17:01, James Read wrote:
> 
> 
> On Wed, May 20, 2020 at 2:31 PM Tom Hughes <to...@co... 
> <mailto:to...@co...>> wrote:
> 
>     On 20/05/2020 14:23, James Read wrote:
> 
>      > I'm trying to use valgrind to track down a memory leak in my web
>      > crawling application. The problem is my application runs just fine
>      > without valgrind but when I run it under valgrind the program
>     crashes
>      > before it has a chance to crawl any websites. Any ideas why this
>      > behaviour could happen?
> 
>     On the basis of the information supplied I'd say it was
>     caused by excess neutron flux in the discombobulator.
> 
>     Seriously, if you want anybody to actually try and answer
>     your question then you'll have to provide some actual
>     information like, what exactly it says...
> 
> 
> A typical run of my program gives the following output:
> 
> Redis server: :0
> Mongo server: 127.0.0.1:27017 <http://127.0.0.1:27017>
> URL file: links/links-2
> Max connections: 1000
> Selected JUST CRAWLER MODE
> 
> Parsed sites: 132 ^C
> Crawler thread exiting.
> Exiting.
> 
> But with valgrind ./crawler -c I get the following output:
> 
> ==415433== Memcheck, a memory error detector
> ==415433== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
> ==415433== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright 
> info
> ==415433== Command: ./crawler -c
> ==415433==
> Redis server: :0
> Mongo server: 127.0.0.1:27017 <http://127.0.0.1:27017>
> URL file: links/links-2
> Max connections: 1000
> Selected JUST CRAWLER MODE
> ==415433== Warning: ignored attempt to set SIGKILL handler in sigaction();
> ==415433==          the SIGKILL signal is uncatchable
> setrlimit() failed
> ==415433==
> ==415433== HEAP SUMMARY:
> ==415433==     in use at exit: 37,773 bytes in 92 blocks
> ==415433==   total heap usage: 6,112 allocs, 6,020 frees, 460,106 bytes 
> allocated
> ==415433==
> ==415433== LEAK SUMMARY:
> ==415433==    definitely lost: 0 bytes in 0 blocks
> ==415433==    indirectly lost: 0 bytes in 0 blocks
> ==415433==      possibly lost: 0 bytes in 0 blocks
> ==415433==    still reachable: 37,773 bytes in 92 blocks
> ==415433==         suppressed: 0 bytes in 0 blocks
> ==415433== Rerun with --leak-check=full to see details of leaked memory
> ==415433==
> ==415433== For lists of detected and suppressed errors, rerun with: -s
> ==415433== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> 
> As you can see no Parsed sites: value message just crashes and burns.

I don't see any crash there, just a program that has chosen to exit.

Does your code exit when setrlimit fails? What sort of limit is it 
trying to set? My guess is that it's trying to play with RLIMIT_NOFILE
in a way that would encroach on valgrind's reserved descriptors so
valgrind is refusing the request and your program is then chooding
to exist rather than continue.

Tom

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

Re: [Valgrind-users] Program crashes with valgrind

[James R. <jam...@gm...>]

On Wed, May 20, 2020 at 2:31 PM Tom Hughes <to...@co...> wrote:

> On 20/05/2020 14:23, James Read wrote:
>
> > I'm trying to use valgrind to track down a memory leak in my web
> > crawling application. The problem is my application runs just fine
> > without valgrind but when I run it under valgrind the program crashes
> > before it has a chance to crawl any websites. Any ideas why this
> > behaviour could happen?
>
> On the basis of the information supplied I'd say it was
> caused by excess neutron flux in the discombobulator.
>
> Seriously, if you want anybody to actually try and answer
> your question then you'll have to provide some actual
> information like, what exactly it says...
>
>
A typical run of my program gives the following output:

Redis server: :0
Mongo server: 127.0.0.1:27017
URL file: links/links-2
Max connections: 1000
Selected JUST CRAWLER MODE

Parsed sites: 132 ^C
Crawler thread exiting.
Exiting.

But with valgrind ./crawler -c I get the following output:

==415433== Memcheck, a memory error detector
==415433== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==415433== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright
info
==415433== Command: ./crawler -c
==415433==
Redis server: :0
Mongo server: 127.0.0.1:27017
URL file: links/links-2
Max connections: 1000
Selected JUST CRAWLER MODE
==415433== Warning: ignored attempt to set SIGKILL handler in sigaction();
==415433==          the SIGKILL signal is uncatchable
setrlimit() failed
==415433==
==415433== HEAP SUMMARY:
==415433==     in use at exit: 37,773 bytes in 92 blocks
==415433==   total heap usage: 6,112 allocs, 6,020 frees, 460,106 bytes
allocated
==415433==
==415433== LEAK SUMMARY:
==415433==    definitely lost: 0 bytes in 0 blocks
==415433==    indirectly lost: 0 bytes in 0 blocks
==415433==      possibly lost: 0 bytes in 0 blocks
==415433==    still reachable: 37,773 bytes in 92 blocks
==415433==         suppressed: 0 bytes in 0 blocks
==415433== Rerun with --leak-check=full to see details of leaked memory
==415433==
==415433== For lists of detected and suppressed errors, rerun with: -s
==415433== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

As you can see no Parsed sites: value message just crashes and burns.

James Read


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

Re: [Valgrind-users] Program crashes with valgrind

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

On 20/05/2020 14:23, James Read wrote:

> I'm trying to use valgrind to track down a memory leak in my web 
> crawling application. The problem is my application runs just fine 
> without valgrind but when I run it under valgrind the program crashes 
> before it has a chance to crawl any websites. Any ideas why this 
> behaviour could happen?

On the basis of the information supplied I'd say it was
caused by excess neutron flux in the discombobulator.

Seriously, if you want anybody to actually try and answer
your question then you'll have to provide some actual
information like, what exactly it says...

Tom

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

[Valgrind-users] Program crashes with valgrind

[James R. <jam...@gm...>]

Hi,

I'm trying to use valgrind to track down a memory leak in my web crawling
application. The problem is my application runs just fine without valgrind
but when I run it under valgrind the program crashes before it has a chance
to crawl any websites. Any ideas why this behaviour could happen?

thanks
James Read

Re: [Valgrind-users] Valgrind-3.16.0.RC2 is available for testing

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

Hi,

On Tue, 2020-05-19 at 14:32 +0200, Julian Seward wrote:
> A first release candidate for 3.16.0 is available at
> https://sourceware.org/pub/valgrind/valgrind-3.16.0.RC2.tar.bz2
> (md5 = 21ac87434ed32bcfe5ea86a0978440ba)
> 
> Please give it a try on platforms that are important for you.  If no serious
> issues are reported, the 3.16.0 final release will happen on 25 May, that is,
> next Monday.

Looks good! In case people want binaries to test,
I made Fedora Rawhide test packages:

(aarch64, armv7hl, i686, ppc64le, s390x, x86_64)
https://bodhi.fedoraproject.org/updates/FEDORA-2020-31868cd970

And packages for stable Fedora and CentOS releases:
https://copr.fedorainfracloud.org/coprs/mjw/valgrind-3.16.0/
(Epel for CentOS 7, aarch64 and x86_64
 Epel for CentOS 8, aarch64 and x86_64
 Fedora 30, aarch64, i386 and x86_64
 Fedora 31, aarch64 and x86_64
 Fedora 32, aarch64 and x86_64)

Note to packagers who run make check and/or make regtest (which is
optional, but recommended to check the sanity of the binaries), this
now validates the docbookx xml documentation, so you'll need to have
xmllint (from libxml2) and the docbook-dtds catalog installed.

Cheers,

Mark

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

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

Greetings.

A first release candidate for 3.16.0 is available at
https://sourceware.org/pub/valgrind/valgrind-3.16.0.RC2.tar.bz2
(md5 = 21ac87434ed32bcfe5ea86a0978440ba)

Please give it a try on platforms that are important for you.  If no serious
issues are reported, the 3.16.0 final release will happen on 25 May, that is,
next Monday.

J

Re: [Valgrind-users] New user and first problem

[Patrick B. <Pat...@le...>]

Le 18/05/2020 à 19:48, Julian Seward a écrit :
>
>> Program received signal SIGILL: Illegal instruction.
>>
>> Backtrace for this error:
>> vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5
>> 0x25 0xA8 0x18 0x0
>> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
>> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
>> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
>> ==377969== valgrind: Unrecognised instruction at address 0xabf9581.
>> ==377969==    at 0xABF9581: opal_pointer_array_construct (in
>> /opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
>
> It sounds like there's an instruction in libopen-pal.so.40.10.3 that
> Valgrind doesn't like.  What CPU does the machine have?
>
> J

Hi Julian,*This machine is a fat node with 4  Intel Xeon Gold 6148 (20
cores each):

vendor_id     : GenuineIntel
cpu family    : 6
model         : 85
model name    : Intel(R) Xeon(R) Gold 6148 CPU @ 2.40GHz
stepping      : 4
microcode     : 0x2000064
cpu MHz       : 2400.000
cache size    : 28160 KB
physical id   : 3
siblings      : 40
core id       : 26
cpu cores     : 20
apicid        : 245
initial apicid : 245
fpu           : yes
fpu_exception : yes
cpuid level   : 22
wp            : yes
flags         : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall
nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good
nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64
monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid dca
sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c
rdrand lahf_lm abm 3dnowprefetch epb cat_l3 cdp_l3 invpcid_single
intel_ppin intel_pt ssbd mba ibrs ibpb stibp tpr_shadow vnmi
flexpriority ept vpid fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms
invpcid rtm cqm mpx rdt_a avx512f avx512dq rdseed adx smap clflushopt
clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 cqm_llc
cqm_occup_llc cqm_mbm_total cqm_mbm_local dtherm ida arat pln pts pku
ospke md_clear spec_ctrl intel_stibp flush_l1d
bogomips      : 4806.68
clflush size  : 64
cache_alignment : 64
address sizes : 46 bits physical, 48 bits virtual

Re: [Valgrind-users] New user and first problem

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

On 18/05/2020 18:48, Julian Seward wrote:
> 
>> Program received signal SIGILL: Illegal instruction.
>>
>> Backtrace for this error:
>> vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5
>> 0x25 0xA8 0x18 0x0
>> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
>> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
>> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
>> ==377969== valgrind: Unrecognised instruction at address 0xabf9581.
>> ==377969==    at 0xABF9581: opal_pointer_array_construct (in
>> /opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
> 
> It sounds like there's an instruction in libopen-pal.so.40.10.3 that
> Valgrind doesn't like.  What CPU does the machine have?

0x62 is an EVEX prefix from the AVX512 extensions, so isn't
supported yet.

Tom

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

Re: [Valgrind-users] New user and first problem

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

> Program received signal SIGILL: Illegal instruction.
> 
> Backtrace for this error:
> vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5
> 0x25 0xA8 0x18 0x0
> vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
> vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
> vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
> ==377969== valgrind: Unrecognised instruction at address 0xabf9581.
> ==377969==    at 0xABF9581: opal_pointer_array_construct (in
> /opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)

It sounds like there's an instruction in libopen-pal.so.40.10.3 that
Valgrind doesn't like.  What CPU does the machine have?

J

[Valgrind-users] New user and first problem

[Patrick B. <Pat...@le...>]

Hi,


I'm new to valgrind. My goal is to investigate a possible memory problem
in a large parallel MPI+OpenMP code.

I've cloned Valgrind from git and built it with GCC7.3 and fortran 3.1
for mpicc (my application is built with the same environment). I'm using
these 2 options:

--enable-only64bit --with-mpicc=$(which mpicc)

"mpirun -np 8 my_application" is working on my fat node (just to have
few processes for the test, I use nearly 60GB of RAM over more than
1TB). It fails after some tenth of iterations.

"mpirun -np 8 valgrind /bin/hostname" works too. So Valgrind seams
working with MPI 3.1 compiled with GCC7.3.

But "mpirun -np 8 valgrind ./my_application" immediately fails with:

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:
vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFD 0x8 0x6F 0x5
0x25 0xA8 0x18 0x0
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=0 PFX.F2=0 PFX.F3=0
==377969== valgrind: Unrecognised instruction at address 0xabf9581.
==377969==    at 0xABF9581: opal_pointer_array_construct (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
==377969==    by 0xAC1BA78: mca_base_var_init (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
==377969==    by 0xABFDE39: opal_init_util (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libopen-pal.so.40.10.3)
==377969==    by 0x911AD60: ompi_mpi_init (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libmpi.so.40.10.3)
==377969==    by 0x914BB34: PMPI_Init_thread (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libmpi.so.40.10.3)
==377969==    by 0x8E97C1F: MPI_INIT_THREAD (in
/opt/openmpi-GCC73/v3.1.x-20181010/lib/libmpi_mpifh.so.40.11.2)
==377969==    by 0x543066: __mpi_m_MOD_init_mpi (mpi_m.f90:140)
==377969==    by 0x411447: __yales2_m_MOD_init_yales2_env (yales2_m.f90:511)
==377969==    by 0x411595: __yales2_m_MOD_run_yales2 (yales2_m.f90:378)
==377969==    by 0x40B9E0: MAIN__ (3D_cylinder.f90:20)
==377969==    by 0x40B9E0: main (3D_cylinder.f90:8)
==377969== Your program just tried to execute an instruction that Valgrind
==377969== did not recognise.  There are two possible reasons for this.
==377969== 1. Your program has a bug and erroneously jumped to a non-code
==377969==    location.  If you are running Memcheck and you just saw a
==377969==    warning about a bad jump, it's probably your program's fault.
==377969== 2. The instruction is legitimate but Valgrind doesn't handle it,
==377969==    i.e. it's Valgrind's fault.  If you think this is the case or
==377969==    you are not sure, please let us know and we'll try to fix it.
==377969== Either way, Valgrind will now raise a SIGILL signal which will
==377969== probably kill your program.

May be I've missed something ?

I'm using master branch. The branch VALGRIND_3_16_BRANCH that I have
tested do not build:

make: ***  Aucune règle pour fabriquer la cible « exp-sgcheck.supp »,
nécessaire pour « default.supp ». Arrêt.

Thanks for your help

Patrick

Re: [Valgrind-users] HELP/Hint: valgrind error message

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

> Below is the error coming when running valgrind , Do not know how to tackle it

> valgrind --tool=memcheck  ./lte_tr069
> ==6660==
> ==6660== Warning: Can't execute setuid/setgid/setcap executable: ./lte_tr069
> ==6660== Possible workaround: remove --trace-children=yes, if in effect
> ==6660==
> valgrind: ./lte_tr069: Permission denied

READ THE Warning MESSAGE.  It says *EXACTLY* what the problem is.
./lte_tr069 has one of the attributes setuid, or setgid, or setcap.
If you're clever enough to set such an attribute then you should
be clever enough to deal with the complaint from valgrind/memcheck.

Re: [Valgrind-users] HELP/Hint: valgrind error message

[Kunal C. <atk...@gm...>]

Hi  Team,

1. I have created a simple  program ./a.out and make a check
if(RUNNING_ON_VALGRIND) but still same error is coming.

2. I am trying to run ./a.out on arm board as it is compile for it also
valgrind is running there only

Thanks
Kunal


On Fri, May 15, 2020 at 2:51 PM Paul FLOYD <pj...@wa...> wrote:

>
>
> > Message du 15/05/20 10:22
> > De : "Kunal Chauhan"
>
>
> > ==6660== Warning: Can't execute setuid/setgid/setcap executable:
> ./lte_tr069
> > ==6660== Possible workaround: remove --trace-children=yes, if in effect
> > ==6660==
> > valgrind: ./lte_tr069: Permission denied
>
>
> Hi
>
> The problem is that your application (or something that your application
> is executing) is trying to switch user, group or capabilities. This is
> likely to interfere with the workings of Valgrind. As an
> example of this, Valgrind often needs to open new log files. This may fail
> if Valgrind has switched user/group/caps.
>
> This is more likely to happen if you are running Valgrind on a wrapper
> script and using the --trace-children=yes. For instance you might be on a
> system where utilities like 'basename' and
> 'dirname' are security hardened. If they are used in your wrapper this
> could result in the problem you are seeing.
>
> Alternatively, if you are not using a wrapper, then the best workaround is
> to have some special Valgrind handling in your executable. See
> http://valgrind.org/docs/manual/manual-core-
> adv.html#manual-core-adv.clientreq
> <http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.clientreq>
>
> So you could write some code like
>
> if (!RUNNING_ON_VALGRIND)
> {
> // your setcap calls
> }
>
> A+
> Paul
>
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>


-- 
*Thanks with Regards!*

*Kunal Chauhan*
*Mob:09813614826*
*Mob:08860397903*

*E-mail:atk...@gm... <E-mail%3Aa...@gm...>*

Re: [Valgrind-users] HELP/Hint: valgrind error message

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

 
> Message du 15/05/20 10:22
> De : "Kunal Chauhan" 


> ==6660== Warning: Can't execute setuid/setgid/setcap executable: ./lte_tr069
> ==6660== Possible workaround: remove --trace-children=yes, if in effect
> ==6660==
> valgrind: ./lte_tr069: Permission denied


Hi

The problem is that your application (or something that your application is executing) is trying to switch user, group or capabilities. This is likely to interfere with the workings of Valgrind. As an 
example of this, Valgrind often needs to open new log files. This may fail if Valgrind has switched user/group/caps. 

This is more likely to happen if you are running Valgrind on a wrapper script and using the --trace-children=yes. For instance you might be on a system where utilities like 'basename' and 
'dirname' are security hardened. If they are used in your wrapper this could result in the problem you are seeing.

Alternatively, if you are not using a wrapper, then the best workaround is to have some special Valgrind handling in your executable. See http://valgrind.org/docs/manual/manual-core-
adv.html#manual-core-adv.clientreq

So you could write some code like

if (!RUNNING_ON_VALGRIND)
{
// your setcap calls
}

A+
Paul

[Valgrind-users] HELP/Hint: valgrind error message

[Kunal C. <atk...@gm...>]

Hi Team,

Below is the error coming when running valgrind , Do not know how to tackle
it
.............................

valgrind --tool=memcheck  ./lte_tr069

==6660==

==6660== Warning: Can't execute setuid/setgid/setcap executable: ./lte_tr069

==6660== Possible workaround: remove --trace-children=yes, if in effect

==6660==

valgrind: ./lte_tr069: Permission denied

-- 
*Thanks with Regards!*

*Kunal Chauhan*
*Mob:09813614826*
*Mob:08860397903*

*E-mail:atk...@gm... <E-mail%3Aa...@gm...>*

Re: [Valgrind-users] Spurious errors during an abrupt program termination

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

On 5/14/20, Dalon Work wrote:

> I have an application with two threads on linux which I was testing
> under valgrind. We have a strange memory behavior that is leading to
> an internal assert terminating the application, hence the
> investigation. After running the application, I have many, many
> errors, (invalid reads and writes), which all follow a similar
> pattern:
> 
> Invalid read/write of size 4:
>      at thread1_func()
>      at thread1_func1()
>      ...

The rule for dealing with output from memcheck is:
    Fix the first complaint.  Do not ignore it; FIX IT.
Many times the command-line option --track-origins=yes provides helpful clues.

> Address 0x##### is ##### bytes inside a block of size #### free'd
>      free()
>      myAllocator::~myAllocator()
>      __run_exit_handlers
>      exit
>      terminate_handler_sp
>      thread2_func()
>      thread2_func1()
>      ...
> 
> The call stack from the free() stack is obviously from the second
> thread (NOT the one that started the error, oddly enough), while the
> invalid read is from the first thread.

Based on this evidence, the most likely scenario is thread2 decided to
(or was forced to) terminate, and started running exit handlers
for the whole process.  Meanwhile, thread1 continues running (thread1
has received no news that it should stop) and references blocks that
have been free()d by the termination handlers invoked by thread2.
So the termination handler should first rendezvous with all threads
before beginning to shutdown the process.

[Valgrind-users] Spurious errors during an abrupt program termination

[Dalon W. <dw...@gm...>]

I have a quick question that hopefully those more knowledgeable in
linux can help me with.

I have an application with two threads on linux which I was testing
under valgrind. We have a strange memory behavior that is leading to
an internal assert terminating the application, hence the
investigation. After running the application, I have many, many
errors, (invalid reads and writes), which all follow a similar
pattern:

Invalid read/write of size 4:
    at thread1_func()
    at thread1_func1()
    ...
Address 0x##### is ##### bytes inside a block of size #### free'd
    free()
    myAllocator::~myAllocator()
    __run_exit_handlers
    exit
    terminate_handler_sp
    thread2_func()
    thread2_func1()
    ...

The call stack from the free() stack is obviously from the second
thread (NOT the one that started the error, oddly enough), while the
invalid read is from the first thread.

Anyway, the way I'm interpreting this is that the first thread starts
the abort process. The second thread catches the signal and starts
destroying the static objects, which frees memory, and somehow the
first thread keeps going and causes all sorts of spurious memory
errors?

I guess another possibility is that at some point the second thread
really did tear everything down at some point and the first thread
really did just charge ahead not knowing about it. My linux-fu is not
at expert-level yet (Just a yellow-belt, really), so I'd appreciate
any thoughts on what could be going on and how to continue with the
debugging process.

Dalon

Re: [Valgrind-users] Load a shared library into client address space

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

> Is there some way that I can load a shared library into the client
> address space?  I am trying to do some dynamic analysis on shared
> libraries, and I would like to have the dynamic loader load a
> specified shared library into the client to run my analysis.

Have main() of the valgrind app (memcheck, drd, etc.) set the environment
variable LD_PRELOAD before invoking the PT_INTERP of the app-under-test.
This is the same as invoking the app-under-test with the bash-shell command line:
     LD_PRELOAD=/path/to/the/shared/library  app-under-test  args...
except that valgrind will supervise the execution.

In many cases setting LD_PRELOAD "commutes with" (can be set before) invoking valgrind:
     LD_PRELOAD=/path/to/the/shared/library  valgrind  app-under-test  args...
as long as the shared library does not interfere with valgrind or
any shared library that already is used by valgrind (typically, libc).

There may be complications if the app-under-test invokes child process(es).
The LD_PRELOAD will propagate to the child(ren).

[Valgrind-users] Load a shared library into client address space

[Derrick M. <der...@gm...>]

Hi,

Is there some way that I can load a shared library into the client
address space?  I am trying to do some dynamic analysis on shared
libraries, and I would like to have the dynamic loader load a
specified shared library into the client to run my analysis.
Alternatively, I could write a small program that just calls dlopen(),
but then I would need a way to track the dlopen() call.  Any ideas?
Thanks.

-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

Re: [Valgrind-users] opcode question

[Mark R. <ma...@cs...>]

Also Iop_CmpNEZ128x1

-----Original Message-----
From: Mark Roberts [mailto:ma...@cs...]
Sent: Monday, April 13, 2020 5:33 PM
To: val...@li...
Subject: opcode question

In memcheck/mc_translate.c I notice that:
Iop_RndF128
Iop_I64UtoF32
are case statement labels in both expr2vbits_Unop and expr2vbits_Binop.

Is that intentional? And if so, why?

Thank you,
Mark Roberts

[Valgrind-users] opcode question

[Mark R. <ma...@cs...>]

In memcheck/mc_translate.c I notice that:
Iop_RndF128
Iop_I64UtoF32
are case statement labels in both expr2vbits_Unop and expr2vbits_Binop.

Is that intentional? And if so, why?

Thank you,
Mark Roberts

[Valgrind-users] Cachegrind not writing on exit

[Han-Wen N. <ha...@gm...>]

Hi there,

I'm trying to use cachegrind on LilyPond. For some reason, cachegrind
starts, but never finalizes its output: there is no summary, and there
is output file.

Where can I start diagnosing this?  I have no trouble running valgrind
on LilyPond.

thanks!


$ valgrind --tool=cachegrind lilypond --help
=1163922== Cachegrind, a cache and branch-prediction profiler
==1163922== Copyright (C) 2002-2017, and GNU GPL'd, by Nicholas
Nethercote et al.
==1163922== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info
==1163922== Command: /home/hanwen/bin//lilypond --help
==1163922==
--1163922-- warning: L3 cache found, using its data for the LL simulation.
Usage: lilypond [OPTION]... FILE...
..

You found a bug? Please read https://lilypond.org/bug-reports.html

$


-- 
Han-Wen Nienhuys - ha...@gm... - http://www.xs4all.nl/~hanwen

[Valgrind-users] Translated instruction doesn't get executed

[Derrick M. <der...@gm...>]

Hi,

I am writing a new tool that involves calling a tool function at every
instruction.  However, there appears to be one instruction that never
gets executed, and I cannot figure out why.  The (partial)
instrumented IRSB is as follows:

------ IMark(0x112E42, 5, 0) ------
   DIRTY 1:I1 RdFX-gst(0,928) ::: record_current_state{0x58001ce0}(0x112E42:I64)
   t68 = Sub64(t2,0x8:I64)
   PUT(48) = t68
   STle(t68) = 0x112E47:I64
   t70 = Sub64(t68,0x80:I64)
   ====== AbiHint(t70, 128, 0x124A10:I64) ======
   ------ IMark(0x124A10, 1, 0) ------
   DIRTY 1:I1 RdFX-gst(0,928) ::: record_current_state{0x58001ce0}(0x124A10:I64)
   t79 = Sub64(t68,0x8:I64)
   PUT(48) = t79
   STle(t79) = t22
   PUT(184) = 0x124A11:I64
   ------ IMark(0x124A11, 3, 0) ------
   DIRTY 1:I1 RdFX-gst(0,928) ::: record_current_state{0x58001ce0}(0x124A11:I64)
   PUT(56) = t79
   PUT(184) = 0x124A14:I64
   ------ IMark(0x124A14, 4, 0) ------
   DIRTY 1:I1 RdFX-gst(0,928) ::: record_current_state{0x58001ce0}(0x124A14:I64)
   t82 = Add64(t79,0xFFFFFFFFFFFFFFF8:I64)
   STle(t82) = t64
   PUT(184) = 0x124A18:I64

The instruction that doesn't get executed is 0x124A10.  There are two
reasons I say the instruction is not executed.  First, I am printing
out the guest IP in record_current_state() and 0x124A10 is never
printed.  Second, I get a segfault at instruction 0x124A14, which
dereferences a stack location.  I have checked read/write permissions
of the location referenced in the STle IRStmt, and sure enough the
location is not valid for the guest.  This leads me to believe that
the t79=Sub64(t68, 0x8) isn't happening, because that should update
the memory permissions.

Interestingly, instruction 0x112E42 seemingly gets executed twice,
according to my instrumentation output:

==273360== Recording state for 0x112e42 (quote_name_buf)
==273360== Recording state for 0x112e42 (quote_name_buf)
==273360== Recording state for 0x124a11 (get_quoting_style)

-- 
Derrick McKee
Phone: (703) 957-9362
Email: der...@gm...

Re: [Valgrind-users] PowerPC undefined symbol _restgpr_30_x

[MP <mx...@gm...>]

I found that the restgpr symbols were being included because I was
configuring crosstool-NG with CT_CC_GCC_ENABLE_TARGET_OPTSPACE, which
compiles gcc libs with "-Os". I rebuilt the toolchain without this
option and Valgrind no longer complains about missing symbols or
unrecognized instructions. The size of the complete board image barely
changed, so I think I can just leave the toolchain like this and
successfully use Valgrind.



On Sun, Mar 22, 2020 at 11:35 PM Alan Corey <ala...@gm...> wrote:
>
> Those happen, don't take it personally.  They used to be real common
> in ARM.  Sounds like you hit a code that's not covered.   Not that I'm
> one that can add it.
>
> See the "==466== Your program just tried to execute an instruction that Valgrind
> ==466== did not recognise." section of the error message.  OTOH
> somewhere it looks like it jumped to a null.