|
From: Sanders, R. M. <san...@za...> - 2007-05-17 14:31:44
|
Hello all,
I'm having a problem getting valgrind (3.2.3) to invoke a debugger=20
when it encounters a problem. I'm running a pretty much stock RHES4 =
rel3
system with valgrind 3.2.3 My test program is dirt simple:
=3D=3D=3D
#include <stdio.h>
int main()
{
int a;
printf("A is %d\n",a);
}
=3D=3D=3D
Compiled by:
cc -g testprog.c -o testprog
valgrind invoked by:
valgrind --leak-check=3Dfull --show-reachable=3Dyes --verbose =
--db-attach=3Dyes --db-command=3D"ddd %f %p" testprog
Valgrind correctly detects the unitialized variable a and asks to start =
a debugger session. When I respond 'y'
it invokes ddd, which correctly loads the testprog. The problem is that =
the stack being reported at that point is
totally bogus.
Related or not, if I have an abort() statement in the code valgrind =
shows the same garbled stack. If I use ddd to
pull up the core file produced by the abort(), all is well.
I have noticed that ddd shows many more libraries being opened when =
invoked from the commandline on the core file as opposed to
being invoked directly from valgrind.
=20
Any suggestions?
Rob
|
|
From: Sanders, R. M. <san...@za...> - 2007-05-17 14:31:45
|
Hello all,
I'm having a problem getting valgrind (3.2.3) to invoke a debugger=20
when it encounters a problem. I'm running a pretty much stock RHES4 =
rel3
system with valgrind 3.2.3 My test program is dirt simple:
=3D=3D=3D
#include <stdio.h>
int main()
{
int a;
printf("A is %d\n",a);
}
=3D=3D=3D
Compiled by:
cc -g testprog.c -o testprog
valgrind invoked by:
valgrind --leak-check=3Dfull --show-reachable=3Dyes --verbose =
--db-attach=3Dyes --db-command=3D"ddd %f %p" testprog
Valgrind correctly detects the unitialized variable a and asks to start =
a debugger session. When I respond 'y'
it invokes ddd, which correctly loads the testprog. The problem is that =
the stack being reported at that point is
totally bogus.
Related or not, if I have an abort() statement in the code valgrind =
shows the same garbled stack. If I use ddd to
pull up the core file produced by the abort(), all is well.
I have noticed that ddd shows many more libraries being opened when =
invoked from the commandline on the core file as opposed to
being invoked directly from valgrind.
=20
Any suggestions?
Rob
|
|
From: Julian S. <js...@ac...> - 2007-05-17 14:43:07
|
> the testprog. The problem is that the stack being reported at that point > is totally bogus. Send both the backtrace from ddd and also the error message that Valgrind prints. J |
|
From: Sanders, R. M. <san...@za...> - 2007-05-17 16:33:48
|
Ok, solution found. My version of gdb (v 6.3.0.0-1.132.EL4rh) doesn't =
work when
invoked from valgrind. I downloaded the version 6.6 and compiled it and =
now
things work correctly. =20
Back to debugging.....
Rob
-----Original Message-----
From: val...@li... on behalf of Sanders, =
Rob M.
Sent: Thu 5/17/2007 10:31 AM
To: val...@li...
Subject: [Valgrind-users] Using valgrind with debuggers
=20
Hello all,
I'm having a problem getting valgrind (3.2.3) to invoke a debugger=20
when it encounters a problem. I'm running a pretty much stock RHES4 =
rel3
system with valgrind 3.2.3 My test program is dirt simple:
=3D=3D=3D
#include <stdio.h>
int main()
{
int a;
printf("A is %d\n",a);
}
=3D=3D=3D
Compiled by:
cc -g testprog.c -o testprog
valgrind invoked by:
valgrind --leak-check=3Dfull --show-reachable=3Dyes --verbose =
--db-attach=3Dyes --db-command=3D"ddd %f %p" testprog
Valgrind correctly detects the unitialized variable a and asks to start =
a debugger session. When I respond 'y'
it invokes ddd, which correctly loads the testprog. The problem is that =
the stack being reported at that point is
totally bogus.
Related or not, if I have an abort() statement in the code valgrind =
shows the same garbled stack. If I use ddd to
pull up the core file produced by the abort(), all is well.
I have noticed that ddd shows many more libraries being opened when =
invoked from the commandline on the core file as opposed to
being invoked directly from valgrind.
=20
Any suggestions?
Rob
-------------------------------------------------------------------------=
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Valgrind-users mailing list
Val...@li...
https://lists.sourceforge.net/lists/listinfo/valgrind-users
|