valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] porition names length

[Marco C. <mar...@op...>]

Thank you very much Florian,
no problem with 3.11.0 version of Valgrind.
It helps me a lot in fixing a wrong memory access.

Bests,
Marco

________________________________________
Da: Florian Krohm <fl...@ei...>
Inviato: mercoledì 28 ottobre 2015 13.03
A: Marco Cisternino; val...@li...
Oggetto: Re: [Valgrind-users] porition names length

On 28.10.2015 12:04, Marco Cisternino wrote:
> Good morning,
>
> I'm new on the list and I would like to ask you something about the Valgrind output.
>
> My c++ code uses a lot of templates so the name of the functions are usually huge.
>
> When Valgrind finds an error, it prints the type of error and where it happens "at 0x........: name of the function".
>
> If the name of the function is too long Valgrind cuts it.
>
> Is there a way to change the maximal length of the function name?

What you describe should have been fixed in the latest
valgrind release 3.11.0
If you are using an older version, function names will be cut
and there is no way to change that with a command line parameter.
If, however, you are using 3.11.0 then this is a bug we want to know
more about. Please file a bug here:
https://bugs.kde.org/enter_bug.cgi?product=valgrind
and include a (small) testcase.

   Florian

[Valgrind-users] valgrind and gdb

[Marco C. <mar...@op...>]

Good morning,

I can't use valgrind with gdb.

In a terminal I launch my code (real) with valgrind

valgrind --vgdb=yes --vgdb-error=0 ./real

and valgrind answer me


==23498== (action at startup) vgdb me ...
==23498==
==23498== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==23498==   /path/to/gdb ./real
==23498== and then give GDB the following command
==23498==   target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=23498
==23498== --pid is optional if only one valgrind process is running


In another one I launch

gdb ./real

In gdb I give the command

target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=23498

Then I give gdb

continue

After few seconds gdb says


Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000000006018417 in __libc_writev (fd=9, vector=0x6af6710, count=3) at ../sysdeps/unix/sysv/linux/writev.c:50
50    ../sysdeps/unix/sysv/linux/writev.c: File o directory non esistente.


where "non esistente" means "doesn't exist"


I don't really know what happens.

Could you help me understand, please?


Thanks.


Best regards,

Marco

Re: [Valgrind-users] porition names length

[Florian K. <fl...@ei...>]

On 28.10.2015 12:04, Marco Cisternino wrote:
> Good morning,
> 
> I'm new on the list and I would like to ask you something about the Valgrind output.
> 
> My c++ code uses a lot of templates so the name of the functions are usually huge.
> 
> When Valgrind finds an error, it prints the type of error and where it happens "at 0x........: name of the function".
> 
> If the name of the function is too long Valgrind cuts it.
> 
> Is there a way to change the maximal length of the function name?

What you describe should have been fixed in the latest
valgrind release 3.11.0
If you are using an older version, function names will be cut
and there is no way to change that with a command line parameter.
If, however, you are using 3.11.0 then this is a bug we want to know
more about. Please file a bug here:
https://bugs.kde.org/enter_bug.cgi?product=valgrind
and include a (small) testcase.

   Florian

[Valgrind-users] porition names length

[Marco C. <mar...@op...>]

Good morning,

I'm new on the list and I would like to ask you something about the Valgrind output.

My c++ code uses a lot of templates so the name of the functions are usually huge.

When Valgrind finds an error, it prints the type of error and where it happens "at 0x........: name of the function".

If the name of the function is too long Valgrind cuts it.

Is there a way to change the maximal length of the function name?


Thanks.


Best regards,

Marco

[Valgrind-users] Developing a tool using C++STL

[William G. <app...@li...>]

Hello,
I would like to use some C++ containers in my tool.  I have attempted to modify my tool's Makefile.am by adding AM_CXXFLAGS = -std=gnu++11 at the top and changing $(LINK) to $(CXXLINK).  However, because of the -nodefaultlibs switch I have to manually add libraries to be linked.  I receive a multiple definition error:

/usr/lib/gcc/x86_64-redhat-linux/5.1.1/../../../../lib64/libc.a(abort.o): In function `abort':
(.text+0x0): multiple definition of `abort'
../coregrind/libcoregrind-amd64-linux.a(libcoregrind_amd64_linux_a-m_main.o):/home/will/Downloads/vg1/coregrind/m_main.c:2861: first defined here

There is a conflict because of valgrind's redefinition of standard library functions.  Is it possible or are the examples of using C++ in a valgrind tool.

Thanks, William

Re: [Valgrind-users] Detect Global Offset Table (GOT) changes or corruption?

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

> A few Linux and Apple users report unexpected results and I am having
> trouble reproducing the issue. I have not been able to duplicate it,
> even, say on Debian Sid (unstable) with the bleeding edge GCC. Its
> been tough to narrow down, but it appears to be related to the latest
> GCC and possibly Clang compilers. I also suspect it might be related
> to the use of PIC.

We tracked this down to Debian Sid (unstable) running on real Core2
Duo hardware (I had to dust off an old Dell S1555 laptop). I also
needed the Debian maintainer to tar his VM and send it to me.

It appears the GCC 5.2.1 compiler was too aggressive with
-fdevirtualize for a few functions when the definition of the function
is in the header and its inlined.

The functions had a call to SecureByteBlock class, which manages an
array of bytes and zeroizes it on destruction. The function New does
what you would expect - it allocates a new block of memory. It can
also be used to reallocate if the new size is larger then when
created. GCC was omitting some of the calls to New which grew the
array.

Jeff

[Valgrind-users] ARMv8 Vectorized Double-precision Instructions

[Karthik S. <ks...@dr...>]

Hi all,

While running an ARMv8 benchmark, I found that an instruction Valgrind
appears to choke on.

For reference, the error message follows:

"The instruction is legitimate but Valgrind doesn't handle it, i.e. it's
> Valgrind's fault.  If you think this is the case or you are not sure,
> please let us know and we'll try to fix it."


I tracked down the problem instruction: a vectorized form of the double
precision 'fmaxnm' instruction to compare two double precision numbers. The
scalar version of this instruction runs fine, and I can verify that the
vectorized instruction only gets generated by gcc when using the
tree-vectorize flag (and 03).

 405720: 4e60c508 fmaxnm v8.2d, v8.2d, v0.2d


Does anyone know if:

1) Vectorized double-precision instructions are unimplemented in valgrind,
2) This particular instruction has been unimplemented, or
3) The platform I'm using is doing something sticky with these instructions?

Thanks,

Karthik

Re: [Valgrind-users] Detect Global Offset Table (GOT) changes or corruption?

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

On Thu, Oct 22, 2015 at 7:52 AM, Julian Seward <js...@ac...> wrote:
>
>> When PIC is in effect, the Global Offset Table (GOT) is utilized.
>> Under the Linux ABI, that means EBX/RBX must be preserved because it
>> holds the pointer to the GOT.
>
> If the GOT pointer register is getting trashed by inline assembly, I'd
> imagine your program would crash very shortly afterwards, in a somewhat
> obvious way (if you're proficient at reading assembly that is).

Yeah, that's what I hoped for. But its showing up as a hang at the
moment. (And I would probably suffer my fair share of reading the
ASM).

No one has provided me with a dump, and no one has provided me with
remote/SSH access to a misbehaving machine. They are not making it
easy :(

I'm trying to go the extra mile because this could be a portent of
things to come at GCC 5.2 or 5.3. I want to get out ahead of this
issue in case it becomes wider spread.

> Also, if the inline asm is wrong, different optimisation levels may well
> have different effects.  Is it -O level dependent?

The issue does not appear to be transient based on optimizations. The
folks who are reporting it use -O{1|2|3}.

I know a -DDISABLE_ASM resolves the issue. I don't know what happens
under the configuration {no-PIC, with-ASM}. No one has reported back.

I also know -mno-sse{3|4|4_1|4_2} does not affect the issue.

> You list a bunch of memory-error checking tools (Memcheck, ASan, etc) but
> don't say anything about race-checking (Helgrind, DRD, TSan, etc).  Did you
> check for races and other threading problems?

The self tests are single threaded, so I guess I am fortunate that its
not a factor. Thank the {Lord|Allay|<Favorite Deity>} for small
miracles :)

Jeff

Re: [Valgrind-users] Detect Global Offset Table (GOT) changes or corruption?

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

> When PIC is in effect, the Global Offset Table (GOT) is utilized.
> Under the Linux ABI, that means EBX/RBX must be preserved because it
> holds the pointer to the GOT.

If the GOT pointer register is getting trashed by inline assembly, I'd
imagine your program would crash very shortly afterwards, in a somewhat
obvious way (if you're proficient at reading assembly that is).

Also, if the inline asm is wrong, different optimisation levels may well
have different effects.  Is it -O level dependent?

You list a bunch of memory-error checking tools (Memcheck, ASan, etc) but
don't say anything about race-checking (Helgrind, DRD, TSan, etc).  Did you
check for races and other threading problems?

J

Re: [Valgrind-users] Valgrind Bad option: --vgdb-error=0

[Ulrich-Lorenz S. <u.s...@ra...>]

Thanks, I'll upgrade.

Uli

Re: [Valgrind-users] Valgrind Bad option: --vgdb-error=0

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

On 22/10/15 09:36, Ulrich-Lorenz Schlüter wrote:
>> What does "valgrind --version" say?
>>
>> Tom
>>
>
> valgrind-3.6.0

So as I thought then. That is five years old and vgdb support didn't 
appear until the 3.7.0 release.

Tom

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

Re: [Valgrind-users] Valgrind Bad option: --vgdb-error=0

[Ulrich-Lorenz S. <u.s...@ra...>]

> What does "valgrind --version" say?
> 
> Tom
> 

valgrind-3.6.0

Uli

Re: [Valgrind-users] Detect Global Offset Table (GOT) changes or corruption?

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

> Is it possible to use Valgrind to detect unexpected changes to the GOT
> pointer when PIC is in effect? Or put another way, is it possible to detect
> unexpected changes to EBX/RBX?

There is no builtin feature to do that.  But if you are highly motivated
then here's how.

Add two words to the VEX register state structure for a thread: the
expected GOT value for RBX/EBX, and a pointer to a linked list of previous
pairs of words.  In the VEX code generator, recognize the "set GOT
pointer" idiom "CALL [MOV (%RSP),%RBX; RET]; ADDQ $NNNN,RBX" then cons the
new value of RBX into the front of the list.  Recognize
return-from-subroutine "POP %RBX; ...; RET", then check RBX against the
expected GOT, and cdr the list.

[Valgrind-users] Detect Global Offset Table (GOT) changes or corruption?

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

Hi Everyone,

I have a cross platform project that uses a fair amount on inline
assembly. The project is clean under Valgrind, Undefined Behavior
sanitizer, Address sanitizer and even Microsoft's Enterprise Analysis
and Coverity. However...

A few Linux and Apple users report unexpected results and I am having
trouble reproducing the issue. I have not been able to duplicate it,
even, say on Debian Sid (unstable) with the bleeding edge GCC. Its
been tough to narrow down, but it appears to be related to the latest
GCC and possibly Clang compilers. I also suspect it might be related
to the use of PIC.

When PIC is in effect, the Global Offset Table (GOT) is utilized.
Under the Linux ABI, that means EBX/RBX must be preserved because it
holds the pointer to the GOT.

Is it possible to use Valgrind to detect unexpected changes to the GOT
pointer when PIC is in effect? Or put another way, is it possible to
detect unexpected changes to EBX/RBX?

(I know its not an easy request. My apologies for asking).

Thanks in Advance.

Re: [Valgrind-users] Valgrind Bad option: --vgdb-error=0

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

On 21/10/15 15:36, Ulrich-Lorenz Schlüter wrote:

> With:
> valgrind --vgdb=yes --vgdb-error=0 --track-origins=yes --leak-check=full
> ./program
> I get the following error:
> valgrind: Bad option: --vgdb=yes
>
> What am I doing wrong?

If I had to guess I'd say you're using a really old version of valgrind.

What does "valgrind --version" say?

Tom

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

[Valgrind-users] Valgrind Bad option: --vgdb-error=0

[Ulrich-Lorenz S. <u.s...@ra...>]

Hi there,

With:
valgrind --vgdb=yes --vgdb-error=0 --track-origins=yes --leak-check=full
./program
I get the following error:
valgrind: Bad option: --vgdb=yes

What am I doing wrong?

Thanks and regards,

Uli

[Valgrind-users] cross compiling to arm7

[Amir G. <am...@Lo...>]

Hi,
How can I cross compile valgrind to ARM7?

Thanks,



[cid:image001.jpg@01CF0C60.A1594690]

Amir Gall Heimberg
Software Development



T

+972 9 8354848

F

+972 9 8656262


                        [תיאור: 70Twitter.png] <https://twitter.com/LogiTag>  [תיאור: 70Facebook.png] <https://www.facebook.com/LogitagSystems>   [תיאור: 70LinkedIn.png] <http://www.linkedin.com/company/logitag>   [תיאור: 70YouTube.png] <http://www.youtube.com/user/LogiTag>
[cid:image006.jpg@01CF0C60.A1594690]<http://www.logi-tag.com/>

Re: [Valgrind-users] Building valgrind on solaris x86

[Ivo R. <iv...@iv...>]

2015-10-19 23:04 GMT+02:00 Paul Floyd <pa...@fr...>:

>
> On 19 Oct 2015, at 20:25, Matthew Wozniczka wrote:
>
> X86/Solaris is listed as supported @
> http://valgrind.org/info/platforms.html, so I grabbed a copy of
> valgrind-3.11.0.tar.bz2 and followed the instructions @
> http://valgrind.org/docs/manual/dist.install.html, but I got the
> following error when running configure:
>
> $ ./configure --prefix=/home/mattheww/valgrind-solx86
> checking for a BSD-compatible install... /opt/csw/bin/ginstall -c
>
> configure: error: Valgrind is operating system specific. Sorry.
>
> $ uname -a
> SunOS B2S-SOL10x86-2 5.10 Generic_147148-26 i86pc i386 i86pc
>
>
>
> I haven't tried despite being something of a dyed in the wool Solaris
> user. At a guess, Solaris 11 is required.
>

Yes, please have a look at README.solaris for precise requirements.
I.

Re: [Valgrind-users] Building Valgrind on Solaris

[Matthew W. <mat...@si...>]

I was able to get it to build after moving to a solaris 11 machine, installing gcc 4.9, and playing around with some paths (mostly issues of it using make vs gmake, etc).

It seems to mostly work, two things I noticed though:

-          C++ symbols don’t get demangled in the output, I need to run it through c++filt. This may be because I built the program using sun studio instead of gcc?

-          I’m seeing invalid reads of size 8 in _Unw_jmp, where it complains that the address is several hundred bytes beneath the stack pointer. This seems to be happening when exceptions are thrown. I’m guessing this is also due to not building with gcc?

From: Ivo Raisr [mailto:iv...@iv...]
Sent: October-19-15 11:57 AM
To: Matthew Wozniczka <mat...@si...>
Cc: val...@li...
Subject: Re: [Valgrind-users] Building Valgrind on Solaris



2015-10-19 20:34 GMT+02:00 Matthew Wozniczka <mat...@si...<mailto:mat...@si...>>:
X86/Solaris is listed as supported @ http://valgrind.org/info/platforms.html, so I grabbed a copy of valgrind-3.11.0.tar.bz2 and followed the instructions @ http://valgrind.org/docs/manual/dist.install.html, but I got the following error when running configure:

$ ./configure --prefix=/home/mattheww/valgrind-solx86
...
checking for a supported OS... no (solaris2.10)
configure: error: Valgrind is operating system specific. Sorry.

$ uname -a
SunOS B2S-SOL10x86-2 5.10 Generic_147148-26 i86pc i386 i86pc


Matthew,

Please study information in README.solaris. It lists all the requirements your Solaris version
needs to satisfy. Most importantly it states you need either illumos or Solaris 11.
Solaris 10 simply does not work. I would be glad to assist you in building Valgrind
on any Solaris 11 or higher system.

Kind regards,
I.

Re: [Valgrind-users] Building valgrind on solaris x86

[Paul F. <pa...@fr...>]

On 19 Oct 2015, at 20:25, Matthew Wozniczka wrote:

> X86/Solaris is listed as supported @ http://valgrind.org/info/platforms.html, so I grabbed a copy of valgrind-3.11.0.tar.bz2 and followed the instructions @ http://valgrind.org/docs/manual/dist.install.html, but I got the following error when running configure:
>  
> $ ./configure --prefix=/home/mattheww/valgrind-solx86
> checking for a BSD-compatible install... /opt/csw/bin/ginstall -c
> 
> configure: error: Valgrind is operating system specific. Sorry.
>  
> $ uname -a
> SunOS B2S-SOL10x86-2 5.10 Generic_147148-26 i86pc i386 i86pc


I haven't tried despite being something of a dyed in the wool Solaris user. At a guess, Solaris 11 is required.

A+
Paul

[Valgrind-users] Building valgrind on solaris x86

[Matthew W. <mat...@si...>]

X86/Solaris is listed as supported @ http://valgrind.org/info/platforms.html, so I grabbed a copy of valgrind-3.11.0.tar.bz2 and followed the instructions @ http://valgrind.org/docs/manual/dist.install.html, but I got the following error when running configure:

$ ./configure --prefix=/home/mattheww/valgrind-solx86
checking for a BSD-compatible install... /opt/csw/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/csw/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for ranlib... ranlib
checking for a sed that does not truncate output... /opt/csw/bin/gsed
checking for ar... /usr/ccs/bin/ar
checking for perl... /usr/bin/perl
checking for gdb... /no/gdb/was/found/at/configure/time
checking dependency style of gcc... gcc3
checking for diff -u... No differences encountered
yes
checking for a supported version of gcc... ok (4.9.2)
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking for a supported CPU... ok (i386)
checking for a 64-bit only build... no
checking for a 32-bit only build... no
checking for a supported OS... no (solaris2.10)
configure: error: Valgrind is operating system specific. Sorry.

$ uname -a
SunOS B2S-SOL10x86-2 5.10 Generic_147148-26 i86pc i386 i86pc

Re: [Valgrind-users] Building Valgrind on Solaris

[Ivo R. <iv...@iv...>]

2015-10-19 20:34 GMT+02:00 Matthew Wozniczka <mat...@si...>:

> X86/Solaris is listed as supported @
> http://valgrind.org/info/platforms.html, so I grabbed a copy of
> valgrind-3.11.0.tar.bz2 and followed the instructions @
> http://valgrind.org/docs/manual/dist.install.html, but I got the
> following error when running configure:
>
>
>
> $ ./configure --prefix=/home/mattheww/valgrind-solx86
>
> ...
>
> checking for a supported OS... no (solaris2.10)
>
> configure: error: Valgrind is operating system specific. Sorry.
>
>
>
> $ uname -a
>
> SunOS B2S-SOL10x86-2 5.10 Generic_147148-26 i86pc i386 i86pc
>


Matthew,

Please study information in README.solaris. It lists all the requirements
your Solaris version
needs to satisfy. Most importantly it states you need either illumos or
Solaris 11.
Solaris 10 simply does not work. I would be glad to assist you in building
Valgrind
on any Solaris 11 or higher system.

Kind regards,
I.

[Valgrind-users] Building Valgrind on Solaris

[Matthew W. <mat...@si...>]

X86/Solaris is listed as supported @ http://valgrind.org/info/platforms.html, so I grabbed a copy of valgrind-3.11.0.tar.bz2 and followed the instructions @ http://valgrind.org/docs/manual/dist.install.html, but I got the following error when running configure:

$ ./configure --prefix=/home/mattheww/valgrind-solx86
checking for a BSD-compatible install... /opt/csw/bin/ginstall -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /opt/csw/bin/gmkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether ln -s works... yes
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking how to run the C preprocessor... gcc -E
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for ranlib... ranlib
checking for a sed that does not truncate output... /opt/csw/bin/gsed
checking for ar... /usr/ccs/bin/ar
checking for perl... /usr/bin/perl
checking for gdb... /no/gdb/was/found/at/configure/time
checking dependency style of gcc... gcc3
checking for diff -u... No differences encountered
yes
checking for a supported version of gcc... ok (4.9.2)
checking build system type... i386-pc-solaris2.10
checking host system type... i386-pc-solaris2.10
checking for a supported CPU... ok (i386)
checking for a 64-bit only build... no
checking for a 32-bit only build... no
checking for a supported OS... no (solaris2.10)
configure: error: Valgrind is operating system specific. Sorry.

$ uname -a
SunOS B2S-SOL10x86-2 5.10 Generic_147148-26 i86pc i386 i86pc

Re: [Valgrind-users] Valgrind on MIPS no output and 100% CPU

[Adam P. <ada...@ho...>]

Thanks for the suggestions. I'll try them and see how far I get.
Adam

> Subject: Re: [Valgrind-users] Valgrind on MIPS no output and 100% CPU
> From: phi...@sk...
> To: ada...@ho...
> CC: val...@li...
> Date: Wed, 14 Oct 2015 23:42:02 +0200
> 
> On Wed, 2015-10-14 at 15:30 +0100, Adam Porteous wrote
> 
> 
> >      1. I don't see any output on the console at all and can see that
> >         valgrind is nearly 100% CPU with the output from using top
> >         (hardware has 2 cores which explains the 48%):
> > 6210  6190 root     R    16004  13%   0  48%
> > {memcheck-mips32} ./valgrind
> 
> > I know this is not much information to go on but can anyone provide a
> > suggestion as to how I could proceed?
> 
> Here is what you could do:
> 
> First check if the loop happens before startup,
> or in the valgrind code,
> or in the guest code.
> 
> So, first thing to try is to run with more tracing, e.g. with
>    --trace-flags=00100000
> and/or with
>    -v -v -v -d -d -d
> 
> If the guest code starts executing, then you should e.g.
> see things such as 
> 
> ==== SB 0 (evchecks 0) [tid 1] 0x4000d00 UNKNOWN_FUNCTION /lib/i386-linux-gnu/ld-2.19.so+0xd00
> ==== SB 1 (evchecks 1) [tid 1] 0x4004330 _dl_start+16 /lib/i386-linux-gnu/ld-2.19.so+0x4330
> ...
> 
> After that, when no progress is visible, you can use vgdb (and/or gdb+vgdb) to
> see if the loop is in the guest code.
> E.g., from the shell, do (several times): 
>     vgdb v.info scheduler
> That should show where it loops
> (and if it loops, you could investigate using gdb+vgdb).
> 
> If vgdb cannot connect, then probably the loop is in the valgrind 'core'.
> You can then maybe see where in the valgrind code it is looping, by using
> gdb and directly attaching to the executable.
> 
> Philippe
> 
> 
 		 	   		  

Re: [Valgrind-users] Valgrind on MIPS no output and 100% CPU

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

On Wed, 2015-10-14 at 15:30 +0100, Adam Porteous wrote


>      1. I don't see any output on the console at all and can see that
>         valgrind is nearly 100% CPU with the output from using top
>         (hardware has 2 cores which explains the 48%):
> 6210  6190 root     R    16004  13%   0  48%
> {memcheck-mips32} ./valgrind

> I know this is not much information to go on but can anyone provide a
> suggestion as to how I could proceed?

Here is what you could do:

First check if the loop happens before startup,
or in the valgrind code,
or in the guest code.

So, first thing to try is to run with more tracing, e.g. with
   --trace-flags=00100000
and/or with
   -v -v -v -d -d -d

If the guest code starts executing, then you should e.g.
see things such as 

==== SB 0 (evchecks 0) [tid 1] 0x4000d00 UNKNOWN_FUNCTION /lib/i386-linux-gnu/ld-2.19.so+0xd00
==== SB 1 (evchecks 1) [tid 1] 0x4004330 _dl_start+16 /lib/i386-linux-gnu/ld-2.19.so+0x4330
...

After that, when no progress is visible, you can use vgdb (and/or gdb+vgdb) to
see if the loop is in the guest code.
E.g., from the shell, do (several times): 
    vgdb v.info scheduler
That should show where it loops
(and if it loops, you could investigate using gdb+vgdb).

If vgdb cannot connect, then probably the loop is in the valgrind 'core'.
You can then maybe see where in the valgrind code it is looping, by using
gdb and directly attaching to the executable.

Philippe