valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] unhandled instruction.

[Eliot M. <mo...@cs...>]

On 7/29/2015 11:04 PM, John Reiser wrote:
>> disInstr(arm): unhandled instruction: 0xEEBA0BEF
>>                    cond=14(0xE) 27:20=235(0xEB) 4:4=0 3:0=15(0xF)
>
> You can help even more by telling us which hardware you have.
> For instance, this is an original RaspberryPi B+:
> -----
> $ cat /proc/cpuinfo
> processor	: 0
> model name	: ARMv6-compatible processor rev 7 (v6l)
> BogoMIPS	: 2.00
> Features	: half thumb fastmult vfp edsp java tls
> CPU implementer	: 0x41
> CPU architecture: 7
> CPU variant	: 0x0
> CPU part	: 0xb76
> CPU revision	: 7
>
> Hardware	: BCM2708
> Revision	: 0010
> -----
>
> If you create a file with the unhandled instruction, and compile and disassemble it,
> then you can see what the instruction is:
> -----foo.s
> 	.word 0xEEBA0BEF
> -----
> $ gcc -c foo.s
> $ gdb foo.o
> (gdb) x/i 0
> 0: vcvt.f64.s32  d0, d0, #1
> (gdb)

If we are really talking about the ARM processor, this instruction is
supposedly handled:

https://bugs.kde.org/show_bug.cgi?id=308717

Regards -- Eliot Moss

Re: [Valgrind-users] Valgrind to profile CPython and Nuitka

[Josef W. <Jos...@gm...>]

Am 25.07.2015 um 00:42 schrieb Kay Hayen:
> I am therefore considering an improvement to callgrind, that would try 
> to make it emit the Python function name, and the Python source file 
> instead. Do you think that is possible, and can you give me pointers to 
> inside the valgrind source distribution, what to change, where to hook?
> 
> Looking at callstack.c in callgrind directory, would it be possible to 
> make direct accesses to the running binary to capture stuff from its 
> data, from function arguments, or is that not possible?

When callgrind detects that a function is entered, it is quite simple to
modify the captured function name with whatever information is available,
which directly is reflected in the profile output.

See attached patch, which allows to add parameter values to function names
to better distinguish recursive calls of same functions but with different
parameters.

Not sure this patch still applies, but should provide the direction.
It was never added to main line, as the code depends on the calling
convention and thus is not platform independent as VG tools are expected
to be... the patch directly accesses stack values from the client code.

For you, passing the currently executed Phython function name to callgrind
for extending the function names should work fine. This can be done by
adding a client call, are by setting a global var which is recognized
by callgrind.

Hope this helps.

Josef

> 
> Should this be possible, it would enable profiling of Python code with 
> valgrind that is accurate for even single iterations as it's based on 
> ticks. So please help me there, if you can.
> 
> Yours,
> Kay Hayen
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 

-- 
Dr. Josef Weidendorfer, Informatik, Technische Universität München
TUM I-10 - FMI 01.04.035 - Tel. 089 / 289-18454

Re: [Valgrind-users] Applying Helgrind On UML

[Lou C. <lou...@16...>]

Hi Dan,

Thank you sooo much for replying!

Your suggestions are really helpful. We'll see what we can do here.

-------------------
Chang

在 2015-7-30，上午12:14，Dan Kegel <da...@ke...> 写道：

> In 2008, there were some patches, see 
> https://web.archive.org/web/20100126181646/http://uml.jfdi.org/uml/Wiki.jsp?page=ValgrindingUML
> I think they were 32 bits only, needed to be extended to 64 bits before they could be considered for merging.
> 
> I may have missed a memo since then, no idea what current status is.
> 
> See also similar approaches, e.g. https://github.com/google/kasan
> - Dan
> 
> Am 29.07.2015 10:42 nachm. schrieb "Lou Chang" <lou...@16...>:
> Dear Valgrind Developers,
> 
> My name is Chang Lou, an undergraduate student in China. I’m trying to enable Helgrind on User-mode Linux as a research project.
> 
> I've looked through the mailing lists and found people had done memcheck on UML but not helgrind. So I’m wondering is there anyone done enabling Helgrind on UML before? If not, is it because it’s impossible or just simply because no one had done it?
> 
> During the hacking, I’ve met some problems like Helgrind unexpectedly exit. It would be great if you guys can share me some hints or learning materials. It would be greatly appreciated.
> 
> Thanks in advance.
> 
> --------------------------
> Chang
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Applying Helgrind On UML

[Dan K. <da...@ke...>]

Sorry, missed that you were only into helgrind.

BTW see also https://github.com/google/ktsan/wiki for something similar.
Am 29.07.2015 11:14 nachm. schrieb "Dan Kegel" <da...@ke...>:

> In 2008, there were some patches, see
>
> https://web.archive.org/web/20100126181646/http://uml.jfdi.org/uml/Wiki.jsp?page=ValgrindingUML
> I think they were 32 bits only, needed to be extended to 64 bits before
> they could be considered for merging.
>
> I may have missed a memo since then, no idea what current status is.
>
> See also similar approaches, e.g. https://github.com/google/kasan
> - Dan
> Am 29.07.2015 10:42 nachm. schrieb "Lou Chang" <lou...@16...>:
>
>> Dear Valgrind Developers,
>>
>> My name is Chang Lou, an undergraduate student in China. I’m trying to
>> enable Helgrind on User-mode Linux as a research project.
>>
>> I've looked through the mailing lists and found people had done memcheck
>> on UML but not helgrind. So I’m wondering is there anyone done enabling
>> Helgrind on UML before? If not, is it because it’s impossible or just
>> simply because no one had done it?
>>
>> During the hacking, I’ve met some problems like Helgrind unexpectedly
>> exit. It would be great if you guys can share me some hints or learning
>> materials. It would be greatly appreciated.
>>
>> Thanks in advance.
>>
>> --------------------------
>> Chang
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Valgrind-users mailing list
>> Val...@li...
>> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>>
>

Re: [Valgrind-users] Applying Helgrind On UML

[Dan K. <da...@ke...>]

In 2008, there were some patches, see
https://web.archive.org/web/20100126181646/http://uml.jfdi.org/uml/Wiki.jsp?page=ValgrindingUML
I think they were 32 bits only, needed to be extended to 64 bits before
they could be considered for merging.

I may have missed a memo since then, no idea what current status is.

See also similar approaches, e.g. https://github.com/google/kasan
- Dan
Am 29.07.2015 10:42 nachm. schrieb "Lou Chang" <lou...@16...>:

> Dear Valgrind Developers,
>
> My name is Chang Lou, an undergraduate student in China. I’m trying to
> enable Helgrind on User-mode Linux as a research project.
>
> I've looked through the mailing lists and found people had done memcheck
> on UML but not helgrind. So I’m wondering is there anyone done enabling
> Helgrind on UML before? If not, is it because it’s impossible or just
> simply because no one had done it?
>
> During the hacking, I’ve met some problems like Helgrind unexpectedly
> exit. It would be great if you guys can share me some hints or learning
> materials. It would be greatly appreciated.
>
> Thanks in advance.
>
> --------------------------
> Chang
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

[Valgrind-users] Applying Helgrind On UML

[Lou C. <lou...@16...>]

Dear Valgrind Developers,

My name is Chang Lou, an undergraduate student in China. I’m trying to enable Helgrind on User-mode Linux as a research project. 

I've looked through the mailing lists and found people had done memcheck on UML but not helgrind. So I’m wondering is there anyone done enabling Helgrind on UML before? If not, is it because it’s impossible or just simply because no one had done it?

During the hacking, I’ve met some problems like Helgrind unexpectedly exit. It would be great if you guys can share me some hints or learning materials. It would be greatly appreciated.

Thanks in advance.

--------------------------
Chang

Re: [Valgrind-users] unhandled instruction.

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

> disInstr(arm): unhandled instruction: 0xEEBA0BEF
>                   cond=14(0xE) 27:20=235(0xEB) 4:4=0 3:0=15(0xF)

You can help even more by telling us which hardware you have.
For instance, this is an original RaspberryPi B+:
-----
$ cat /proc/cpuinfo
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 2.00
Features	: half thumb fastmult vfp edsp java tls
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2708
Revision	: 0010
-----

If you create a file with the unhandled instruction, and compile and disassemble it,
then you can see what the instruction is:
-----foo.s
	.word 0xEEBA0BEF
-----
$ gcc -c foo.s
$ gdb foo.o
(gdb) x/i 0
0: vcvt.f64.s32  d0, d0, #1
(gdb)

Re: [Valgrind-users] unhandled instruction.

[Eliot M. <mo...@cs...>]

On 7/29/2015 8:35 PM, Thomas Green wrote:
> I'm new to this list, but was unable to google an answer to this one.  This is an unhandled instruction error, and I'm pretty sure it's not in my program (as it happens to be inside of QT, and I didn't get the warning about a bad jump).  So, as the instructions say, I'm letting you know....
>
> disInstr(arm): unhandled instruction: 0xEEBA0BEF
>                   cond=14(0xE) 27:20=235(0xEB) 4:4=0 3:0=15(0xF)
> ==3014== valgrind: Unrecognised instruction at address 0x4f5b628.
> ==3014==    at 0x4F5B628: QQuickText::setFont(QFont const&) (in /usr/lib/libQt5Quick.so.5.3.1)
> ==3014== Your program just tried to execute an instruction that Valgrind
> ==3014== did not recognise.  There are two possible reasons for this.
> ==3014== 1. Your program has a bug and erroneously jumped to a non-code
> ==3014==    location.  If you are running Memcheck and you just saw a
> ==3014==    warning about a bad jump, it's probably your program's fault.
> ==3014== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==3014==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==3014==    you are not sure, please let us know and we'll try to fix it.
> ==3014== Either way, Valgrind will now raise a SIGILL signal which will
> ==3014== probably kill your program.

The Intel platform has a huge number of instructions and variants on them.
Valgrind covers *most* of them, but this means that this particular instruction
it does not recognize.

It's a moving target -- new models and new instructions come out all the time.

All that said, one of the regular contributors may be able to add it ...

Regards -- Eliot Moss

[Valgrind-users] unhandled instruction.

[Thomas G. <TG...@So...>]

I'm new to this list, but was unable to google an answer to this one.  This is an unhandled instruction error, and I'm pretty sure it's not in my program (as it happens to be inside of QT, and I didn't get the warning about a bad jump).  So, as the instructions say, I'm letting you know....

disInstr(arm): unhandled instruction: 0xEEBA0BEF
                 cond=14(0xE) 27:20=235(0xEB) 4:4=0 3:0=15(0xF)
==3014== valgrind: Unrecognised instruction at address 0x4f5b628.
==3014==    at 0x4F5B628: QQuickText::setFont(QFont const&) (in /usr/lib/libQt5Quick.so.5.3.1)
==3014== Your program just tried to execute an instruction that Valgrind
==3014== did not recognise.  There are two possible reasons for this.
==3014== 1. Your program has a bug and erroneously jumped to a non-code
==3014==    location.  If you are running Memcheck and you just saw a
==3014==    warning about a bad jump, it's probably your program's fault.
==3014== 2. The instruction is legitimate but Valgrind doesn't handle it,
==3014==    i.e. it's Valgrind's fault.  If you think this is the case or
==3014==    you are not sure, please let us know and we'll try to fix it.
==3014== Either way, Valgrind will now raise a SIGILL signal which will
==3014== probably kill your program.

Re: [Valgrind-users] Valgrind doesn't create readable core dumps

[Mikhail B. <mik...@de...>]

Hello

I see that gdb can't find general purpose registers.
/warning: Couldn't find general-purpose registers in core file.//

/Maybe valgrind adds these registers with some wrong offset?

On 07/14/2015 04:52 PM, Mikhail Baikov wrote:
> Architecture is mipsel. OS is Linux.
> the output of uname -a is
> Linux 192.168.23.55 3.3.8-3.3 #1 SMP Fri Jul 10 10:11:31 MSK 2015 mips 
> GNU/Linux
>
>
> On 07/13/2015 08:28 PM, Ivo Raisr wrote:
>>
>>
>> 2015-07-13 19:17 GMT+02:00 Mikhail Baikov 
>> <mik...@de... <mailto:mik...@de...>>:
>>
>>     Hello.
>>     Is there a possibility to disable signals handling by valgrind?
>>     The core will be created by the system and that will solve the
>>     problem.
>>
>>
>> This is not an option.
>> Run of your program (guest) is simulated by Valgrind (host).
>> Therefore Valgrind itself must create the guest coredump;
>> operating system can only create coredump of Valgrind (host).
>>
>> What is your OS and architecture (for example x86/Linux)?
>>
>> I.
>>
>>
>>     On 07/02/2015 04:11 PM, Mikhail Baikov wrote:
>>>     Hello
>>>
>>>     I've got a problem while reading dumps created by valgrind. I've
>>>     compiled and run this code with valgrind and without it.
>>>     /int main()//
>>>     //{//
>>>     //    const char *str = "segfault";//
>>>     //    *(char *)str = 'a';//
>>>     //    return 1;//
>>>     //}
>>>     /
>>>
>>>     When I read the system created core dump it's readable
>>>     /Core was generated by `./seg'.//
>>>     //Program terminated with signal 11, Segmentation fault.//
>>>     //#0  0x004006d0 in main () at ./seg.c:4/
>>>
>>>     When I try to read the core dump created by valgrind, gdb is
>>>     unable to read it
>>>     /warning: Couldn't find general-purpose registers in core file.//
>>>     //
>>>     //warning: Could not load shared library symbols for 5
>>>     libraries, e.g.
>>>     /bin/valgrind/lib/valgrind/vgpreload_core-mips32-linux.so.//
>>>     //Use the "info sharedlibrary" command to see the complete
>>>     listing.//
>>>     //Do you need "set solib-search-path" or "set sysroot"?//
>>>     //Core was generated by `'.//
>>>     //
>>>     //warning: Couldn't find general-purpose registers in core file.//
>>>     //../../gdb-7.3.1/gdb/frame-unwind.c:133: internal-error:
>>>     frame_unwind_find_by_frame failed//
>>>     //A problem internal to GDB has been detected,//
>>>     //further debugging may prove unreliable./
>>
>>
>
> -- 
> Sincerely
> Mikhail Baikov
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

-- 
Sincerely
Mikhail Baikov

[Valgrind-users] Valgrind to profile CPython and Nuitka

[Kay H. <kay...@gm...>]

Hello there,

my name is Kay Hayen, I am the author of the Python compiler Nuitka 
(http://nuitka.net) and so far I have very successfully used Valgrind to 
analyse the performance of my created binaries in comparison to original 
CPython bytecode interpretation.

However, I am kind of set now, on creating a comparison tool. The user 
should be allowed to run his code with Nuitka and CPython, and it should 
be possible to compare the performance. I sort of promised this to my 
users during Europython this week.

For CPython, and partially Nuitka, where bytecode becomes evaluated, and 
effectively always in a Python frame, function or module, this is 
basically is just PyEval_CallFrame (or similar) on the C call stack, and 
as such totally impossible to associate to decode without looking at its 
arguments.

(For Nuitka, there also may be possibly inlining, which will not have a 
call made, but instead a debugging information change only. But lets 
ignore that, I probably need to solve that when presenting the data.)

I am therefore considering an improvement to callgrind, that would try 
to make it emit the Python function name, and the Python source file 
instead. Do you think that is possible, and can you give me pointers to 
inside the valgrind source distribution, what to change, where to hook?

Looking at callstack.c in callgrind directory, would it be possible to 
make direct accesses to the running binary to capture stuff from its 
data, from function arguments, or is that not possible?

Should this be possible, it would enable profiling of Python code with 
valgrind that is accurate for even single iterations as it's based on 
ticks. So please help me there, if you can.

Yours,
Kay Hayen

[Valgrind-users] --db-attach to be removed in next valgrind release

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

When valgrind 3.10.0 was released in September 2014, the feature to
attach a debugger using --db-attach was deprecated and scheduled to be
removed in the next feature release.
The rationale for deprecation is valgrind's built-in GDB server. Its
capabilities are superior and it is also less brittle. Detailed
documentation can be found here:
http://valgrind.org/docs/manual/manual-core-adv.html#manual-core-adv.gdbserver

This note is a gentle reminder of that upcoming change. We haven't heard
any objections to the plan and *now* would be a good time to raise them,
if there are any.

   Florian

Re: [Valgrind-users] Valgrind doesn't create readable core dumps

[Mikhail B. <mik...@de...>]

Architecture is mipsel. OS is Linux.
the output of uname -a is
Linux 192.168.23.55 3.3.8-3.3 #1 SMP Fri Jul 10 10:11:31 MSK 2015 mips 
GNU/Linux


On 07/13/2015 08:28 PM, Ivo Raisr wrote:
>
>
> 2015-07-13 19:17 GMT+02:00 Mikhail Baikov 
> <mik...@de... <mailto:mik...@de...>>:
>
>     Hello.
>     Is there a possibility to disable signals handling by valgrind?
>     The core will be created by the system and that will solve the
>     problem.
>
>
> This is not an option.
> Run of your program (guest) is simulated by Valgrind (host).
> Therefore Valgrind itself must create the guest coredump;
> operating system can only create coredump of Valgrind (host).
>
> What is your OS and architecture (for example x86/Linux)?
>
> I.
>
>
>     On 07/02/2015 04:11 PM, Mikhail Baikov wrote:
>>     Hello
>>
>>     I've got a problem while reading dumps created by valgrind. I've
>>     compiled and run this code with valgrind and without it.
>>     /int main()//
>>     //{//
>>     //    const char *str = "segfault";//
>>     //    *(char *)str = 'a';//
>>     //    return 1;//
>>     //}
>>     /
>>
>>     When I read the system created core dump it's readable
>>     /Core was generated by `./seg'.//
>>     //Program terminated with signal 11, Segmentation fault.//
>>     //#0  0x004006d0 in main () at ./seg.c:4/
>>
>>     When I try to read the core dump created by valgrind, gdb is
>>     unable to read it
>>     /warning: Couldn't find general-purpose registers in core file.//
>>     //
>>     //warning: Could not load shared library symbols for 5 libraries,
>>     e.g. /bin/valgrind/lib/valgrind/vgpreload_core-mips32-linux.so.//
>>     //Use the "info sharedlibrary" command to see the complete listing.//
>>     //Do you need "set solib-search-path" or "set sysroot"?//
>>     //Core was generated by `'.//
>>     //
>>     //warning: Couldn't find general-purpose registers in core file.//
>>     //../../gdb-7.3.1/gdb/frame-unwind.c:133: internal-error:
>>     frame_unwind_find_by_frame failed//
>>     //A problem internal to GDB has been detected,//
>>     //further debugging may prove unreliable./
>
>

-- 
Sincerely
Mikhail Baikov

Re: [Valgrind-users] Valgrind doesn't create readable core dumps

[Ivo R. <ivo...@gm...>]

2015-07-13 19:17 GMT+02:00 Mikhail Baikov <mik...@de...>:

>  Hello.
> Is there a possibility to disable signals handling by valgrind? The core
> will be created by the system and that will solve the problem.
>

This is not an option.
Run of your program (guest) is simulated by Valgrind (host).
Therefore Valgrind itself must create the guest coredump;
operating system can only create coredump of Valgrind (host).

What is your OS and architecture (for example x86/Linux)?

I.


>
> On 07/02/2015 04:11 PM, Mikhail Baikov wrote:
>
> Hello
>
> I've got a problem while reading dumps created by valgrind. I've compiled
> and run this code with valgrind and without it.
> *int main()*
> *{*
> *    const char *str = "segfault";*
> *    *(char *)str = 'a';*
> *    return 1;*
>
> *} *
>
> When I read the system created core dump it's readable
> *Core was generated by `./seg'.*
> *Program terminated with signal 11, Segmentation fault.*
> *#0  0x004006d0 in main () at ./seg.c:4*
>
> When I try to read the core dump created by valgrind, gdb is unable to
> read it
> *warning: Couldn't find general-purpose registers in core file.*
>
> *warning: Could not load shared library symbols for 5 libraries, e.g.
> /bin/valgrind/lib/valgrind/vgpreload_core-mips32-linux.so.*
> *Use the "info sharedlibrary" command to see the complete listing.*
> *Do you need "set solib-search-path" or "set sysroot"?*
> *Core was generated by `'.*
>
> *warning: Couldn't find general-purpose registers in core file.*
> *../../gdb-7.3.1/gdb/frame-unwind.c:133: internal-error:
> frame_unwind_find_by_frame failed*
> *A problem internal to GDB has been detected,*
> *further debugging may prove unreliable.*
>
>

Re: [Valgrind-users] Valgrind doesn't create readable core dumps

[Mikhail B. <mik...@de...>]

Hello.
Is there a possibility to disable signals handling by valgrind? The core 
will be created by the system and that will solve the problem.

On 07/02/2015 04:11 PM, Mikhail Baikov wrote:
> Hello
>
> I've got a problem while reading dumps created by valgrind. I've 
> compiled and run this code with valgrind and without it.
> /int main()//
> //{//
> //    const char *str = "segfault";//
> //    *(char *)str = 'a';//
> //    return 1;//
> //}
> /
>
> When I read the system created core dump it's readable
> /Core was generated by `./seg'.//
> //Program terminated with signal 11, Segmentation fault.//
> //#0  0x004006d0 in main () at ./seg.c:4/
>
> When I try to read the core dump created by valgrind, gdb is unable to 
> read it
> /warning: Couldn't find general-purpose registers in core file.//
> //
> //warning: Could not load shared library symbols for 5 libraries, e.g. 
> /bin/valgrind/lib/valgrind/vgpreload_core-mips32-linux.so.//
> //Use the "info sharedlibrary" command to see the complete listing.//
> //Do you need "set solib-search-path" or "set sysroot"?//
> //Core was generated by `'.//
> //
> //warning: Couldn't find general-purpose registers in core file.//
> //../../gdb-7.3.1/gdb/frame-unwind.c:133: internal-error: 
> frame_unwind_find_by_frame failed//
> //A problem internal to GDB has been detected,//
> //further debugging may prove unreliable./
>
> Can you help me with this?
> P.S.
> cpu model: Broadcom BMIPS5000 V1.1  FPU V0.1
> valgrind-3.10.1
>
> -- 
> Sincerely
> Mikhail Baikov
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
>
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

-- 
Sincerely
Mikhail Baikov

Re: [Valgrind-users] Valgrind massif -- difference between time(B) and total(B) columns

[Milian W. <ma...@mi...>]

On Thursday, July 09, 2015 12:10:14 PM Anthony Haas wrote:
> Hi,
> 
> When running with valgrind massif with --time-unit=B option, how can the
> time(B) column value be so much larger than the total(B) column value?
> In this case at snapshot 35, I have a total of 119,461,400 but the
> time(B) is at more than 1GB. What does that mean? and where does it come
> from?

The time(B) just counts how much memory was requested in total, ignoring 
deallocations, and uses that for a "time" axis. The total(B) counts how much 
memory is currently being used, i.e. actually takes deallocations into 
account.

HTH
-- 
Milian Wolff
ma...@mi...
http://milianw.de

[Valgrind-users] Valgrind massif -- difference between time(B) and total(B) columns

[Anthony H. <ap...@em...>]

Hi,

When running with valgrind massif with --time-unit=B option, how can the 
time(B) column value be so much larger than the total(B) column value? 
In this case at snapshot 35, I have a total of 119,461,400 but the 
time(B) is at more than 1GB. What does that mean? and where does it come 
from?

Thanks,

Anthony




--------------------------------------------------------------------------------
   n        time(B)         total(B)   useful-heap(B) extra-heap(B)    
stacks(B)
--------------------------------------------------------------------------------
  33  1,056,768,488       71,575,048       71,518,410 56,638            0
  34  1,083,961,928       98,768,488       98,709,838 58,650            0
  35  1,105,439,944      119,461,400      119,397,314 64,086            0

[Valgrind-users] Help:strange compiling error when cross compiling valgrind for android with cygwin

[Yanli Z. <yan...@gm...>]

Hi All,
I'm quite new to Valgrind. Now I'm trying to cross compile valgrind for
android with cygwin. But I got a strange error as:

make[3]: Entering directory
`E:/thirdParty/valgrind/valgrind-3.10.1/coregrind'
E:/ogs/external/AndroidNDK/r9b/Win32/toolchains/arm-linux-androideabi-4.8/prebuilt/windows/bin/arm-linux-androideabi-gcc.exe
-DHAVE_CONFIG_H -I. -I..  -I.. -I../include -I../VEX/pub -I../VEX/pub
-DVGA_arm=1 -DVGO_linux=1 -DVGP_arm_linux=1 -DVGPV_arm_linux_android=1
-I../coregrind -DVG_LIBDIR="\"/data/local/Inst/lib/valgrind"\"
-DVG_PLATFORM="\"arm-linux\""
--sysroot=E:/ogs/external/AndroidNDK/r9b/Win32/platforms/android-18/arch-arm
-DANDROID_HARDWARE_generic -O2 -g -Wall -Wmissing-prototypes -Wshadow
-Wpointer-arith -Wstrict-prototypes -Wmissing-declarations
-Wno-format-zero-length -fno-strict-aliasing -fno-builtin -marm
-mcpu=cortex-a8 -DENABLE_LINUX_TICKET_LOCK -Wno-long-long
--sysroot=E:/ogs/external/AndroidNDK/r9b/Win32/platforms/android-18/arch-arm
-fno-stack-protector -MT libcoregrind_arm_linux_a-m_libcproc.o -MD -MP -MF
.deps/libcoregrind_arm_linux_a-m_libcproc.Tpo -c -o
libcoregrind_arm_linux_a-m_libcproc.o `test -f 'm_libcproc.c' || echo
'./'`m_libcproc.c
m_libcproc.c:66:1: error: stray '\' in program
 const HChar *VG_(libdir) = VG_LIBDIR;
 ^
m_libcproc.c:66:1: error: stray '\' in program
<command-line>:0:13: error: expected expression before '/' token
m_libcproc.c:66:28: note: in expansion of macro 'VG_LIBDIR'
 const HChar *VG_(libdir) = VG_LIBDIR;
                            ^
<command-line>:0:13: error: stray '\' in program
m_libcproc.c:66:28: note: in expansion of macro 'VG_LIBDIR'
 const HChar *VG_(libdir) = VG_LIBDIR;
                            ^
<command-line>:0:13: error: stray '\' in program
m_libcproc.c:66:28: note: in expansion of macro 'VG_LIBDIR'
 const HChar *VG_(libdir) = VG_LIBDIR;
                            ^
make[3]: *** [libcoregrind_arm_linux_a-m_libcproc.o] Error 1


m_libcproc.c is definitely downloaded from valgrind.org and not changed.
line 65: /* Path to library directory */
line 66: const HChar *VG_(libdir) = VG_LIBDIR;

I didnot get much helpful info from google. So PLS HELP. Thx.


Regards,
Apple

[Valgrind-users] Valgrind doesn't create readable core dumps

[Mikhail B. <mik...@de...>]

Hello

I've got a problem while reading dumps created by valgrind. I've 
compiled and run this code with valgrind and without it.
/int main()//
//{//
//    const char *str = "segfault";//
//    *(char *)str = 'a';//
//    return 1;//
//}
/

When I read the system created core dump it's readable
/Core was generated by `./seg'.//
//Program terminated with signal 11, Segmentation fault.//
//#0  0x004006d0 in main () at ./seg.c:4/

When I try to read the core dump created by valgrind, gdb is unable to 
read it
/warning: Couldn't find general-purpose registers in core file.//
//
//warning: Could not load shared library symbols for 5 libraries, e.g. 
/bin/valgrind/lib/valgrind/vgpreload_core-mips32-linux.so.//
//Use the "info sharedlibrary" command to see the complete listing.//
//Do you need "set solib-search-path" or "set sysroot"?//
//Core was generated by `'.//
//
//warning: Couldn't find general-purpose registers in core file.//
//../../gdb-7.3.1/gdb/frame-unwind.c:133: internal-error: 
frame_unwind_find_by_frame failed//
//A problem internal to GDB has been detected,//
//further debugging may prove unreliable./

Can you help me with this?
P.S.
cpu model: Broadcom BMIPS5000 V1.1  FPU V0.1
valgrind-3.10.1

-- 
Sincerely
Mikhail Baikov

Re: [Valgrind-users] Help Needed !

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

>   ./configure --target=arm-none-eabi --host=x86_64-linux CC=~/gcc/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-gcc

> checking for x86_64-linux-gcc... /home/pinkesh/gcc/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-gcc
> checking whether the C compiler works... no
> configure: error: in `/home/pinkesh/installs/valgrind-3.10.1':
> configure: error: C compiler cannot create executables
> See `config.log' for more details

Well, what does config.log say?

Does running the shell command:
     /home/pinkesh/gcc/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-gcc -o hello hello.c
produce a file 'hello' which is an executable for arm-none-eabi?

If more information is needed, then diagnose with strace, such as:
     strace -f -e trace=execve -v -s 300 \
         ./configure --target=arm-none-eabi --host=x86_64-linux \
         CC=~/gcc/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-gcc

-- 

Re: [Valgrind-users] Is a list of the values assigned to tmp variables maintained some where accessible?

[yixiaoxian <yix...@gm...>]

t0, t1 or t2 are temporaries, which are UInt in type. How to get their value
of some point of execution? If just pass them to instrument functions, we
get only the temporary numbers, but the values at runtime.



--
View this message in context: http://valgrind.10908.n7.nabble.com/Is-a-list-of-the-values-assigned-to-tmp-variables-maintained-some-where-accessible-tp41345p55033.html
Sent from the Valgrind - Users mailing list archive at Nabble.com.

Re: [Valgrind-users] Help Needed !

[Alexander P. <gl...@go...>]

Apparently you're trying to use the cross-compiler targeting ARM as
the host compiler.
./configure is attempting to compile a small program with that
compiler and is unable to execute the resulting binary.
You need to look at ./configure source or the --help output to find
out how to supply different compilers for host and target.

On Thu, Jul 2, 2015 at 2:56 PM, Pinkesh Pachchigar <pin...@li...> wrote:
> Hello everyone ,
>
> I am novice to valgrind tool . I want to configure valgrind for ARM
> Cortex-m4 .
>
> My host system is x86_64 GNU/Linux ..
>
> and cross-compile toolchain is arm-none-eabi .
>
> Anyone ?
>
>  ./configure --target=arm-none-eabi --host=x86_64-linux
> CC=~/gcc/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-gcc
>
> configure: WARNING: if you wanted to set the --build type, don't use --host.
>     If a cross compiler is detected then cross compile mode will be used
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for x86_64-linux-strip... no
> checking for strip... strip
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... no
> checking for mawk... mawk
> checking whether make sets $(MAKE)... yes
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking whether ln -s works... yes
> checking for x86_64-linux-gcc...
> /home/pinkesh/gcc/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-gcc
> checking whether the C compiler works... no
> configure: error: in `/home/pinkesh/installs/valgrind-3.10.1':
> configure: error: C compiler cannot create executables
> See `config.log' for more details
>
> - Pinkesh
>
>
> ------------------------------------------------------------------------------
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud.com/
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>



-- 
Alexander Potapenko
Software Engineer

Google Germany GmbH
Dienerstraße 12
80331 München

[Valgrind-users] Help Needed !

[Pinkesh P. <pin...@li...>]

Hello everyone ,

I am novice to valgrind tool . I want to configure valgrind for ARM Cortex-m4 .

My host system is x86_64 GNU/Linux ..

and cross-compile toolchain is arm-none-eabi .

Anyone ?

 ./configure --target=arm-none-eabi --host=x86_64-linux CC=~/gcc/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-gcc 

configure: WARNING: if you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for x86_64-linux-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether ln -s works... yes
checking for x86_64-linux-gcc... /home/pinkesh/gcc/gcc-arm-none-eabi-4_9-2015q1/bin/arm-none-eabi-gcc
checking whether the C compiler works... no
configure: error: in `/home/pinkesh/installs/valgrind-3.10.1':
configure: error: C compiler cannot create executables
See `config.log' for more details

- Pinkesh

 		 	   		  

Re: [Valgrind-users] Documentation for callgrind text data file format?

[Josef W. <Jos...@gm...>]

Am 29.05.2015 um 19:14 schrieb Dan Liew:
> There's [1]. It's not complete though,

It should be complete now in SVN :-)

Josef

[Valgrind-users] reply： helgrind use more than 32G memory.

[王阳 <412...@qq...>]

Hi Philippe,


Thank you for your reply.
>Ok, the origin of the memory is related to the locks/nr of locks
>your application creates and/or locks/keeps locked.
>About 50Gb of memory is consumed for hg.ids.4.
What is the  hg.ids.4? Is it helgrind's memory using for analysing lock?
I know that a lock can not cost big memory, how many memory  does helgrind cost for analysing one lock?
It is unbelievable  that  helgrind will cost 50GB for 1,029,288 locks.




>From the above, I guess your application has thousands
>of locks, and that each thread has sometimes hundreds
>of locks held.Myprog have creates about 4096*64 locks, sometimes myprog will lock almost all the locks at one time, and release them later.


>There is no garbage collection of the lock set universe.
You mean the big memory allocated using for analysing locks can not be reused/recyled by  valgrind?




>At this point, I think there are 2 possible approaches:
>  * implement in helgrind a garbage collection of the univ_lsets
>    (unclear if this is implementable, and for sure not trivial)
>  * you change the limits of Valgrind max memory, to e.g. go
>    to 128G or 256G.
Both ways are so difficult for me, I am want to try the second way, but I need your your help.
Can you give me a patch for 3.10.1 to  change the limits of Valgrind max memory to 256G.Thanks.




> I have done it two times with different options series. The result is
> as follows:
> 1.--tool=helgrind --gen-suppressions=all --stats=yes
> --profile-heap=yes --track-lockorders=no --read-var-info=yes
> --trace-children=yes --error-limit=no --log-file=xxx.log myprog 
Ok, the origin of the memory is related to the locks/nr of locks
your application creates and/or locks/keeps locked.

About 50Gb of memory is consumed for hg.ids.4.
> 51,760,182,272 in   341,498: hg.ids.4
This is the 'universe of locksets' : ie. all the locksets that
helgrind has ever seen.
It looks like your application uses a lot of locks
and keeps a lot of locks in a status 'locked' shown by:
>           locks: 1,029,288 acquires, 915,546 releases
From the above, I guess your application has thousands
of locks, and that each thread has sometimes hundreds
of locks held.

Well, if that is the case, I think helgrind data structure
is not done for such a behaviour :(  
There is no garbage collection of the lock set universe.

At this point, I think there are 2 possible approaches:
  * implement in helgrind a garbage collection of the univ_lsets
    (unclear if this is implementable, and for sure not trivial)
  * you change the limits of Valgrind max memory, to e.g. go
    to 128G or 256G.
    You might refer for that to the revision r13278, which increased
    from 32G to 64G. That gives the various constants to multiply by 2
    or 4 to go to 128G or 256G.
    So, checkout the SVN version, then do
    svn diff -r13277:13278
    and follow that pattern to increase to 128 or 256G
    
Philippe