|
From: rafaelg <raf...@ya...> - 2007-01-26 17:31:05
|
Hi,
I am trying to run valgrind in an application that is being stressed and I
need it to be as much light as possible.
Up to now I am using the following configuration:
--tool=memcheck --num-callers=10 --error-limit=no
--log-socket=<SERV_IP>:35000 --suppressions=./default.supp
As the objective I have is to find the location of a double free (which gdb
can not determine because the stack trace is corrupted completely) I have
added some supressions to the default.supp which can be found at the end of
the message.
The problem, besides the application being slower, is that valgrind consumes
a lot of memory and the kernel kills it.
Is there any way for reducing the memory consumption and the CPU
utilization. Take into account that the application being checked must run
at least over a week being stressed!!!.
Thanks
Rafael.
SUPRESSIONS:
{
use of uninitialised value of size 4
Memcheck:Value4
fun:*
}
{
use of uninitialised value of size 1
Memcheck:Value1
fun:*
}
{
use of uninitialised value of size 2
Memcheck:Value2
fun:*
}
{
use of uninitialised value of size 8
Memcheck:Value8
fun:*
}
{
use of uninitialised value of size 16
Memcheck:Value16
fun:*
}
{
use of uninitialised value on condition
Memcheck:Cond
fun:*
}
{
Invalid system call parameter
Memcheck:Param
write(buf)
fun:*
}
{
Invalid system call parameter
Memcheck:Param
sched_getparam(p)
fun:*
}
{
Invalid system call parameter
Memcheck:Param
set_tid_address(tidptr)
fun:*
}
{
invalid write of size 1
Memcheck:Addr1
fun:*
}
{
invalid write of size 2
Memcheck:Addr2
fun:*
}
{
invalid write of size 4
Memcheck:Addr4
fun:*
}
{
invalid write of size 8
Memcheck:Addr8
fun:*
}
{
invalid write of size 16
Memcheck:Addr16
fun:*
}
--
View this message in context: http://www.nabble.com/Reduce-memory-consumption-tf3122305.html#a8651092
Sent from the Valgrind - Users mailing list archive at Nabble.com.
|
|
From: Ashley P. <as...@qu...> - 2007-01-26 19:13:26
|
On 26 Jan 2007, at 13:48, rafaelg wrote: > As the objective I have is to find the location of a double free > (which gdb > can not determine because the stack trace is corrupted completely) I > have > added some supressions to the default.supp which can be found at the > end of > the message. Nothing to do with Valgrind but I've found the libc environment variable _MALLOC_CHECK=3 helpful in situations like this. There is documentation for this online. Also try using the debug version of libc if your distribution packages one. Ashley, |
|
From: Rafael G. <raf...@ya...> - 2007-01-26 20:16:28
|
Hi Ashley,
Thanks for your response. That _MALLOC_CHECK variable captured my attention. I looked for it through google but I could not find much infomation. Where is that documentation you said?
Thanks again,
Rafael.
Ashley Pittman <as...@qu...> wrote: On 26 Jan 2007, at 13:48, rafaelg wrote:
> As the objective I have is to find the location of a double free
> (which gdb
> can not determine because the stack trace is corrupted completely) I
> have
> added some supressions to the default.supp which can be found at the
> end of
> the message.
Nothing to do with Valgrind but I've found the libc environment
variable _MALLOC_CHECK=3 helpful in situations like this. There is
documentation for this online. Also try using the debug version of
libc if your distribution packages one.
Ashley,
---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta. |
|
From: Ashley P. <as...@qu...> - 2007-01-27 11:29:11
|
Sorry, my mistake, it's MALLOC_CHECK_=3D2 http://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-=20 Checking.html Ashley, On 26 Jan 2007, at 20:16, Rafael Garabato wrote: > Hi Ashley, > =A0 > =A0=A0=A0=A0 Thanks for your response. That _MALLOC_CHECK variable = captured my =20 > attention. I looked for it through google but I could not find much =20= > infomation. Where is that documentation you said? > > Thanks again, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Rafael. > > Ashley Pittman <as...@qu...> wrote: >> > As the objective I have is to find the location of a double free >> > (which gdb >> > can not determine because the stack trace is corrupted completely) = I >> > have >> > added some supressions to the default.supp which can be found at = the >> > end of >> > the message. >> >> Nothing to do with Valgrind but I've found the libc environment >> variable _MALLOC_CHECK=3D3 helpful in situations like this. There is >> documentation for this online. Also try using the debug version of >> libc if your distribution packages one. >> >> Ashley, >> > > Everyone is raving about the all-new Yahoo! Mail beta.= |
rafaelg wrote: [snip] > As the objective I have is to find the location of a double free (which gdb > can not determine because the stack trace is corrupted completely) I have > added some supressions to the default.supp which can be found at the end of > the message. > > The problem, besides the application being slower, is that valgrind consumes > a lot of memory and the kernel kills it. Looking at your added SUPPRESSIONS, you have chosen to ignore these *serious* errors everywhere ["fun:*"]: > use of uninitialised value of size 4 > use of uninitialised value of size 1 > use of uninitialised value of size 2 > use of uninitialised value of size 8 > use of uninitialised value of size 16 > use of uninitialised value on condition > invalid write of size 1 > invalid write of size 2 > invalid write of size 4 > invalid write of size 8 > invalid write of size 16 If you really need those suppressions, then the execution of the application is total garbage. The output of the application should not be trusted *AT ALL*. Fix the above errors first [or show that they correspond to bugs in memcheck]. -- |
|
From: Rafael G. <raf...@ya...> - 2007-01-26 20:08:47
|
The problem is that I must focus first on the double free. On the other hand, the errors are from the libc, so I shouldn't be fixing that.
Thanks,
Rafael.
John Reiser <jreiser@BitWagon.com> wrote: rafaelg wrote:
[snip]
> As the objective I have is to find the location of a double free (which gdb
> can not determine because the stack trace is corrupted completely) I have
> added some supressions to the default.supp which can be found at the end of
> the message.
>
> The problem, besides the application being slower, is that valgrind consumes
> a lot of memory and the kernel kills it.
Looking at your added SUPPRESSIONS, you have chosen to ignore these
*serious* errors everywhere ["fun:*"]:
> use of uninitialised value of size 4
> use of uninitialised value of size 1
> use of uninitialised value of size 2
> use of uninitialised value of size 8
> use of uninitialised value of size 16
> use of uninitialised value on condition
> invalid write of size 1
> invalid write of size 2
> invalid write of size 4
> invalid write of size 8
> invalid write of size 16
If you really need those suppressions, then the execution of the
application is total garbage. The output of the application
should not be trusted *AT ALL*. Fix the above errors first
[or show that they correspond to bugs in memcheck].
--
---------------------------------
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar. |
John Reiser wrote: > Looking at your added SUPPRESSIONS, you have chosen to ignore these > *serious* errors everywhere ["fun:*"]: > >> use of uninitialised value of size 4 ... Rafael Garabato wrote: > The problem is that I must focus first on the double free. Please explain why the double free must come first. In the absence of any explanation, then it makes more sense to fix the first complaint first, particularly because the double free might be caused by such earlier errors. Also, the Suppressions you have given, which ignore errors *everywhere*, suggest that the application is so bad that only its maintainer should even bother looking at it. > On the other hand, the errors are from the libc, so I shouldn't be fixing that. I have already fixed several dozen memory access errors in glibc; these include all of the default memcheck suppressions for glibc, plus others. See http://bitwagon.com/glibc-audit/glibc-audit.html for details, including pre-compiled binary .rpm packages for i686, x86_64, and ppc. Today I added glibc-2.5-10; previous versions include 2.4-4, 2.3.90-30, etc. -- |
|
From: Nicholas N. <nj...@cs...> - 2007-01-27 02:35:44
|
On Fri, 26 Jan 2007, rafaelg wrote: > The problem, besides the application being slower, is that valgrind consumes > a lot of memory and the kernel kills it. > Is there any way for reducing the memory consumption and the CPU > utilization. Take into account that the application being checked must run > at least over a week being stressed!!!. If you use --undef-value-errors=no it will run a bit faster, although the memory usage will be the same. Nick |