|
From: Bob R. <bo...@br...> - 2004-09-30 18:40:28
|
Hi, I am running valgrind $ valgrind --version valgrind-2.2.0 and for some reason during startup valgrind hangs. At one my point valgrind was processing my application fine. This was with version 2.0.0. Then when I went to upgrade to 2.1.2 I noticed the problem that valgrind would hang on startup. I decided not to upgrade. Now I noticed valgrind is still hanging, however, this time it has some obscure error messages. A posting of the output is below. After about 1 minute, I killed valgrind. Any suggestions? I would greatly like to get a new version of valgrind working. Thanks, Bob Rossi $ valgrind -v --tool=corecheck /home/BONO/bar/cvs/ptr_to_uncon/vectors/build-platform/Linux/vectorcast_dir/.real/enviroedg-bin uut.env ==1165== Coregrind, a rudimentary error detector for x86-linux. ==1165== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==1165== Using valgrind-2.2.0, a program supervision framework for x86-linux. ==1165== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==1165== Valgrind library directory: /home/TOOLS/valgrind-2.2.0-1/lib/valgrind ==1165== Command line ==1165== /home/BONO/bar/cvs/ptr_to_uncon/vectors/build-platform/Linux/vectorcast_dir/.real/enviroedg-bin ==1165== uut.env ==1165== Startup, with flags: ==1165== -v ==1165== --tool=corecheck ==1165== Contents of /proc/version: ==1165== Linux version 2.4.20-19.7smp (bhc...@po...) (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113)) #1 SMP Tue Jul 15 13:34:04 EDT 2003 ==1165== Reading syms from /home/BONO/bar/cvs/ptr_to_uncon/vectors/build-platform/Linux/vectorcast_dir/.real/enviroedg-bin (0x8048000) @@ unlikely looking definition in unparsed remains ";"k @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" @@ unlikely looking definition in unparsed remains ";" |
|
From: Tom H. <th...@cy...> - 2004-09-30 20:06:58
|
In message <20040930184019.GB2271@white>
Bob Rossi <bo...@br...> wrote:
> At one my point valgrind was processing my application fine. This was
> with version 2.0.0. Then when I went to upgrade to 2.1.2 I noticed the
> problem that valgrind would hang on startup. I decided not to upgrade.
> Now I noticed valgrind is still hanging, however, this time it has some
> obscure error messages. A posting of the output is below.
Those errors can safely be ignored - they are fixed in the CVS code.
> After about 1 minute, I killed valgrind. Any suggestions? I would
> greatly like to get a new version of valgrind working.
Well we're going to need to know more about what your application
is going when it hangs, or get a test case or something.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-09-30 20:29:11
|
On Thu, Sep 30, 2004 at 09:07:01PM +0100, Tom Hughes wrote: > In message <20040930184019.GB2271@white> > Bob Rossi <bo...@br...> wrote: > > > At one my point valgrind was processing my application fine. This was > > with version 2.0.0. Then when I went to upgrade to 2.1.2 I noticed the > > problem that valgrind would hang on startup. I decided not to upgrade. > > Now I noticed valgrind is still hanging, however, this time it has some > > obscure error messages. A posting of the output is below. > > Those errors can safely be ignored - they are fixed in the CVS code. > > > After about 1 minute, I killed valgrind. Any suggestions? I would > > greatly like to get a new version of valgrind working. > > Well we're going to need to know more about what your application > is going when it hangs, or get a test case or something. Could you please expand on exactly what it is you need to know. I don't think my program ever even get's started. I modified it to have a 'fprintf ( stderr, "test\n" );' as the first line of the program and I never see it when I run valgrind. Thanks, Bob Rossi |
|
From: Tom H. <th...@cy...> - 2004-09-30 22:44:07
|
In message <20040930202902.GD2271@white>
Bob Rossi <bo...@br...> wrote:
> Could you please expand on exactly what it is you need to know. I don't
> think my program ever even get's started.
>
> I modified it to have a 'fprintf ( stderr, "test\n" );' as the first
> line of the program and I never see it when I run valgrind.
Could be a problem reading the debug info or something then. We had
a case recently where that could cause a hang.
Are you using stabs or DWARF debugging info? Do you have your program
compiled for debugging? Is it C code or something else?
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-09-30 22:57:11
|
On Thu, Sep 30, 2004 at 11:44:16PM +0100, Tom Hughes wrote: > In message <20040930202902.GD2271@white> > Bob Rossi <bo...@br...> wrote: > > > Could you please expand on exactly what it is you need to know. I don't > > think my program ever even get's started. > > > > I modified it to have a 'fprintf ( stderr, "test\n" );' as the first > > line of the program and I never see it when I run valgrind. > > Could be a problem reading the debug info or something then. We had > a case recently where that could cause a hang. > > Are you using stabs or DWARF debugging info? The program consists of C, C++ and Ada. We are using GNU's gcc version 2.96 and for C and C++. We are using GNAT's gcc version 2.8.1 for ADA. I don't know a definitive way to tell you what debug formats my executable is made up of, however, I can tell you that the majority of it is in stabs. > Do you have your program compiled for debugging? Yes, the program is definatly compiled with debug. This might be some proof. $ file /home/BONO/bar/cvs/ptr_to_uncon/vectors/build-platform/Linux/vectorcast_dir/.real/enviroedg-bin /home/BONO/bar/cvs/ptr_to_uncon/vectors/build-platform/Linux/vectorcast_dir/.real/enviroedg-bin: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped > Is it C code or something else? It consists of C, C++ and ADA. What else can I do to help out? I really can't live much longer without valgrind :) Thanks, Bob Rossi |
|
From: Tom H. <th...@cy...> - 2004-09-30 23:20:25
|
In message <20040930225703.GA3203@white>
Bob Rossi <bo...@br...> wrote:
> > Is it C code or something else?
>
> It consists of C, C++ and ADA.
It's probablt the ADA code. There is at least one bug relating to
problems reading the debug information generated by GNAT. I did fix
one bug, so you might like to try the CVS code, but I think there is
another bug open now.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-10-01 13:28:38
|
On Fri, Oct 01, 2004 at 12:20:24AM +0100, Tom Hughes wrote: > In message <20040930225703.GA3203@white> > Bob Rossi <bo...@br...> wrote: > > > > Is it C code or something else? > > > > It consists of C, C++ and ADA. > > It's probablt the ADA code. There is at least one bug relating to > problems reading the debug information generated by GNAT. I did fix > one bug, so you might like to try the CVS code, but I think there is > another bug open now. It works when there is no debug info at all. Both the latest release and CVS hang when there is debug info. Wonder what the next step is... Thanks, Bob Rossi |
|
From: Bob R. <bo...@br...> - 2004-10-01 15:05:17
|
On Fri, Oct 01, 2004 at 09:28:20AM -0400, Bob Rossi wrote: > On Fri, Oct 01, 2004 at 12:20:24AM +0100, Tom Hughes wrote: > > In message <20040930225703.GA3203@white> > > Bob Rossi <bo...@br...> wrote: > > > > > > Is it C code or something else? > > > > > > It consists of C, C++ and ADA. > > > > It's probablt the ADA code. There is at least one bug relating to > > problems reading the debug information generated by GNAT. I did fix > > one bug, so you might like to try the CVS code, but I think there is > > another bug open now. > > It works when there is no debug info at all. Both the latest release and > CVS hang when there is debug info. Wonder what the next step is... OK, I have an update on the status of things. I got the latest valgrind from CVS. $ valgrind --version valgrind-2.3.0.CVS With my mostly ADA application, I have reduced the problem. I have compiled my application without any debug support. The whole thing. However, if I use the 'file' command, it still isn't stripped. So I guess there is some normal amount of debug support that goes into an application even when '-g' is not used. So, with my program compiled without '-g' valgrind hangs, when I strip the program, valgrind works. What next? Thanks, Bob Rossi |
|
From: Bob R. <bo...@br...> - 2004-10-01 15:13:59
|
On Fri, Oct 01, 2004 at 11:04:59AM -0400, Bob Rossi wrote: > On Fri, Oct 01, 2004 at 09:28:20AM -0400, Bob Rossi wrote: > > On Fri, Oct 01, 2004 at 12:20:24AM +0100, Tom Hughes wrote: > > > In message <20040930225703.GA3203@white> > > > Bob Rossi <bo...@br...> wrote: > > > > > > > > Is it C code or something else? > > > > > > > > It consists of C, C++ and ADA. > > > > > > It's probablt the ADA code. There is at least one bug relating to > > > problems reading the debug information generated by GNAT. I did fix > > > one bug, so you might like to try the CVS code, but I think there is > > > another bug open now. > > > > It works when there is no debug info at all. Both the latest release and > > CVS hang when there is debug info. Wonder what the next step is... > > OK, I have an update on the status of things. I got the latest valgrind > from CVS. > $ valgrind --version > valgrind-2.3.0.CVS > > With my mostly ADA application, I have reduced the problem. I have > compiled my application without any debug support. The whole thing. > However, if I use the 'file' command, it still isn't stripped. So I > guess there is some normal amount of debug support that goes into an > application even when '-g' is not used. > > So, with my program compiled without '-g' valgrind hangs, when I strip > the program, valgrind works. > > What next? Finally, I have something reproducable :) I am very embarrassed that I didn't come up with this code segment before I went through all the pain I've gone through. This code simply doesn't work in my environment, even with the latest version of valgrind. bar@bono ~/tmp/tmp $ ls foo.adb bar@bono ~/tmp/tmp $ /home/GNAT/gnat/bin/gnatmake foo gcc -c foo.adb gnatbind -x foo.ali gnatlink foo.ali /home/GNAT/gnat/lib/gcc-lib/i686-pc-linux-gnu/2.8.1/adalib/libgnat.a(a-adaint.o): In function `__gnat_tmp_name': a-adaint.o(.text+0x504): the use of `tmpnam' is dangerous, better use `mkstemp' bar@bono ~/tmp/tmp $ valgrind --version valgrind-2.3.0.CVS bar@bono ~/tmp/tmp $ valgrind --tool=corecheck foo ==26534== Coregrind, a rudimentary error detector for x86-linux. ==26534== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==26534== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==26534== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. and valgrind never returns. What can be done to fix this problem? $ cat foo.adb with Text_IO; procedure foo is begin Text_Io.Put_Line ( "Hello World" ); end foo; $ valgrind --version valgrind-2.3.0.CVS $ /home/GNAT/gnat/bin/gcc --version 2.8.1 Could someone else please try to reproduce this problem? Maybe something is wrong with my environment. Here is a transcript of it working after the strip, bar@bono ~/tmp/tmp $ ls foo foo.adb foo.ali foo.o bar@bono ~/tmp/tmp $ strip foo bar@bono ~/tmp/tmp $ valgrind --tool=corecheck foo ==26560== Coregrind, a rudimentary error detector for x86-linux. ==26560== Copyright (C) 2002-2004, and GNU GPL'd, by Nicholas Nethercote. ==26560== Using valgrind-2.3.0.CVS, a program supervision framework for x86-linux. ==26560== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al. ==26560== For more details, rerun with: -v ==26560== Hello World ==26560== ==26560== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) bar@bono ~/tmp/tmp Thanks, Bob Rossi |
|
From: Naveen K. <g_n...@ya...> - 2004-10-01 16:09:06
|
I had a similar problem. I turned on debug in many of the stab functions[vg_stabs.c] and figured out that it was spinning in an infinite loop in one place. See my earlier post to this group regarding this. http://sourceforge.net/mailarchive/message.php?msg_id=9532982 Maybe it might help. Naveen --- Bob Rossi <bo...@br...> wrote: > Hi, > > I am running valgrind > $ valgrind --version > valgrind-2.2.0 > and for some reason during startup valgrind hangs. > > At one my point valgrind was processing my > application fine. This was > with version 2.0.0. Then when I went to upgrade to > 2.1.2 I noticed the > problem that valgrind would hang on startup. I > decided not to upgrade. > Now I noticed valgrind is still hanging, however, > this time it has some > obscure error messages. A posting of the output is > below. > > After about 1 minute, I killed valgrind. Any > suggestions? I would > greatly like to get a new version of valgrind > working. > > Thanks, > Bob Rossi > > $ valgrind -v --tool=corecheck > /home/BONO/bar/cvs/ptr_to_uncon/vectors/build-platform/Linux/vectorcast_dir/.real/enviroedg-bin > uut.env > ==1165== Coregrind, a rudimentary error detector for > x86-linux. > ==1165== Copyright (C) 2002-2004, and GNU GPL'd, by > Nicholas Nethercote. > ==1165== Using valgrind-2.2.0, a program supervision > framework for x86-linux. > ==1165== Copyright (C) 2000-2004, and GNU GPL'd, by > Julian Seward et al. > ==1165== Valgrind library directory: > /home/TOOLS/valgrind-2.2.0-1/lib/valgrind > ==1165== Command line > ==1165== > /home/BONO/bar/cvs/ptr_to_uncon/vectors/build-platform/Linux/vectorcast_dir/.real/enviroedg-bin > ==1165== uut.env > ==1165== Startup, with flags: > ==1165== -v > ==1165== --tool=corecheck > ==1165== Contents of /proc/version: > ==1165== Linux version 2.4.20-19.7smp > (bhc...@po...) (gcc version 2.96 > 20000731 (Red Hat Linux 7.3 2.96-113)) #1 SMP Tue > Jul 15 13:34:04 EDT 2003 > ==1165== Reading syms from > /home/BONO/bar/cvs/ptr_to_uncon/vectors/build-platform/Linux/vectorcast_dir/.real/enviroedg-bin > (0x8048000) > @@ unlikely looking definition in unparsed remains > ";"k > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > @@ unlikely looking definition in unparsed remains > ";" > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: IT Product Guide > on ITManagersJournal > Use IT products in your business? Tell us what you > think of them. Give us > Your Opinions, Get Free ThinkGeek Gift Certificates! > Click to find out more > http://productguide.itmanagersjournal.com/guidepromo.tmpl > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Bob R. <bo...@br...> - 2004-10-04 13:23:48
|
On Fri, Oct 01, 2004 at 09:08:59AM -0700, Naveen Kumar wrote: > I had a similar problem. I turned on debug in many of > the stab functions[vg_stabs.c] and figured out that it > was spinning in an infinite loop in one place. See my > earlier post to this group regarding this. > > http://sourceforge.net/mailarchive/message.php?msg_id=9532982 > > Maybe it might help. This seems like a good idea. I am having trouble debugging valgrind. Is there something special that needs to be done to debug valgrind? Thanks, Bob Rossi |
|
From: Naveen K. <g_n...@ya...> - 2004-10-04 14:34:23
|
Usually most funtions have a static const Bool debug = False; set that to True and recompile valgrind. That should do the trick. There is no one way to do this. Just experiment with turning on debug in different parts of the code. After you get a feel for the execution path of the code you can narrow down your problems to one or two files(in my case vg_stabs.c). Turn on debug in that and add some VG_(printf) code in places where you think there might be problems. That should help you pinpoint the problem. Naveen --- Bob Rossi <bo...@br...> wrote: > On Fri, Oct 01, 2004 at 09:08:59AM -0700, Naveen > Kumar wrote: > > I had a similar problem. I turned on debug in many > of > > the stab functions[vg_stabs.c] and figured out > that it > > was spinning in an infinite loop in one place. See > my > > earlier post to this group regarding this. > > > > > http://sourceforge.net/mailarchive/message.php?msg_id=9532982 > > > > Maybe it might help. > > This seems like a good idea. I am having trouble > debugging valgrind. > Is there something special that needs to be done to > debug valgrind? > > Thanks, > Bob Rossi > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Bob R. <bo...@br...> - 2004-11-01 15:23:39
|
On Mon, Oct 04, 2004 at 07:34:11AM -0700, Naveen Kumar wrote: > Usually most funtions have a > > static const Bool debug = False; Is it possible to debug valgrind using GDB, or no? > set that to True and recompile valgrind. That should > do the trick. There is no one way to do this. Just > experiment with turning on debug in different parts of > the code. After you get a feel for the execution path > of the code you can narrow down your problems to one > or two files(in my case vg_stabs.c). Turn on debug in > that and add some VG_(printf) code in places where you > think there might be problems. That should help you > pinpoint the problem. This is fine, but it could take a long time to find by using instrumentation. Has any worked on trying to debug valgrind using GDB? Bob Rossi |
|
From: Tom H. <th...@cy...> - 2004-11-01 16:16:52
|
In message <20041101152320.GB2460@white>
Bob Rossi <bo...@br...> wrote:
> On Mon, Oct 04, 2004 at 07:34:11AM -0700, Naveen Kumar wrote:
>> Usually most funtions have a
>>
>> static const Bool debug = False;
>
> Is it possible to debug valgrind using GDB, or no?
It is, but it is rarely the easiest way to debug it as you need to
understand exactly what you are trying to debug and what bit of
valgrind it is likely to be in - debugging the stage one loader
requires a different technique to debugging stage two which is
different to debugging code that runs on the simulated CPU as a part
of the client program.
I do quite a bit of bug hunting in valgrind and it's very rare
that I choose to use gdb to do it - using the various trace options
in valgrind (both switches and compile time changes) is usually much
easier.
Basically, if you're debugging stage one then you just run it under
gdb in the normal way. If it is getting past the stage one loader and
into valgrind proper then you need to use --wait-for-gdb=yes and then
start gdb in another window as follows:
gdb /usr/lib/valgrind/stage2 <pid>
Where <pid> is the pid that valgrind prints out. You can then start
it running using "jump *$eip" in the gdb window.
Code that runs in the target program such as the pthread replacement
code or the malloc replacement code would have to be debugged as part
of the target program, probably by attaching a debugger after it has
started. I've never really tried that however.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-11-01 16:45:01
|
On Mon, Nov 01, 2004 at 04:16:34PM +0000, Tom Hughes wrote: > In message <20041101152320.GB2460@white> > Bob Rossi <bo...@br...> wrote: > > > On Mon, Oct 04, 2004 at 07:34:11AM -0700, Naveen Kumar wrote: > >> Usually most funtions have a > >> > >> static const Bool debug = False; > > > > Is it possible to debug valgrind using GDB, or no? > > It is, but it is rarely the easiest way to debug it as you need to > understand exactly what you are trying to debug and what bit of > valgrind it is likely to be in - debugging the stage one loader > requires a different technique to debugging stage two which is > different to debugging code that runs on the simulated CPU as a part > of the client program. > > I do quite a bit of bug hunting in valgrind and it's very rare > that I choose to use gdb to do it - using the various trace options > in valgrind (both switches and compile time changes) is usually much > easier. > > Basically, if you're debugging stage one then you just run it under > gdb in the normal way. If it is getting past the stage one loader and > into valgrind proper then you need to use --wait-for-gdb=yes and then > start gdb in another window as follows: > > gdb /usr/lib/valgrind/stage2 <pid> > > Where <pid> is the pid that valgrind prints out. You can then start > it running using "jump *$eip" in the gdb window. OK, this is really helpful. I was able to get this far. Now I want to set a breakpoint in VG_. However, when I attach and do 'b VG_' I get 'Function "VG_" not defined.' which makes me think that maybe I'm debugging at the wrong stage? Any help? Thanks, Bob Rossi |
|
From: Tom H. <th...@cy...> - 2004-11-01 16:49:50
|
In message <20041101164452.GC2460@white>
Bob Rossi <bo...@br...> wrote:
> OK, this is really helpful. I was able to get this far. Now I want to
> set a breakpoint in VG_. However, when I attach and do
> 'b VG_' I get 'Function "VG_" not defined.'
> which makes me think that maybe I'm debugging at the wrong stage?
There's no such function as VG_ in valgrind. What is it you actually
want to stop on?
Note that VG_ is a macro so VG_(xxx) expands to vgPlain_xxx.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-11-01 17:09:32
|
On Mon, Nov 01, 2004 at 04:49:38PM +0000, Tom Hughes wrote: > In message <20041101164452.GC2460@white> > Bob Rossi <bo...@br...> wrote: > > > OK, this is really helpful. I was able to get this far. Now I want to > > set a breakpoint in VG_. However, when I attach and do > > 'b VG_' I get 'Function "VG_" not defined.' > > which makes me think that maybe I'm debugging at the wrong stage? > > There's no such function as VG_ in valgrind. What is it you actually > want to stop on? > > Note that VG_ is a macro so VG_(xxx) expands to vgPlain_xxx. I want to stop in the stabs reader. I just got the translation unit and see that the function name I think I want to stop in vgPlain_read_debuginfo_stabs. However, I 1. run 'valgrind --wait-for-gdb=yes --tool=corecheck ./tmp/uut' 2. gdb valgrind --pid=valgrind above 3. break vgPlain_read_debuginfo_stabs this is where I still get 'Function "vgPlain_read_debuginfo_stabs" not defined.'. Any ideas? Thanks, Bob Rossi |
|
From: Tom H. <th...@cy...> - 2004-11-01 17:30:29
|
In message <20041101170921.GD2460@white>
Bob Rossi <bo...@br...> wrote:
> I want to stop in the stabs reader. I just got the translation unit and
> see that the function name I think I want to stop in
> vgPlain_read_debuginfo_stabs. However, I
>
> 1. run 'valgrind --wait-for-gdb=yes --tool=corecheck ./tmp/uut'
> 2. gdb valgrind --pid=valgrind above
That's wrong - it should be /usr/lib/valgrind/stage2 as I wrote in
my first message.
> 3. break vgPlain_read_debuginfo_stabs
>
> this is where I still get 'Function "vgPlain_read_debuginfo_stabs" not
> defined.'.
Because you've got gdb using the stage one loader symbols.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-11-01 19:00:03
|
On Mon, Nov 01, 2004 at 05:30:19PM +0000, Tom Hughes wrote: > In message <20041101170921.GD2460@white> > Bob Rossi <bo...@br...> wrote: > > > I want to stop in the stabs reader. I just got the translation unit and > > see that the function name I think I want to stop in > > vgPlain_read_debuginfo_stabs. However, I > > > > 1. run 'valgrind --wait-for-gdb=yes --tool=corecheck ./tmp/uut' > > 2. gdb valgrind --pid=valgrind above > > That's wrong - it should be /usr/lib/valgrind/stage2 as I wrote in > my first message. Thanks Tom, I found the place where it is looping forever, it is in vg_symtypes.c line 416. Here is the backtrace. #0 vgPlain_st_basetype (type=0xb0201498, do_resolve=0 '\0') at vg_symtypes.c:41 7 #1 0xb0037778 in initSym (si=0xb01e8020, sym=0xb0200f58, kind=N_LSYM, namep=0xb fffeaa0, val=0) at vg_stabs.c:1095 #2 0xb00382b0 in vgPlain_read_debuginfo_stabs (si=0xb01e8020, stabC=0xb02fbf20 "\001", stab_sz=29508, stabstr=0xb0303264 "", stabstr_sz=61536) at vg_stabs.c:16 72 Basically the typdef points to itself. $8 = (SymType *) 0xb0201430 (tgdb) p type->u.t_typedef.type $9 = (SymType *) 0xb0201430 (tgdb) So, is the problem that the data structure was populated the wrong way? Or can I look at the actual stabs data in the assembly file to see if it is incorrect? Any suggestions on how to fix this? What about an assertion in the loop like below? if ( type == type->u.t_typedef.type ) then break; /* Error in symbol reading */ Thanks, Bob Rossi |
|
From: Tom H. <th...@cy...> - 2004-11-01 20:14:52
|
In message <20041101185938.GE2460@white>
Bob Rossi <bo...@br...> wrote:
>
> Thanks Tom,
>
> I found the place where it is looping forever, it is in vg_symtypes.c
> line 416.
>
> Here is the backtrace.
>
> #0 vgPlain_st_basetype (type=0xb0201498, do_resolve=0 '\0') at
> vg_symtypes.c:41
> 7
> #1 0xb0037778 in initSym (si=0xb01e8020, sym=0xb0200f58, kind=N_LSYM,
> namep=0xb
> fffeaa0, val=0) at vg_stabs.c:1095
> #2 0xb00382b0 in vgPlain_read_debuginfo_stabs (si=0xb01e8020,
> stabC=0xb02fbf20
> "\001", stab_sz=29508, stabstr=0xb0303264 "", stabstr_sz=61536) at
> vg_stabs.c:16
> 72
>
>
> Basically the typdef points to itself.
>
> $8 = (SymType *) 0xb0201430
> (tgdb) p type->u.t_typedef.type
> $9 = (SymType *) 0xb0201430
> (tgdb)
That looks suspiciously like the bug I fixed a few weeks ago. Are
you using the CVS head or 2.2.0 here?
> So, is the problem that the data
> structure was populated the wrong way? Or can I look at the actual
> stabs data in the assembly file to see if it is incorrect?
You can use objdump or you can just turn on debugging in vg_stabs.c ;-)
> Any suggestions on how to fix this?
>
> What about an assertion in the loop like below?
> if ( type == type->u.t_typedef.type ) then
> break; /* Error in symbol reading */
Well that isn't an assertion...
The fix depends on the problem is. If you could file a bug with a
test case then that would be very helpful.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Bob R. <bo...@br...> - 2004-11-01 22:23:01
|
On Mon, Nov 01, 2004 at 08:14:45PM +0000, Tom Hughes wrote: > In message <20041101185938.GE2460@white> > Bob Rossi <bo...@br...> wrote: > > > > > Thanks Tom, > > > > I found the place where it is looping forever, it is in vg_symtypes.c > > line 416. > > > > Here is the backtrace. > > > > #0 vgPlain_st_basetype (type=0xb0201498, do_resolve=0 '\0') at > > vg_symtypes.c:41 > > 7 > > #1 0xb0037778 in initSym (si=0xb01e8020, sym=0xb0200f58, kind=N_LSYM, > > namep=0xb > > fffeaa0, val=0) at vg_stabs.c:1095 > > #2 0xb00382b0 in vgPlain_read_debuginfo_stabs (si=0xb01e8020, > > stabC=0xb02fbf20 > > "\001", stab_sz=29508, stabstr=0xb0303264 "", stabstr_sz=61536) at > > vg_stabs.c:16 > > 72 > > > > > > Basically the typdef points to itself. > > > > $8 = (SymType *) 0xb0201430 > > (tgdb) p type->u.t_typedef.type > > $9 = (SymType *) 0xb0201430 > > (tgdb) > > That looks suspiciously like the bug I fixed a few weeks ago. Are > you using the CVS head or 2.2.0 here? I was using CVS from sometime around a few weeks ago :) I'll do an update and try again. Hopefully it'll work ... Bob Rossi |
|
From: Bob R. <bo...@br...> - 2004-11-02 13:43:49
|
On Mon, Nov 01, 2004 at 05:22:53PM -0500, Bob Rossi wrote: > On Mon, Nov 01, 2004 at 08:14:45PM +0000, Tom Hughes wrote: > > In message <20041101185938.GE2460@white> > > Bob Rossi <bo...@br...> wrote: > > > > > > > > Thanks Tom, > > > > > > I found the place where it is looping forever, it is in vg_symtypes.c > > > line 416. > > > > > > Here is the backtrace. > > > > > > #0 vgPlain_st_basetype (type=0xb0201498, do_resolve=0 '\0') at > > > vg_symtypes.c:41 > > > 7 > > > #1 0xb0037778 in initSym (si=0xb01e8020, sym=0xb0200f58, kind=N_LSYM, > > > namep=0xb > > > fffeaa0, val=0) at vg_stabs.c:1095 > > > #2 0xb00382b0 in vgPlain_read_debuginfo_stabs (si=0xb01e8020, > > > stabC=0xb02fbf20 > > > "\001", stab_sz=29508, stabstr=0xb0303264 "", stabstr_sz=61536) at > > > vg_stabs.c:16 > > > 72 > > > > > > > > > Basically the typdef points to itself. > > > > > > $8 = (SymType *) 0xb0201430 > > > (tgdb) p type->u.t_typedef.type > > > $9 = (SymType *) 0xb0201430 > > > (tgdb) > > > > That looks suspiciously like the bug I fixed a few weeks ago. Are > > you using the CVS head or 2.2.0 here? > > I was using CVS from sometime around a few weeks ago :) > I'll do an update and try again. Hopefully it'll work ... Great, this works now, thanks! Bob Rossi |
|
From: Naveen K. <g_n...@ya...> - 2004-11-02 16:06:35
|
Bob, I had suggested you try the "solution" I had put forward when you first mailed the list regarding this problem since my case was similar. http://sourceforge.net/mailarchive/message.php?msg_id=9681249 I fixed the "looping" as shown below(in link). Doesn't look like it is the same fix that Tom is talking about. http://sourceforge.net/mailarchive/message.php?msg_id=9532982 Anyway good to know that you have it fixed. Naveen --- Bob Rossi <bo...@br...> wrote: > On Mon, Nov 01, 2004 at 05:30:19PM +0000, Tom Hughes > wrote: > > In message <20041101170921.GD2460@white> > > Bob Rossi <bo...@br...> wrote: > > > > > I want to stop in the stabs reader. I just got > the translation unit and > > > see that the function name I think I want to > stop in > > > vgPlain_read_debuginfo_stabs. However, I > > > > > > 1. run 'valgrind --wait-for-gdb=yes > --tool=corecheck ./tmp/uut' > > > 2. gdb valgrind --pid=valgrind above > > > > That's wrong - it should be > /usr/lib/valgrind/stage2 as I wrote in > > my first message. > > Thanks Tom, > > I found the place where it is looping forever, it is > in vg_symtypes.c > line 416. > > Here is the backtrace. > > #0 vgPlain_st_basetype (type=0xb0201498, > do_resolve=0 '\0') at > vg_symtypes.c:41 > 7 > #1 0xb0037778 in initSym (si=0xb01e8020, > sym=0xb0200f58, kind=N_LSYM, > namep=0xb > fffeaa0, val=0) at vg_stabs.c:1095 > #2 0xb00382b0 in vgPlain_read_debuginfo_stabs > (si=0xb01e8020, > stabC=0xb02fbf20 > "\001", stab_sz=29508, stabstr=0xb0303264 "", > stabstr_sz=61536) at > vg_stabs.c:16 > 72 > > > Basically the typdef points to itself. > > $8 = (SymType *) 0xb0201430 > (tgdb) p type->u.t_typedef.type > $9 = (SymType *) 0xb0201430 > (tgdb) > > So, is the problem that the data > structure was populated the wrong way? Or can I look > at the actual > stabs data in the assembly file to see if it is > incorrect? > > Any suggestions on how to fix this? > > What about an assertion in the loop like below? > if ( type == type->u.t_typedef.type ) then > break; /* Error in symbol reading */ > > Thanks, > Bob Rossi > > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for > FREE > LinuxWorld Reader's Choice Award Winner for best > database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com |