|
From: Naveen K. <g_n...@ya...> - 2004-09-01 17:59:27
|
Hi folks, I am running valgrind on a executable and I dont see any output. I put in the verbose option for valgrind and the last line printed is ==3145== Reading syms from so-and-so-binary (0x8048000) Thats it. I dont get any output after that. I then recompiled coregrind with some of the debug flags set to true and reran the executable. It prints out lots of data and thats it, it just stops at some point. There dont seem to be any apparent errors from those logs. Any suggestion ? The linux box is running the Linux-2.4.9-12 kernel. I did test valgrind on a simpler executable and it worked fine. On this particular executable though I dont have a clue. Thanks Naveen __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail |
|
From: Naveen K. <g_n...@ya...> - 2004-09-09 19:30:11
|
Hi folks,
I had posted earlier about valgrind stalling but
since nobody seemed to have encountered it I decided
to try investigating myself. I turned on some of the
debug flags and added some printf statements at some
points in the code. I find that valgrind is going into
an infinite loop in one place. These are the debug
statements before it stalls
initSym(si=0xB02ED020, tab=0xB02FD120, sym=0xB17416F8,
kind=128, name=0xB0AC6C46 "msgbuf:Tt(0,27)=xsmsgbuf:",
val=0)
initSym name="msgbuf" type=Tt(0,27)=xsmsgbuf:
initSym: before base type
I added the following printfs in vg_stabs.c
VG_(printf)("initSym: before base type\n");
base = VG_(st_basetype)(sym->type, False);
VG_(printf)("initSym: after base type\n");
As can be seen from the logs I dont get anything
printed after "..before base type..". It is just
spinning in VG_(st_basetype). Any suggestions on what
may be causing this ?
Thanks
Naveen
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-13 11:12:26
|
On Thu, 9 Sep 2004, Naveen Kumar wrote:
> I had posted earlier about valgrind stalling but
> since nobody seemed to have encountered it I decided
> to try investigating myself. I turned on some of the
> debug flags and added some printf statements at some
> points in the code. I find that valgrind is going into
> an infinite loop in one place. These are the debug
> statements before it stalls
>
> initSym(si=0xB02ED020, tab=0xB02FD120, sym=0xB17416F8,
> kind=128, name=0xB0AC6C46 "msgbuf:Tt(0,27)=xsmsgbuf:",
> val=0)
>
> initSym name="msgbuf" type=Tt(0,27)=xsmsgbuf:
> initSym: before base type
>
> I added the following printfs in vg_stabs.c
> VG_(printf)("initSym: before base type\n");
> base = VG_(st_basetype)(sym->type, False);
> VG_(printf)("initSym: after base type\n");
>
> As can be seen from the logs I dont get anything
> printed after "..before base type..". It is just
> spinning in VG_(st_basetype).
Can you file a bug report for this please?
Thanks.
N
|
|
From: Naveen K. <g_n...@ya...> - 2004-09-14 21:44:12
|
Hi all,
Below(far below) is my previous post regarding
this. On further investigation I found that the "spin"
in VG_(st_basetype) [vg_symtypes.c] was because
type = type->u.t_typedef.type = SymType pointer passed
in the below function. Hence the spin forever.
SymType *VG_(st_basetype)(SymType *type, Bool
do_resolve)
{
while (type->kind == TyTypedef || (do_resolve &&
type->kind == TyUnresolved)) {
if (do_resolve)
resolve(type);
if (type->kind == TyTypedef)
{
type = type->u.t_typedef.type;
}
}
return type;
}
The symbol that was being parsed below had already
been parsed previously and I found that the
type->u.t_typedef.type was being set in
VG_(st_mktypedef) [vg_symtypes.c] which in turn was
being called from structDef [vg_stabs.c].
So I do a simple check before calling st_mktypedef
from structDef so that recursion is avoided as shown
below. After making the below change I find that the
program in question could executed by valgrind(and
already it has found some problems!!!).
static SymType *structDef(StabTypeTab *tab, SymType
*def, Bool isstruct, Char *name)
{
static const Bool debug = False;
SymType *ref = structRef(tab, NULL, isstruct,
name);
if (debug)
VG_(printf)("defining %s ref for %s %p -> %p\n",
isstruct ? "struct" : "union", name,
ref, def);
if( ref != def)
def = VG_(st_mktypedef)(ref, name,
VG_(st_basetype)(def, False));
VG_(st_setname)(def, name);
return def;
}
I am not sure if the above is the correct thing to do
but it works and I hope it would atleast shed some
light and pave the way for correcting it.
Thanks
Naveen
--- Nicholas Nethercote <nj...@ca...> wrote:
> On Thu, 9 Sep 2004, Naveen Kumar wrote:
>
> > I had posted earlier about valgrind stalling but
> > since nobody seemed to have encountered it I
> decided
> > to try investigating myself. I turned on some of
> the
> > debug flags and added some printf statements at
> some
> > points in the code. I find that valgrind is going
> into
> > an infinite loop in one place. These are the debug
> > statements before it stalls
> >
> > initSym(si=0xB02ED020, tab=0xB02FD120,
> sym=0xB17416F8,
> > kind=128, name=0xB0AC6C46
> "msgbuf:Tt(0,27)=xsmsgbuf:",
> > val=0)
> >
> > initSym name="msgbuf" type=Tt(0,27)=xsmsgbuf:
> > initSym: before base type
> >
> > I added the following printfs in vg_stabs.c
> > VG_(printf)("initSym: before base type\n");
> > base = VG_(st_basetype)(sym->type, False);
> > VG_(printf)("initSym: after base type\n");
> >
> > As can be seen from the logs I dont get anything
> > printed after "..before base type..". It is just
> > spinning in VG_(st_basetype).
>
> Can you file a bug report for this please?
>
> Thanks.
>
> N
>
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-13 11:15:03
|
On Mon, 13 Sep 2004, Nicholas Nethercote wrote:
>> I had posted earlier about valgrind stalling but
>> since nobody seemed to have encountered it I decided
>> to try investigating myself. I turned on some of the
>> debug flags and added some printf statements at some
>> points in the code. I find that valgrind is going into
>> an infinite loop in one place. These are the debug
>> statements before it stalls
>>
>> initSym(si=0xB02ED020, tab=0xB02FD120, sym=0xB17416F8,
>> kind=128, name=0xB0AC6C46 "msgbuf:Tt(0,27)=xsmsgbuf:",
>> val=0)
>>
>> initSym name="msgbuf" type=Tt(0,27)=xsmsgbuf:
>> initSym: before base type
>>
>> I added the following printfs in vg_stabs.c
>> VG_(printf)("initSym: before base type\n");
>> base = VG_(st_basetype)(sym->type, False);
>> VG_(printf)("initSym: after base type\n");
>>
>> As can be seen from the logs I dont get anything
>> printed after "..before base type..". It is just
>> spinning in VG_(st_basetype).
>
> Can you file a bug report for this please?
Actually, it might be more appropriate to add a comment to
http://bugs.kde.org/show_bug.cgi?id=88703 explaining your situation (I
think that's the bug you're talking about?)
Thanks.
N
|
|
From: Tom H. <th...@cy...> - 2004-09-13 11:46:29
|
In message <Pin...@he...>
Nicholas Nethercote <nj...@ca...> wrote:
> On Mon, 13 Sep 2004, Nicholas Nethercote wrote:
>
>>> I had posted earlier about valgrind stalling but
>>> since nobody seemed to have encountered it I decided
>>> to try investigating myself. I turned on some of the
>>> debug flags and added some printf statements at some
>>> points in the code. I find that valgrind is going into
>>> an infinite loop in one place. These are the debug
>>> statements before it stalls
>>> initSym(si=0xB02ED020, tab=0xB02FD120, sym=0xB17416F8,
>>> kind=128, name=0xB0AC6C46 "msgbuf:Tt(0,27)=xsmsgbuf:",
>>> val=0)
>>> initSym name="msgbuf" type=Tt(0,27)=xsmsgbuf:
>>> initSym: before base type
>>> I added the following printfs in vg_stabs.c
>>> VG_(printf)("initSym: before base type\n");
>>> base = VG_(st_basetype)(sym->type, False);
>>> VG_(printf)("initSym: after base type\n");
>>> As can be seen from the logs I dont get anything
>>> printed after "..before base type..". It is just
>>> spinning in VG_(st_basetype).
>>
>> Can you file a bug report for this please?
>
> Actually, it might be more appropriate to add a comment to
> http://bugs.kde.org/show_bug.cgi?id=88703 explaining your situation (I
> think that's the bug you're talking about?)
Why? That bug isn't about a stall, it's about a warning from
the stabs reader. I'm not aware of any reason to believe that
the two are linked.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2004-09-01 21:57:30
|
On Wed, 1 Sep 2004, Naveen Kumar wrote: > I am running valgrind on a executable and I dont > see any output. I put in the verbose option for > valgrind and the last line printed is > > ==3145== Reading syms from so-and-so-binary > (0x8048000) > > Thats it. I dont get any output after that. I then > recompiled coregrind with some of the debug flags set > to true and reran the executable. It prints out lots > of data and thats it, it just stops at some point. > There dont seem to be any apparent errors from those > logs. Any suggestion ? The linux box is running the > Linux-2.4.9-12 kernel. I did test valgrind on a > simpler executable and it worked fine. On this > particular executable though I dont have a clue. You don't say which Valgrind version you are using. Is the program you are running written in Ada? This sounds like bug #87904 (http://bugs.kde.org/show_bug.cgi?id=87904). N |
|
From: Naveen K. <g_n...@ya...> - 2004-09-02 14:03:46
|
Oops sorry I was using Valgrind version 2.1.2. Only after I wrote this email did I notice that 2.2.0 was released. I used that and now I get @@ unlikely looking definition in unparsed remains ";" on the below mentioned exec. BTW the exec was written in C++. Thanks Naveen --- Nicholas Nethercote <nj...@ca...> wrote: > On Wed, 1 Sep 2004, Naveen Kumar wrote: > > > I am running valgrind on a executable and I dont > > see any output. I put in the verbose option for > > valgrind and the last line printed is > > > > ==3145== Reading syms from so-and-so-binary > > (0x8048000) > > > > Thats it. I dont get any output after that. I then > > recompiled coregrind with some of the debug flags > set > > to true and reran the executable. It prints out > lots > > of data and thats it, it just stops at some point. > > There dont seem to be any apparent errors from > those > > logs. Any suggestion ? The linux box is running > the > > Linux-2.4.9-12 kernel. I did test valgrind on a > > simpler executable and it worked fine. On this > > particular executable though I dont have a clue. > > You don't say which Valgrind version you are using. > Is the program you > are running written in Ada? This sounds like bug > #87904 > (http://bugs.kde.org/show_bug.cgi?id=87904). > > N > _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush |
|
From: Nicholas N. <nj...@ca...> - 2004-09-02 14:08:48
|
On Thu, 2 Sep 2004, Naveen Kumar wrote: > Oops sorry I was using Valgrind version 2.1.2. Only > after I wrote this email did I notice that 2.2.0 was > released. I used that and now I get > > @@ unlikely looking definition in unparsed remains ";" > > on the below mentioned exec. Does it still hang, or does it run to completion? N |
|
From: Naveen K. <g_n...@ya...> - 2004-09-02 14:15:04
|
Oh it still hangs!!!! Naveen --- Nicholas Nethercote <nj...@ca...> wrote: > On Thu, 2 Sep 2004, Naveen Kumar wrote: > > > Oops sorry I was using Valgrind version 2.1.2. > Only > > after I wrote this email did I notice that 2.2.0 > was > > released. I used that and now I get > > > > @@ unlikely looking definition in unparsed remains > ";" > > > > on the below mentioned exec. > > Does it still hang, or does it run to completion? > > N > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
|
From: Paul P. <pa...@pa...> - 2004-09-03 16:03:47
|
>>>>> On Wed, 1 Sep 2004 10:59:20 -0700 (PDT), Naveen Kumar <g_n...@ya...> said:
> ==3145== Reading syms from so-and-so-binary
> (0x8048000)
> Thats it. I dont get any output after that.
Does the app re-exec itself?
If so, you'll need to add --trace-children=yes
--
Paul Pluzhnikov pa...@pa...
|