xscope in dtrace ver. 0.1
By uejio on Nov 06, 2007
I've been playing with dtrace a lot lately to help debug issues with the Xserver and some X clients. Since Alan added the dtrace probes for the Xserver in Solaris 10, I've been meaning to rewrite xscope using dtrace. It's probably a much bigger job than I have the spare time for, but I did start working on a simply version called xscope.d. This is version 0.1 and just prints a simple one line output for each X request and event and is based on Alan's sample scripts.
Here is some example output when xlogo is started:
request-start: from client=21 (), request = X_CreateWindow request-done: from client=21 (), request = X_ChangeWindowAttributes, resultCode = 0 request-start: from client=21 (), request = X_ChangeWindowAttributes client-auth: client=21, from local pid=7209 (/usr/openwin/bin/xlogo) request-done: from client=21 (/usr/openwin/bin/xlogo), request = X_ChangeWindowAttributes, resultCode = 0
This shows that the xlogo probably calls XCreateWindow() then XChangeWindowAttributes(). One odd thing about this output is that the client-auth probe which should fire when the client first connects to the Xserver seems to be called after the client makes a X_CreateWindow request. I can't figure out if that's a bug in dtrace or the Xserver probes.
I also added an example in xscope.d which gives more detail for the PropertyNotify event, so for this example, I see:
send-event: to client = 21 (/usr/openwin/bin/xlogo), event type = PropertyNotify (28) PropertyNotify: window=0xa80001, atom=0x27, state=0, time=381056109
What that means is that xlogo is probably changing the atom 0x27. What atom is that? I can use xlsatoms to list all the atoms (using the -f "%x %s" option to display in hex) and find that 0x27 is WM_NAME. So, this event corresponds to xlogo setting the name of the window. This is not particularly useful for this case, however, I have been working on a bug with focus events and modified this script to print out details for the FocusIn and FocusOut events. My xscope.d script has been very useful for understanding what's happening with that bug.