Archive for June, 2007

notify-send

June 6, 2007

First of all I would like to give a big shout out to the folks who wrote libnotify. Libnotify standarized gnome notification solution, and they did a good job of it. The popup widget allows you to add buttons, images, and they look very good.

notify-send is a command line utility that makes uses libnotify to send notifications the the user.

for example:

notify-send hi

shows this:

notify-send.png

As soon as i discouvered this I started using it to notify me when my build is finished. So:

 

make && notify-send DONE!

Then I got fancier and I added this to my .bashrc:

alias saydone='notify-send "Done! `if [ \$? = 0 ]; then echo \:\); else echo \:\(; fi`"'

no explanation nessesary of course.

so now I do;

../frysk/autogen.sh ; saydone

If the autogen returns a 0 i get a smily face, otherwise I get a frowny.

saydone.png

Now for the bash guros out there. How do i make it print the previously run command so that the notification says “../frysk/autogen.sh finished :)

Interns and Ex-terns part-2

June 1, 2007

Okay so in the previous post I said I will tell you about the CatchError. Well here is the code: CatchError.java

So lets take a closer look at the critical parts of the code.

public static String myError;

public static void main (String[] args)
{
  //some argument parsing
  //...
  Manager.host.requestCreateAttachedProc(myArgs, attachedObserver);
  Manager.eventLoop.run();
}

In the above code segment we do some argument parsing, we ask the host object to create an attached Proc and we start the event loop. The rest of the juicy details happen in attachedObserver:

static TaskObserver.Attached attachedObserver = new TaskObserver.Attached(){

  public Action updateAttached (Task task)
  {
    task.requestAddSyscallObserver(syscallObserver);
    return Action.BLOCK;
  }

  public void addFailed (Object observable, Throwable w){}
  public void addedTo (Object observable){}
  public void deletedFrom (Object observable){}
};

Very simple. When updateAttached is called we are being told the process has been created, attached, is block very early in its life time, and waiting for instructions. So we attempt to add a syscallObserver to it, and make sure to return Action.BLOCK so that the process doesnt slip through our fingers before syscallObserver is watching those naught write calls.

syscallObserver does all the heavy lifting:

static TaskObserver.Syscall syscallObserver = new TaskObserver.Syscall(){
  public Action updateSyscallEnter (Task task)
  {
    SyscallEventInfo eventInfo = task.getSyscallEventInfo();
    frysk.proc.Syscall syscall = eventInfo.getSyscall(task);

    if(syscall.getName().equals("write")){
      long address = syscall.getArguments(task, 2);
      StringBuffer x = new StringBuffer();
      task.getMemory().get(address, 200, x);
      String xString = new String(x);

      if(xString.contains(myError)){
        Frame frame = StackFactory.createFrame(task);
        System.out.println("we got it! here is a stack trace:n" +
        StackFactory.printStackTrace(frame));
      }
    }
  return Action.CONTINUE;
  }

  public Action updateSyscallExit (Task task)
  {
    return Action.CONTINUE;
  }

  public void addedTo (Object observable)
  {
    Task task = (Task) observable;
    task.requestUnblock(attachedObserver);
  }

  public void addFailed (Object observable, Throwable w){}
  public void deletedFrom (Object observable){}

};

updateSyscallEnter gets called telling us that a syscall is happening, we check if it is a write, if so we retrieve its string argument, and figure out if it is trying to write the string that we are interested in. If so, we ask frysk to extract a stack trace at that point in the procs life time. One thing to point out that I guess might not be obvious is that we actually get notified while the system call is happening, and during the execution of the code inside updateSyscallEnter, the task is actually stopped during the stack call that resulted in the syscall so it is a good point to extract a stack back trace.

Another interesting part in syscallObserver is this:


public void addedTo (Object observable)
{
  Task task = (Task) observable;
  task.requestUnblock(attachedObserver);
}

If you remember earlier we told the task to stay blocked, well we have to unblock it so it can go on to exec, and make all those write calls. This is a good point to unblock it because we are now sure that the syscallObserver has been added. Also note that the api to unblock a task requires you to pass in the object that requested the block. This is to prevent any unintentional unblocking of tasks. That is to say that a task is not unblock until all parties that requested blocks have signed off.

It was pretty cool to use eclipse to do this. Code completion allowed me to focuse on frysk rather than java, and syntax errors. Also, I was able to finish coding in ~35 minutes.

Interns and Ex-terns part-1

June 1, 2007

Here at Red Hat Toronto we have a very lively internship program. Every year we hire a few interns and they stay with us for 16 months terms during which they make significant contributions to the various development projects that we have at Red Hat Toronto.

I started as an intern at Red Hat, so as an Ex-tern I was asked to give a talk on Frysk to the new interns. I though what better ways to introduce Frysk than show them some code. So, for the second half of the presentation we wrote a useful little Frysk command line utility called CatchError.

Ever had a program you are working on or using crash on you printing some random error message to the terminal ? Well I have :) When we worked together in the monitor phil and I used to get errors like this all the time:

 (Frysk:19767): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)’ failed

There was just no way to figure out what exact sequence of events resulted in this error. The tool we wrote yesterday allows you to get more information about that sort of error.

Given a string of an interesting error CatchError will monitor all the write system calls that your program makes until it tries to write the given string. At that moment CatchError pulls a stack trace and prints it to terminal. In the above example this will allow you to narrow things down to one set of GObjects out the the thousands that are swimming around. The utility ended up being around 100 lines of code, about 20 of which I wrote and the rest was eclipse generated :) .

In the next episode I will post the code and go through it. Stay tuned.


Follow

Get every new post delivered to your Inbox.