|
From: Christophe L. <chr...@st...> - 2012-08-01 07:59:03
|
Hello, I have been using valgrind --leak-check=yes on an ARM-Cortex-A9 board to debug an application (based on gstreamer), and find it much slower when the board is booted in SMP mode than it UP mode. I takes about 20 minutes before it detects an error: ==1393== Invalid read of size 1 ==1393== at 0x4831E64: strncmp (mc_replace_strmem.c:534) ==1393== by 0x5EB1923: pixman_arm_read_auxv (in /usr/lib/libpixman-1.so.0.22.2) After that, execution is about as fast as in UP mode. Is there any difference in the beginning stage of valgrind between SMP and UP modes? Using the 'top' command shows that the system is busy at the memcheck-arm-li process. Where can I look at to isolate the problem? Thanks! Christophe. |
|
From: Alexander P. <gl...@go...> - 2012-08-01 08:30:16
|
How about dumping the IR to see how much instructions are actually being translated in both modes? The problem might be related to the memory barriers implemented (if I remember correctly) with MCR instructions in the userspace __kernel_dmb() (and maybe other) functions present in the SMP mode. On Wed, Aug 1, 2012 at 11:38 AM, Christophe Lyon <chr...@st...> wrote: > Hello, > > I have been using valgrind --leak-check=yes on an ARM-Cortex-A9 board to debug an application (based on gstreamer), and find it much slower when the board is booted in SMP mode than it UP mode. > > I takes about 20 minutes before it detects an error: > > ==1393== Invalid read of size 1 > ==1393== at 0x4831E64: strncmp (mc_replace_strmem.c:534) > ==1393== by 0x5EB1923: pixman_arm_read_auxv (in > /usr/lib/libpixman-1.so.0.22.2) > > After that, execution is about as fast as in UP mode. > > Is there any difference in the beginning stage of valgrind between SMP and UP modes? > Using the 'top' command shows that the system is busy at the memcheck-arm-li process. > > Where can I look at to isolate the problem? > > Thanks! > > Christophe. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users -- Alexander Potapenko Software Engineer Google Moscow |
|
From: Julian S. <js...@ac...> - 2012-08-01 08:53:18
|
> > Where can I look at to isolate the problem? Try --profile-flags=10000000 to get a profile of the hottest blocks in the application. This might give some clue as to what is going on. J |
|
From: Christophe L. <chr...@st...> - 2012-08-01 08:49:51
|
Thanks for the hint... and sorry for the simple question: how do I dump IR to see what you suggest? On 01.08.2012 10:30, Alexander Potapenko wrote: > How about dumping the IR to see how much instructions are actually > being translated in both modes? > The problem might be related to the memory barriers implemented (if I > remember correctly) with MCR instructions in the userspace > __kernel_dmb() (and maybe other) functions present in the SMP mode. > > On Wed, Aug 1, 2012 at 11:38 AM, Christophe Lyon <chr...@st...> wrote: >> Hello, >> >> I have been using valgrind --leak-check=yes on an ARM-Cortex-A9 board to debug an application (based on gstreamer), and find it much slower when the board is booted in SMP mode than it UP mode. >> >> I takes about 20 minutes before it detects an error: >> >> ==1393== Invalid read of size 1 >> ==1393== at 0x4831E64: strncmp (mc_replace_strmem.c:534) >> ==1393== by 0x5EB1923: pixman_arm_read_auxv (in >> /usr/lib/libpixman-1.so.0.22.2) >> >> After that, execution is about as fast as in UP mode. >> >> Is there any difference in the beginning stage of valgrind between SMP and UP modes? >> Using the 'top' command shows that the system is busy at the memcheck-arm-li process. >> >> Where can I look at to isolate the problem? >> >> Thanks! >> >> Christophe. >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Valgrind-users mailing list >> Val...@li... >> https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |
|
From: Alexander P. <gl...@go...> - 2012-08-01 08:56:59
|
What Julian said. --help-debug will give you some other useful flags. I was talking about --trace-notbelow and --trace-flags, but --profile-flags is even better. On Wed, Aug 1, 2012 at 12:49 PM, Christophe Lyon <chr...@st...> wrote: > Thanks for the hint... and sorry for the simple question: how do I dump IR > to see what you suggest? > > > > On 01.08.2012 10:30, Alexander Potapenko wrote: >> >> How about dumping the IR to see how much instructions are actually >> being translated in both modes? >> The problem might be related to the memory barriers implemented (if I >> remember correctly) with MCR instructions in the userspace >> __kernel_dmb() (and maybe other) functions present in the SMP mode. >> >> On Wed, Aug 1, 2012 at 11:38 AM, Christophe Lyon <chr...@st...> >> wrote: >>> >>> Hello, >>> >>> I have been using valgrind --leak-check=yes on an ARM-Cortex-A9 board to >>> debug an application (based on gstreamer), and find it much slower when the >>> board is booted in SMP mode than it UP mode. >>> >>> I takes about 20 minutes before it detects an error: >>> >>> ==1393== Invalid read of size 1 >>> ==1393== at 0x4831E64: strncmp (mc_replace_strmem.c:534) >>> ==1393== by 0x5EB1923: pixman_arm_read_auxv (in >>> /usr/lib/libpixman-1.so.0.22.2) >>> >>> After that, execution is about as fast as in UP mode. >>> >>> Is there any difference in the beginning stage of valgrind between SMP >>> and UP modes? >>> Using the 'top' command shows that the system is busy at the >>> memcheck-arm-li process. >>> >>> Where can I look at to isolate the problem? >>> >>> Thanks! >>> >>> Christophe. >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Valgrind-users mailing list >>> Val...@li... >>> https://lists.sourceforge.net/lists/listinfo/valgrind-users >> >> >> > -- Alexander Potapenko Software Engineer Google Moscow |