indented relay traces

[James Hawkins]

Hey guys,

I don't know if you've ever wished the relay traces were indented by
the level of the call, so you can get a better feel for who calls what
from where, but I thought it would be nifty.  I've attached a patch
for dlls/ntdll/relay.c that gives you this.  You see the call level
next to the thread id, then twice that number of spaces, then the
usual relay information.  I'd paste an example, but it would just get
line wrapped, so patch your tree and give it a shot!

[Eric Pouech]

James Hawkins wrote:
> Hey guys,
>
> I don't know if you've ever wished the relay traces were indented by
> the level of the call, so you can get a better feel for who calls what
> from where, but I thought it would be nifty.  I've attached a patch
> for dlls/ntdll/relay.c that gives you this.  You see the call level
> next to the thread id, then twice that number of spaces, then the
> usual relay information.  I'd paste an example, but it would just get
> line wrapped, so patch your tree and give it a shot!

this won't work for a multithreaded program
tools/examine_relay does what you want, plus some other goodies (calls 
that didn't return...)
IMO it's better to instrument the tools after the relay trace, rather 
than tweaking the trace generation for any potential goodie

A+

[James Hawkins]

On 6/24/06, Eric Pouech  wrote:
> >
>
> this won't work for a multithreaded program
> tools/examine_relay does what you want, plus some other goodies (calls
> that didn't return...)

Ah, didn't know about that tool.  You learn something new every day.
> IMO it's better to instrument the tools after the relay trace, rather
> than tweaking the trace generation for any potential goodie

It's ok, I know it was a hack :)

[Jaap Stolk]

On 6/24/06, James Hawkins  wrote:
> Ah, didn't know about that tool.  You learn something new every day.

didn't know about that tool too. sounds interesting.

usually I do something like:

// reduce log size:
egrep -v 'RtlFreeHeap|RtlAllocateHeap|trace:syslevel:_Enter|trace:syslevel:_Leave|Ret
 kernel32.MultiByteToWideChar|Ret  ntdll.RtlUpperChar'  all.txt >
all2.txt

// add line numbering: (to back-trace interesting things) all2.txt > all.txt
grep -n ''

// filter out interesting things: (manually add more interesting finds later)
egrep ':loaddll:|:ntoskrnl:|:warn:|Unable to|fixme' all.txt >
all_interesting.txt

Jaap.

[Mike Hearn]

On Sat, 24 Jun 2006 02:15:09 -0700, James Hawkins wrote:
> Ah, didn't know about that tool.  You learn something new every day.

Perhaps it should be mentioned in the developer quickstart.

thanks -mike

[Duane Clark]

James Hawkins wrote:
> On 6/24/06, Eric Pouech  wrote:
> > this won't work for a multithreaded program
> > tools/examine_relay does what you want, plus some other goodies (calls
> > that didn't return...)
>
> Ah, didn't know about that tool.  You learn something new every day.

It is also not immediately obvious that it will indent in two slightly 
different formats. Add a flag to the end of the command line to get 
different formatting:
tools/examine_relay wine.log -f

[Molle Bestefich]

James Hawkins wrote:
> I don't know if you've ever wished the relay traces were indented by
> the level of the call, so you can get a better feel for who calls what
> from where, but I thought it would be nifty.  I've attached a patch
> > for dlls/ntdll/relay.c that gives you this.

Hah, funny..
I made a patch to accomplish exactly the same a year ago.

Eric Pouech wrote:
> this won't work for a multithreaded program

Mine did :-).
Also, it could filter calls beyond a specific level, as a way of
limiting output.
> tools/examine_relay does what you want, plus some other goodies
> (calls that didn't return...)
> IMO it's better to instrument the tools after the relay trace,
> rather than tweaking the trace generation for any potential goodie

IMHO, tools/examine_relay seemed to behave wrongly in some cases and
is also an overly complex solution compared to just doing this at
runtime.  It really doesn't take much code.