Tuesday Jul 29, 2008

LiveUSB creator for fedora

I needed to install Linux to reproduce a bug remotely displaying apps from Linux to Solaris and found a very easy to use Windows executable to create a Fedora Live USB. You can get it from: http://fedorahosted.org/liveusb-creator

The application lets you choose from a couple of different Fedora releases to download and it downloads and creates the USB all in one step.  If the USB create fails for some reason, it doesn't have to download the image again and it lets you continue on after correcting the error.  In my case, my flash drive was not FAT formatted, so after correcting that and refreshing the target device in their GUI, I continued with the USB creation.  The liveUSB booted fine on my Acer 3400.  Now, why can't creating an OpenSolaris liveUSB be that easy?

Wednesday Jul 16, 2008

OpenSolaris on an iPod Touch (via VNC)

Not sure if this would actually be usable, but here it is:


OpenSolaris 2008.05 on an iPod Touch via VNC.

This is using an iPod Touch that I bought a few months ago running the 2.0 Update and running a free VNC app from the App Store.  OpenSolaris 2008.05 in running on a Sun Ultra 20.  I had to enable XDMCP in gdm by editing the file /etc/X11/gdm/custom.conf and changing the xdmcp section to read:

[xdmcp]
Enable=true

Hm... This looks just like OpenSolaris.  "How do I know that you're running on an iTouch?", one might ask.  The only difference is those three buttons on the bottom of the image.  The keyboard button brings up keyboard input:



The "+" button brings up a menu of options and the "hand" button switches between using our finger as the pointer within VNC and using it as the pointer on the Touch. (i.e. to resize the screen and scroll).

Trust me.  I really do have my iTouch running a VNC app and displaying OpenSolaris 2008.05.  It really works! 

Wednesday Jul 02, 2008

simple DTrace script to print function argument

Someone asked me for a DTrace script to print out the argument to an arbitrary function. I'm not exactly sure if this is what he meant, so I wrote a script which lets you specify a function name and the position of the string argument that you want printed out and then the command to run.  Since it's a script, you can modify to print out integer args or to connect to a running process, etc...

The script is called printarg.d.  You have to run it either as root or with sufficient privileges in /etc/user_attr.  For example, this entry allows me to run dtrace scripts:

uejio::::type=normal;defaultpriv=basic,dtrace_user,dtrace_proc,dtrace_kernel

Anyway, here's an example:

$ printarg.d XLoadQueryFont 1 -c dtcalc
XLoadQueryFont: arg1=-dt-interface user-medium-r-normal-m\*-\*-\*-\*-\*-\*-\*-\*-\*
XLoadQueryFont: arg1=-dt-interface system-medium-r-normal-m sans-17-170-72-72-p-97-iso8859-1
XLoadQueryFont: arg1=-dt-interface user-medium-r-normal-m sans-14-140-72-72-m-90-iso8859-1


Here's another example:

$ printarg.d fopen 0 -c dtcalc
fopen: arg0=/home/uejio/.Xauthority
fopen: arg0=/usr/openwin/lib/locale/locale.alias
fopen: arg0=/usr/openwin/lib/locale/locale.dir
fopen: arg0=/usr/openwin/lib/locale/locale.alias
fopen: arg0=/usr/openwin/lib/locale/locale.alias
fopen: arg0=/usr/openwin/lib/locale/locale.dir
fopen: arg0=/usr/openwin/lib/X11/Xcms.txt
fopen: arg0=/home/uejio/.icons/blueprint-cursor-theme/cursors/arrow
fopen: arg0=/home/uejio/.icons/blueprint-cursor-theme/index.theme
fopen: arg0=/usr/share/icons/blueprint-cursor-theme/cursors/arrow
fopen: arg0=/usr/share/icons/blueprint-cursor-theme/index.theme
fopen: arg0=/usr/share/pixmaps/blueprint-cursor-theme/cursors/arrow
fopen: arg0=/usr/share/pixmaps/blueprint-cursor-theme/index.theme
fopen: arg0=/home/uejio/.icons/default/cursors/arrow
fopen: arg0=/home/uejio/.icons/default/index.theme
fopen: arg0=/usr/share/icons/default/cursors/arrow
fopen: arg0=/usr/share/icons/default/index.theme
fopen: arg0=/usr/share/pixmaps/default/cursors/arrow
fopen: arg0=/usr/share/pixmaps/default/index.theme
fopen: arg0=/usr/dt/appconfig/icons/C/Dtcalc.l.bm
fopen: arg0=/usr/dt/appconfig/icons/C/Dtcalc.l_m.bm


Well, I thought this was pretty cool and so easy to do in DTrace, but your mileage may vary. ;-)

If anyone knows of a simpler way to calculate the args to pass in, please let me know.

Thursday Jun 05, 2008

Difference between deadbeef and baddcafe

No, this is not a posting about food poisoning at a restaurant.

It's about my experience with libumem.  libumem is a very useful and fast preload library for detecting memory corruption and memory leaks. I was working on a bug where the Xserver crashes, but only under libumem. The stack trace showed that a particular function was being called with the first argument equal to "deadbeef".  Something like:

(dbx) where
=>[1] SizeDeviceInfo(0xdeadbeef, 0xffbfed44, 0xffbfed40, 0x1f, 0x58, 0x52d1c8), at 0xff0ee260
  [2] ProcXListInputDevices(0xda1188, 0x1, 0xffbfed44, 0xdeadbeef, 0xff102000, 0xffbfed40), at 0xff0ee0f8

Well, actually it is 0xdeadbeef.  This is a special constant that libumem uses.  I thought it was for an uninitialized variable and kept looking for that in the code, but I couldn't find it. But, after reading the manpage for umem_debug(3MALLOC) it turns out that the constant for uninitialized variables is "baddcafe". "deadbeef" is used to show that a chunk of memory has been freed. So, basically I was trying to access freed memory.  So, it was just a matter of stepping thru the code and looking to see where the memory got freed.

It turns out that the bug was that a data structure was being freed and then a field of that structure was being accessed.  Something like:

free(dev);
...
newdev = dev->next;


So, I just fixed it to do:

...
newdev = dev->next;
free(dev);


(The code was a bit more complicated than that...)

D'oh!  Fortunately, not much was happening in the "..." so the code only crashes under libumem or other memory checkers.  But, if more code was added in that section, there could be some strange behavior that would be really hard to track down.

Here's a link to someone else's experience with libumem and accessing freed memory.  I should really blog more about using mdb and libumem one of these days...

Saturday May 03, 2008

Another acronym for JAVA

I went to DC a couple of weeks ago and at the Cherry Blossom Festival, I saw sign that said "JAVA", but it wasn't from Sun:

 

Their website is at javadc.org.  From their about page: "This is an umbrella website representing a number of Japanese American Veterans' organizations throughout the United States."  It looks like some sites are still under construction, but have a look anyway.


Wednesday Nov 14, 2007

DTrace Tutorial for X Window Programmers

Here's some notes on a DTrace presentation I gave to our desktop sustaining group. It's geared towards application debugging esp. for X Window System programmers and not for kernel debugging.

DTrace is usually thought of as a tool for kernel debugging. However, I have found it very useful for user level debugging, too. It's especially useful when first debugging an issue that you don't know where to begin and for issues involving applications that are already running.

I usually use DTrace for debugging the call stack.  That is, trying to figure out what functions are being called, by whom, and with what arguments.  DTrace also lets you look at return values. I've also used DTrace for performance issues such as determining how many times a function is called and how long that took.

Useful One-liners:

Here are some one-liners for client debugging.  There are a number of useful ones from Brendan Gregg's website at:

http://www.brendangregg.com/DTrace/dtrace_oneliners.txt

Here's one which prints out new processes:

dtrace -qn 'syscall::exec\*:return { printf("%Y %s\\n",walltimestamp,curpsinfo->pr_psargs); }'

If I run gnome-terminal, I see the following output:

2007 Nov 14 16:56:17 gnome-terminal
2007 Nov 14 16:56:18 gnome-pty-helper
2007 Nov 14 16:56:18 pt_chmod 4
2007 Nov 14 16:56:18 /usr/lib/utmp_update testuser /5 pts/5 19917 7 0 0 1195088178 373248 0 000000000
2007 Nov 14 16:56:18 bash

Here's one for looking at files opened by processes:

dtrace -n 'syscall::open\*:entry { printf("%s %s",execname,copyinstr(arg0)); }'

If I run gnome-terminal again, I get a lot of output:

...
  0  43837      open64:entry gnome-terminal /usr/share/themes/blueprint/gtk-2.0/vertStepDwnButton.png
  0  43837      open64:entry gnome-terminal /usr/share/themes/blueprint/gtk-2.0/menuBorderButton.png
  0  43453      open:entry nscd /etc/user_attr
  0  43453      open:entry utmpd /proc/19924/psinfo
  0  43453      open:entry gconfd-2 /export/home/testuser/.gconf/apps/panel/profiles/default/applets/...
  0  43453      open:entry gconfd-2 /export/home/testuser/.gconfd/saved_state.tmp
...

Try doing this with dbx or truss or any other tool, especially the first example!

Some things to notice about these one-liners:

The -q option means "quiet".  The -n means that the next argument is a probe name.  In these examples, we're looking at system calls so we use the syscall provider and then specify which function call and that we're looking at the entry to a function.  This probe fires at the entry to the function.

The arguments to the function are accessible via the variables arg0, arg1, arg2, etc.  So, in the open example, we're printing the first argument to the function open which is the pathname.  For strings variables, you need to use the copyinstr() function to print the contents of the string.  For integers you don't have to do any special conversion.

However, I found that it's not usually system calls that I want to look at, but rather user library calls.  Unfortunately, you can't just do something like:

# dtrace -n 'syscall::XOpenDisplay:entry'

You will get the error:

dtrace: invalid probe specifier syscall::XOpenDisplay:entry: probe
description syscall::XOpenDisplay:entry does not match any probes

DTrace only knows about system calls, but you can use the pid provider to look at all the calls in a particular process.  For example "dtrace -l" will list out the probes. You can limit that also with -n.  Let's look at the probes for metacity for an Xlib call XMoveWindow:

dtrace -l -n "pid`pgrep metacity`::XMove\*:"
   ID   PROVIDER            MODULE                          FUNCTION NAME
44083   pid19834       libX11.so.4                       XMoveWindow return
44084   pid19834       libX11.so.4                       XMoveWindow entry
44085   pid19834       libX11.so.4                       XMoveWindow 0
44086   pid19834       libX11.so.4                       XMoveWindow 1
...


Lots of output.  There are probes for both entry and return points and also arbitrary instructions.  You could trace the execution of instructions within a function as well.  However, I find dbx is probably a much easier tool to use for doing that.

In my examples, I'm only going to mention entry and return points.

So, now, let's take a look at a simple DTrace script, libX11.d. This script  just traces all calls to libX11:

# ./libX11.d `pgrep gnome-terminal`
dtrace: script './libX11.d' matched 1629 probes
CPU     ID                    FUNCTION:NAME
  0  44400                   XPending:entry
  0  44401             _XEventsQueued:entry
  0  44326                    _XFlush:entry
  0  44309                 _XFlushInt:entry
  0  44402     _X11TransBytesReadable:entry
  0  44403 _X11TransSocketBytesReadable:entry
...

Wow, lots of calls to XPending() and other functions.  We probably don't want to debug those, so before we remove them, we can format the output nicer by adding to the libX11.d script:

#pragma D option flowindent

Now we can see that XPending is calling these functions and that's probably not a very interesting function to look at, so, we can get rid of them by setting a flag in the entry probe to XPending(). Then in the return probe of XPending unset the flag.  When the flag is set, don't print out the function calls and when it is not set, then print out calls.

However, I'm also going to remove the flowindent because the indenting is sometimes annoying.  Also, I'm going to add a "quiet" option which will cause DTrace to not print out every probe that fires. So, I need to add my own printfs.  This results in, libX11_pending.d:

# ./libX11_pending.d `pgrep gnome-terminal`
XNextEvent called
_XDeq called
XFilterEvent called
XNextEvent called
_XDeq called
...
XChangeGC called
_XUpdateGCCache called
XChangeGC called
XChangeGC called
XSetClipRectangles called
_XSetClipRectangles called
XSetTSOrigin called
XFillRectangle called
...

So, we see lots and lots of libX11 functions being called.  Well, this also is too much information and probably not useful.  Suppose, we wanted to instead limit the calls to a specific type of call.  So, let's look at the next example.  libX11_grab.d.  This example prints out all the calls to any Xlib grab functions.  It also prints out the stack trace of the user process (gnome-terminal in this case) whenever the grab or ungrab function is called.  Printing out stack traces for grabs can be a problem when running in dbx since you probably can't type in the dbx window if client has a keyboard or pointer grab. So, DTrace is definitely the better tool here. In this example, I press the mouse button on the Edit menu item and get a popdown menu.

# ./libX11_grab.d `pgrep gnome-terminal`
XGrabPointer called

              libX11.so.4`XGrabPointer
              libgdk-x11-2.0.so.0.400.9`gdk_pointer_grab+0x180
XGrabKeyboard called

              libX11.so.4`XGrabKeyboard
              libgdk-x11-2.0.so.0.400.9`gdk_keyboard_grab+0x6c
...

More Complex Examples:

Now let's look at a complex example involving two processes.  Suppose, we want to know what happens in one processs when another process calls some function. The script trace2processes.d takes 3 arguments--the process id of the two processes and the function to key off of.  For example, if I want to know what the Xserver is doing when metacity calls XMoveWindow(), I would execute:

# ./trace2processes.d `pgrep Xnest` `pgrep metacity` XMoveWindow
metacity: XMoveWindow: enters
metacity: XMoveWindow: returns
Xnest: xnestGetImage: return = 1
Xnest: WriteToClient: entering
Xnest: WriteToClient: return = 2400
Xnest: DoGetImage: return = 0
Xnest: ProcGetImage: return = 0
Xnest: FlushAllOutput: entering
...

In my example, I am using the Xnest server since I was demo'ing this via a VNC session to engineers in Ireland and India and had Xnest running in VNC.

Here's another example, xscope in DTrace:

xscope.d

This shows how to use some of the Xserver probes to implement a simple DTrace version of the X debugging tool called xscope. Xscope is a tool for viewing the X protocol between client and server.

It's a pretty complex example.

First, I need to run DTrace with -C option so that it uses the preprocessor to parse the #include lines.  Then, I need include X11 header files.  However, I can't include X11/Xlib.h because there is a structure which conflicts with DTrace  So, not all Xlib structures can be used in DTrace. Unfortunately, the most important structure that you can't access is the Display structure. The xscope.d script shows an example of how to cast structures in DTrace such as casting the xEvent structure to show the component fields of an XEvent. The output of xscope is detailed in an earlier blog here.

Handy DTrace scripts from the DTrace Toolkit at:

http://www.brendangregg.com/dtrace.html#DTraceToolkit

I've used:

execsnoop - Traces execs of all processes.

dtruss - Truss written in DTrace  Runs much faster than truss so it can be very useful when truss is too slow.

Also:

memleak.d - from http://blogs.sun.com/sanjeevb/.  Lists memory leaks using DTrace.  Much faster than libumem and good when dbx access checking fails.

But, mostly, I modify one-liners from:
http://www.brendangregg.com/DTrace/dtrace_oneliners.txt

Sorry, I don't know of any way to detect memory corruption using DTrace.  

Tuesday Nov 06, 2007

xscope in dtrace ver. 0.1

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.

Monday Nov 05, 2007

Experience with OpenSolaris Developer Preview Live USB

Last year,  I tried running Belenix OpenSolaris Live USB and have been wondering how to run Solaris from a live USB.  I just haven't had time to play with it, but with the recent announcement of the OpenSolaris Developer Preview, I thought I'd give it a try again.  Thanks, to Alan for providing me with various links on how to get the USB flash image (see here for one way), I was on my way. 

I got an internal copy of a flash image and downloaded it to my Acer 3400 laptop running Solaris 10.  I first tried the  usbdump.sh script from Belenix, but my flash image was not an ISO image.  Fortunately, a fellow blogger posted instructions on using a command called usbcopy.  Unfortunately, I didn't have usbcopy on my Solaris 10 machine.  So, the instructions said to use mercurial. But, I didn't have that either...

Fortunately, I could download mercurial from blastwave and after an hour or so of fiddling and downloading dependent packages (mostly due to the fact that I had run out of disk space in "/") I was able to run usbcopy. 

Finally, I ran it and got:

Found the following USB devices:
Enter the number of your choice:

There were no devices listed!  D'oh!

I took a look at the usbcopy command and it was parsing the output of rmformat. I ran that command by hand and it showed my Kingston 1.0 Gb USB stick:

     3. Logical Node: /dev/rdsk/c4t0d0p0
        Physical Node: /pci@0,0/pci1025,57@10,3/storage@3/disk@0,0
        Connected Device: Kingston DataTraveler 2.0 PMAP
        Device Type: Removable

But the size and bus type were missing.  Hm...  Now what?  Well, I looked closely at the usbcopy script and found that it was just getting the logical device name and then running fdisk and format on the drive.  Then, it copied the contents using dd and finally added the boot sectors with installgrub.  So, I did all that by hand (I had to disable volume management first):

# svcadm disable volfs
# fdisk -B /dev/rdsk/c4t0d0p0
# format -e /dev/rdsk/c4t0d0p0

I partitioned the drive as a single root partition using the entire disk from starting cylinder 1.  This is what the usbcopy script was doing, so I just copied that.

Then, I ran the dd command and about 20 minutes later it was done.  I forgot to save the output of the command, but for future use, the output device was /dev/rdsk/c4t0d0s0.  Then I ran the installgrub as in the usbcopy script.  And I was done, but "will it blend?"

Amazingly, "YES!".  I was so happy that I even attempted to explain this to my wife whose eyes  began to glaze over and she immediately changed the subject... Ok.  So, maybe my son is right.  I am a nerd (or at least a geek).

BTW, to boot off the USB drive on an Acer 3400, you have to insert the drive before powering on the computer.  Then, press the F2 key for the setup screen and select the hard drive as the boot disk. The hard drive will contain two entries: one for the hard drive and one for the flash drive.  Move the flash drive above the hard drive using the F5 or F6 key.  Then save and boot up. 

Also, don't forget to read the release notes to get the default user and root passwords... 

So, OpenSolaris booted up fine from the Live USB drive and I was surprised at how usable the performance was even running from a USB drive.  It connected automatically to my router (hardwired) and I was able to get to my work email using Thunderbird.  Firefox 2.0.0.8 works great.  Infact, I'm typing this blog from it.  Although, I noticed that the fan on my laptop keeps running.  I guess there's still some issues with power, but this is a developer preview after all.  I don't want to upgrade my Solaris 10 image to it just yet, but maybe soon!

Now to take this USB stick to some other laptops and see how it runs there...

 

Monday Feb 26, 2007

DST changes in two weeks (Sun Alert 102775)

An issue that I've been working on lately has been to evaluate the effects on the CDE calendars from the new Daylight Savings Time changes for the US and a few other countries.  The new DST starts March 11 this year. 

Patches created for the Solaris Operating System will fix the issues related to the CDE calendar manager (dtcm) and calendar server (rpc.cmsd).  Unfortunately, appointments which  were created before the patches were installed and which are starting in the new DST period (between March 11 and April 1 and between Oct 28 and Nov 4) may have to be recreated.   For more information on the DST issues in Solaris see Sun Alert 102775.

In addition, Sun has a site which gathers all the DST issues for Sun products at: http://www.sun.com/bigadmin/hubs/dst/

Growing up in Hawaii which doesn't observe DST, I never understood why it was needed.    Infact, I wonder why everyone doesn't just use GMT.  It would make traveling and coordinating meetings across timezones so much easier.  Of course it would be a little confusing since I would eat breakfast at 4 pm, have lunch at 8 pm., dinner at 3 am. and go to bed at 7 am.   Hm...  Maybe that would not be such a good idea after all...

 

Wednesday Dec 27, 2006

Playing with Belenix OpenSolaris LiveUSB

After reading Jonathan's blog a few weeks ago, I really wanted to try running OpenSolaris from a  LiveUSB. Unfortunately when I read that blog, I only had a 512 Mb flash drive, so I shopped around and finally bought a Kingston 1Gb drive on Amazon for about $25. I had also had an old Belenix LiveCD 0.4.2 lying around, so I thought I would try that first. 

I downloaded the latest disk image of the the Belenix LiveCD (which was 0.5.1) and the usbdump script and put them in my home directory on my Solaris 10 partition on my Ferrari 3400 laptop.  Then, I booted up the old Belenix LiveCD 0.4.2 and it worked fine.  It even automatically mounted my home directory from the Solaris 10 partitition in /mnt/solaris1.

I ran the usbdump.sh script:  

# ./usbdump.sh /mnt/solaris1/uejio/belenix0.5.1.iso

It did give me a nice WARNING saying that all data on my USB device would be destroyed.   I also got a few other errors such as:

umount: warning: /mnt/microroot not in mnttab

and some other error about a missing  stage1 file from the installgrub command.  That didn't sound good.

Next, I tried to boot from my USB drive.  That actually is kind of tricky on my Ferrari 3400.  I thought there might be some BIOS setting to boot from USB, but could not find any.  Finally, I searched the net and found that I needed to set the BIOS to boot from harddisk.  When I select the boot menu, the harddisk had a little plus sign to the left of it.  When I selected it, I saw two entries: one for my harddisk and the other for the flash drive.  The flash drive must be plugged in before turning the computer on.  Once I had that set, my laptop tried to boot from the flash drive, but then I got a "bad PBR sig" or something like that.

Oops... I guess I shouldn't have ignored that error from installgrub.  So, back to booting the Belenix LiveCD.  But, then I thought to myself, why can't I just boot from my Solaris 10 partition and run installgrub from there?  That would be much quicker since I'm booting from the harddisk instead of CD.  (Infact, why can't I try running usbdump from Solaris 10?  I'll have to try that someday.) 

After looking at the usbdump.sh script, I found that it does:

# cd /boot/grub
# installgrub -mf stage1 stage2 $devs > /dev/null

Fortunately, Solaris 10 has the stage1 and stage2 files in /boot/grub, so I disabled volfs and ran the installgrub command.  I used the rmformat to tell me where the USB device was and used d0s0 instead of d0p0.  (I'm not really sure what I'm talking about, though.)

So, after all that, I tried booting from the flash drive again.  The darn Ferrari doesn't seem to save it's boot settings, so I had to select F2, then from the boot menu, select the "+harddisk" and move the flash drive above the harddisk.  I wish is would save that setting so I don't have to keep doing that...

Finally, here I am running Firefox 2.0. from Belenix 0.5.1 off of a liveUSB!

Next to try: getting Solaris installed on a liveUSB similar to "World's smallest bootable Solaris media?"

I think I'll save that for another holiday.

Wednesday Oct 18, 2006

Photos of Sun Products

Did you know that Sun has a website for its brand and also for photos of its products?  The photos are at http://photos.sun.com.  So, now when someone asks me what an Ultra 20 looks like (we just got a few in our lab), I'll point them here.

 
Someone must have had a lot of fun putting together these scenarios for Project Blackbox...

Tuesday Oct 17, 2006

Blackbox Tour on YouTube

I missed the demo on Project Blackbox at work today.  But, I found a link to a YouTube video by Sun.  Enjoy!


(If anyone knows how to embed the flash player directly into my blog entry, please let me know.  Thanks!)


Monday Feb 13, 2006

JDS Applets May Exit Unexpectedly (SunAlert 102039)

Just finished getting the last patch released for Sun Alert 102039, JDS applets may exit unexpectedly.

This affects Gnome 2.6 on Solaris 9 on x86 and JDS for Solaris 10 (both Sparc and x86). The root cause was a fix to the Xserver/Xlib to return an XError for certain large requests which the panel applets were incorrectly making. So, if you have the latest Xserver patches for Solaris 10, (patches 119370-09 or 119371-09 or greater) and you are using JDS as your desktop, then you should probably install the patches to a gnome-panel library for this Sun Alert.

Sun Alert Notifications are accessed on Sun Solve Online by clicking on "Browse Documents", selecting "Free Sun Alert Notifications" and then clicking the "Browse" button. You can also subscribe to the weekly Sun Alert Notifications email by clicking on http://sunsolve.sun.com/pub-cgi/show.pl?target=salert-notice and filling in your email address.

Thursday Dec 15, 2005

dtrace for S9 wish

While debugging an Xlib issue on Solaris 9, I sure wished dtrace was available for that OS. I just wanted to see when the values of width and height to the XCreatePixmap call were greater than a certain value. A simple dtrace script such as:

#!/usr/sbin/dtrace -s
 
pid$target:libX11:XCreatePixmap:entry
/arg2 > 4095||arg3 > 4095/
{
	printf("width=%d, height=%d, depth=%d\\n",arg2,arg3,arg4);
}

would have done the trick. But, since dtrace isn't available for S9, I ended up creating a preload library and used LD_PRELOAD. So, something like:

#include <stdio.h>
#include <dlfcn.h>
#include <X11/Xlib.h>
#include <X11/Xresource.h>
#include <X11/Xatom.h>
/\* 
   compile with:
   cc -I/usr/openwin/include -o preloadpixmap.so.1 -G -K pic preloadpixmap.c
   then:
   setenv LD_PRELOAD ./preloadpixmap.so.1
\*/

Pixmap XCreatePixmap(display, d, width, height, depth)
     Display \*display;
     Drawable d;
     unsigned int width, height;
     unsigned int depth;
{
  Pixmap pix;
  static void \*(\* fptr)() = 0;
  if (fptr == 0) {
    fptr = (void \*(\*)())dlsym(RTLD_NEXT,"XCreatePixmap");
    if (fptr == NULL) {
      (void) printf("dlopen: %s\\n", dlerror());
      return NULL;
    }
  }
     if ((width>4095)||(height>4095)) {
        printf("XCreatePixmap: width=%d, height=%d, depth=%d\\n",
		width,height,depth);
     }
  pix = (Pixmap)((\*fptr)(display,d,width,height,depth));
  return pix;
}

dtrace would have been soo much easier...

 

Tuesday Dec 06, 2005

dtrace RFE--probe user functions across processes

I finally learned to use dtrace. I attended a talk by Bryan Cantrill on dtrace at a Solaris Desktop Summit organized by John Rice. Bryan is a great speaker. He is incredibly knowledgable, animated, and makes learning dtrace exciting. He covered so much material in a short time that I probably followed only about half of it, but that was enough to get started fiddling with it.

One thing that it would be nice to have in dtrace is the ability to probe user library functions across processes. dtrace does this very nicely for system calls, but not for any arbitrary function in userland. For example, I might want to find out how many calls to some GTK library function were made when logging in to JDS by all GTK apps. I can do this for one app using pid$target, but I couldn't figure out how to do this for multiple apps and aggregate for all apps. Again, this is for any arbitrary function in user space and not system calls. I didn't get a chance to ask Bryan this question, but other dtrace experts said that it can't be done. Rats. (I remember the days when truss couldn't follow user libraries and I was so happy when we added the -u option to trace any lib including a.out.)

I'm still excited about dtrace and look forward to using it in my daily work. Thanks Bryan!

I should also remember to blog about the Solaris Desktop Summit which so far has been a great success...

 

About

uejio

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today