|
| hooklogger problem, repost |
 |
Wed, 16 Aug 2006 14:10:06 +020 |
Hello,
I am trying to get rid of some nasty leaks in my app. As I rememberd
before when using uiq2.1 sdk there was pretty call stack leading to each
memory leak.
Now instead of functions with nice names i have only ordinal numbers.
It look like:
Call stack:
Ordinal345 + 18
Expo + 8996 -EUserParasite_EKA1.dll! 10003324()
Expo + 10308 -EUserParasite_EKA1.dll! 10003844()
Ordinal67 + 1004
Ordinal26 + 184
Ordinal72 + 51
Ordinal254 + 507
Ordinal254 + 201
Ordinal285 + 40
Ordinal63 + 76
Ordinal221 + 219
Ordinal221 + 353
Ordinal1482 + 38
Ordinal279 + 1213 -EKERN.DLL! 5b00d103()
kernel32.dll! 7c [e487]
What can be wrong? How to get usable function names from these ordinals?
My sdk: s60 2.1 codewarrior version
Thanks in advance
|
| Post Reply
|
| Re: hooklogger problem, repost |
 |
Thu, 17 Aug 2006 05:25:34 -000 |
I'm querying the tool's author- busy man, so may take some time to respond.
Regards
H
"Sebastian Wieczorek" <s.wieczorek@softline.net.pl> wrote in
message
news:1NZ6p0SwGHA.1384@UKCOL01WWEB01.symbian.intra...
> Hello,
>
> I am trying to get rid of some nasty leaks in my app. As I rememberd
> before when using uiq2.1 sdk there was pretty call stack leading to each
> memory leak.
> Now instead of functions with nice names i have only ordinal numbers.
>
> It look like:
> Call stack:
> Ordinal345 + 18
> Expo + 8996 -EUserParasite_EKA1.dll! 10003324()
> Expo + 10308 -EUserParasite_EKA1.dll! 10003844()
> Ordinal67 + 1004
> Ordinal26 + 184
> Ordinal72 + 51
> Ordinal254 + 507
> Ordinal254 + 201
> Ordinal285 + 40
> Ordinal63 + 76
> Ordinal221 + 219
> Ordinal221 + 353
> Ordinal1482 + 38
> Ordinal279 + 1213 -EKERN.DLL! 5b00d103()
> kernel32.dll! 7c [e487]
>
> What can be wrong? How to get usable function names from these ordinals?
> My sdk: s60 2.1 codewarrior version
>
> Thanks in advance
> Sebastian Wieczorek
|
| Post Reply
|
| Re: hooklogger problem, repost |
 |
Thu, 17 Aug 2006 07:35:38 -000 |
OK, from the expert ....,
This is probably not due to HookLogger itself -> if symbols are unobtainable
then it reports offsets from the start of the DLL (would take more effort to
figure out nearest ordinal). My guesses in order of likelihood:
1. The SDK binaries are UREL and that the symbol table handler (part of MS's
debug tools we include with HL) does this as its best guess.
2. The SDK binaries have been deliberately built without symbols (or been
stripped)
3. You've got a conflicting version of DBGHELP.DLL taking precedence in the
path (shouldn't be possible since the one we include is in the same
directory as HL, and he indicates that the change was well-corellated with
changing SDK, but maybe in between he moved stuff around or experimented)
This effect can be reproduced by running a UREL emulator, So it's almost
certainly (1) - either you ran it on a UREL emulator or (worst case) the SDK
only ships UREL/or non symbol version.
Can you force this to UDEB and confirm whether or not it works?
Regards
H
"Hamish Willee" <hamish_w@tpg.com.au> wrote in message
news:nKVZT3bwGHA.5096@UKCOL01WWEB01.symbian.intra...
> I'm querying the tool's author- busy man, so may take some time to
respond.
> Regards
> H
>
> "Sebastian Wieczorek" <s.wieczorek@softline.net.pl> wrote
in message
> news:1NZ6p0SwGHA.1384@UKCOL01WWEB01.symbian.intra...
> > Hello,
> >
> > I am trying to get rid of some nasty leaks in my app. As I rememberd
> > before when using uiq2.1 sdk there was pretty call stack leading to
each
> > memory leak.
> > Now instead of functions with nice names i have only ordinal numbers.
> >
> > It look like:
> > Call stack:
> > Ordinal345 + 18
> > Expo + 8996 -EUserParasite_EKA1.dll! 10003324()
> > Expo + 10308 -EUserParasite_EKA1.dll! 10003844()
> > Ordinal67 + 1004
> > Ordinal26 + 184
> > Ordinal72 + 51
> > Ordinal254 + 507
> > Ordinal254 + 201
> > Ordinal285 + 40
> > Ordinal63 + 76
> > Ordinal221 + 219
> > Ordinal221 + 353
> > Ordinal1482 + 38
> > Ordinal279 + 1213 -EKERN.DLL! 5b00d103()
> > kernel32.dll! 7c [e487]
> >
> > What can be wrong? How to get usable function names from these
ordinals?
> > My sdk: s60 2.1 codewarrior version
> >
> > Thanks in advance
> > Sebastian Wieczorek
>
>
|
| Post Reply
|
| Re: hooklogger problem, repost |
 |
Thu, 17 Aug 2006 12:28:23 +020 |
ad 1) I am quite sure it was udeb. Also i've checked this again by
recompiling all libs and app, then started udeb emulator. Still the
same, I see only ordinals...
Another interesting thing is sometimes I see single function name but i
cannot reproduce it. It looks like:
Ordinal1664 + 29
Ordinal70 + 55
Ordinal941 + 121
CXXXAppUi::ConstructL(void) <C:\some path\SRC\CXXXAppUi.cpp #69>
Ordinal182 + 89
Ordinal183 + 33
Ordinal63 + 567
Ordinal221 + 219
Now, double click on some (or 'alloc details' button) items on 'heap'
tab does not show details window, where call stack is shown.
ad 3) I've found seven copies of dbghelp.dll on my machine, seven
different versions :). Also I checked which one is loaded when HL is
working, it was right one:
dbghelp 6.3.0011.3 (DbgBuild.040120-1256) 894 464 bytes 2004-03-04
14:52 Microsoft Corporation c:\program files\common
files\symbian\tools\dbghelp.dll
ad 2) Binaries without symbols... i've checked this "ordinals only"
behaviour on several machines, where codewarrior and ms visual c++ was
used. Also, as before, I recompiled everything using ms visual c++ and
still the same, no function names.
Then started uiq 2.1 emluator, symbols were visible, in my app and in
system libs. I think nokia s60 2.1 wins and winscw sdk does not include
symbols...
Probably this is what we are searching for.
When searching for memory leaks, framework panics app when it finds one
leak at least(or some other resource), then you can see all allocated
cells on 'heap' tab. Beside of application allocated memory there is
plenty of framework allocated memory, which would be freed later. I
think in this corwd I did not noticed 'my leaks'. This is my assumption.
Last thing to explain is why I cannot see 'alloc details'(as above) for
some items listed in 'heap' tab in HL.
Thank you Hamish
Sebastian Wieczorek
Hamish Willee wrote:
> OK, from the expert ....,
>
> This is probably not due to HookLogger itself -> if symbols are
unobtainable
> then it reports offsets from the start of the DLL (would take more effort
to
> figure out nearest ordinal). My guesses in order of likelihood:
>
> 1. The SDK binaries are UREL and that the symbol table handler (part of
MS's
> debug tools we include with HL) does this as its best guess.
>
> 2. The SDK binaries have been deliberately built without symbols (or been
> stripped)
>
> 3. You've got a conflicting version of DBGHELP.DLL taking precedence in
the
> path (shouldn't be possible since the one we include is in the same
> directory as HL, and he indicates that the change was well-corellated with
> changing SDK, but maybe in between he moved stuff around or experimented)
>
> This effect can be reproduced by running a UREL emulator, So it's almost
> certainly (1) - either you ran it on a UREL emulator or (worst case) the
SDK
> only ships UREL/or non symbol version.
>
> Can you force this to UDEB and confirm whether or not it works?
>
> Regards
>
> H
>
> "Hamish Willee" <hamish_w@tpg.com.au> wrote in message
> news:nKVZT3bwGHA.5096@UKCOL01WWEB01.symbian.intra...
>> I'm querying the tool's author- busy man, so may take some time to
> respond.
>> Regards
>> H
>>
>> "Sebastian Wieczorek" <s.wieczorek@softline.net.pl>
wrote in message
>> news:1NZ6p0SwGHA.1384@UKCOL01WWEB01.symbian.intra...
>>> Hello,
>>>
>>> I am trying to get rid of some nasty leaks in my app. As I
rememberd
>>> before when using uiq2.1 sdk there was pretty call stack leading to
each
>>> memory leak.
>>> Now instead of functions with nice names i have only ordinal
numbers.
>>>
>>> It look like:
>>> Call stack:
>>> Ordinal345 + 18
>>> Expo + 8996 -EUserParasite_EKA1.dll! 10003324()
>>> Expo + 10308 -EUserParasite_EKA1.dll! 10003844()
>>> Ordinal67 + 1004
>>> Ordinal26 + 184
>>> Ordinal72 + 51
>>> Ordinal254 + 507
>>> Ordinal254 + 201
>>> Ordinal285 + 40
>>> Ordinal63 + 76
>>> Ordinal221 + 219
>>> Ordinal221 + 353
>>> Ordinal1482 + 38
>>> Ordinal279 + 1213 -EKERN.DLL! 5b00d103()
>>> kernel32.dll! 7c [e487]
>>>
>>> What can be wrong? How to get usable function names from these
ordinals?
>>> My sdk: s60 2.1 codewarrior version
>>>
>>> Thanks in advance
>>> Sebastian Wieczorek
>>
>
|
| Post Reply
|
| Re: hooklogger problem, repost |
 |
Fri, 18 Aug 2006 06:52:18 -000 |
Hi
Against the "symbols removed" notion is the absence of any of your
own
symbols! If you don't have symbols then you should get a similarly unhelpful
callstack above your code in the IDE when hitting a breakpoint?
Aside from that a quick way to check the symbols present would be running
PEDUMP (old Win32 tool by Matt Pietrek, Win32 guru), from here:
http://www.wheaty.net/downloads.htm
across both the UDEB & UREL EUSER.DLL. It's a command line tool, run with
just the EXE/DLL name, eg:
pedump \epoc32\RELEASE\WINSCW\UREL\EUSER.DLL
Among the details output is a summary of debugging data. For UDEB I have
this in the "data directory" section:
DEBUG rva: 00068CC0 size: 0000001C
and later this:
Debug Formats in File
Type Size Address FilePtr Charactr TimeData Version
--------------- -------- -------- -------- -------- -------- --------
CODEVIEW 00118E9C 00000000 0009A000 00000000 44B3E416 0.00
whereas on UREL the data directory has no entry:
DEBUG rva: 00000000 size: 00000000
What does PEDUMP say?
Hamish Willee/UK/Symbian
18/08/2006 00:25
To
Thomas Goodfellow/UK/Symbian@Symbian
cc
"Sebastian Wieczorek" <s.wieczorek@softline.net.pl> wrote in
message
news:58SjegewGHA.3788@UKCOL01WWEB01.symbian.intra...
> ad 1) I am quite sure it was udeb. Also i've checked this again by
> recompiling all libs and app, then started udeb emulator. Still the
> same, I see only ordinals...
> Another interesting thing is sometimes I see single function name but i
> cannot reproduce it. It looks like:
>
> Ordinal1664 + 29
> Ordinal70 + 55
> Ordinal941 + 121
> CXXXAppUi::ConstructL(void) <C:\some path\SRC\CXXXAppUi.cpp #69>
> Ordinal182 + 89
> Ordinal183 + 33
> Ordinal63 + 567
> Ordinal221 + 219
>
> Now, double click on some (or 'alloc details' button) items on 'heap'
> tab does not show details window, where call stack is shown.
>
> ad 3) I've found seven copies of dbghelp.dll on my machine, seven
> different versions :). Also I checked which one is loaded when HL is
> working, it was right one:
> dbghelp 6.3.0011.3 (DbgBuild.040120-1256) 894 464 bytes 2004-03-04
> 14:52 Microsoft Corporation c:\program files\common
> files\symbian\tools\dbghelp.dll
>
>
>
> ad 2) Binaries without symbols... i've checked this "ordinals
only"
> behaviour on several machines, where codewarrior and ms visual c++ was
> used. Also, as before, I recompiled everything using ms visual c++ and
> still the same, no function names.
> Then started uiq 2.1 emluator, symbols were visible, in my app and in
> system libs. I think nokia s60 2.1 wins and winscw sdk does not include
> symbols...
>
> Probably this is what we are searching for.
> When searching for memory leaks, framework panics app when it finds one
> leak at least(or some other resource), then you can see all allocated
> cells on 'heap' tab. Beside of application allocated memory there is
> plenty of framework allocated memory, which would be freed later. I
> think in this corwd I did not noticed 'my leaks'. This is my assumption.
>
>
> Last thing to explain is why I cannot see 'alloc details'(as above) for
> some items listed in 'heap' tab in HL.
>
> Thank you Hamish
>
> Sebastian Wieczorek
>
>
> Hamish Willee wrote:
> > OK, from the expert ....,
> >
> > This is probably not due to HookLogger itself -> if symbols are
unobtainable
> > then it reports offsets from the start of the DLL (would take more
effort to
> > figure out nearest ordinal). My guesses in order of likelihood:
> >
> > 1. The SDK binaries are UREL and that the symbol table handler (part
of
MS's
> > debug tools we include with HL) does this as its best guess.
> >
> > 2. The SDK binaries have been deliberately built without symbols (or
been
> > stripped)
> >
> > 3. You've got a conflicting version of DBGHELP.DLL taking precedence
in
the
> > path (shouldn't be possible since the one we include is in the same
> > directory as HL, and he indicates that the change was well-corellated
with
> > changing SDK, but maybe in between he moved stuff around or
experimented)
> >
> > This effect can be reproduced by running a UREL emulator, So it's
almost
> > certainly (1) - either you ran it on a UREL emulator or (worst case)
the
SDK
> > only ships UREL/or non symbol version.
> >
> > Can you force this to UDEB and confirm whether or not it works?
> >
> > Regards
> >
> > H
> >
> > "Hamish Willee" <hamish_w@tpg.com.au> wrote in
message
> > news:nKVZT3bwGHA.5096@UKCOL01WWEB01.symbian.intra...
> >> I'm querying the tool's author- busy man, so may take some time
to
> > respond.
> >> Regards
> >> H
> >>
> >> "Sebastian Wieczorek"
<s.wieczorek@softline.net.pl> wrote in message
> >> news:1NZ6p0SwGHA.1384@UKCOL01WWEB01.symbian.intra...
> >>> Hello,
> >>>
> >>> I am trying to get rid of some nasty leaks in my app. As I
rememberd
> >>> before when using uiq2.1 sdk there was pretty call stack
leading to
each
> >>> memory leak.
> >>> Now instead of functions with nice names i have only ordinal
numbers.
> >>>
> >>> It look like:
> >>> Call stack:
> >>> Ordinal345 + 18
> >>> Expo + 8996 -EUserParasite_EKA1.dll! 10003324()
> >>> Expo + 10308 -EUserParasite_EKA1.dll! 10003844()
> >>> Ordinal67 + 1004
> >>> Ordinal26 + 184
> >>> Ordinal72 + 51
> >>> Ordinal254 + 507
> >>> Ordinal254 + 201
> >>> Ordinal285 + 40
> >>> Ordinal63 + 76
> >>> Ordinal221 + 219
> >>> Ordinal221 + 353
> >>> Ordinal1482 + 38
> >>> Ordinal279 + 1213 -EKERN.DLL! 5b00d103()
> >>> kernel32.dll! 7c [e487]
> >>>
> >>> What can be wrong? How to get usable function names from
these
ordinals?
> >>> My sdk: s60 2.1 codewarrior version
> >>>
> >>> Thanks in advance
> >>> Sebastian Wieczorek
> >>
> >
> >
|
| Post Reply
|
|
|