ProductsDesktop Server For Scientific Computing For IBM POWER For IBM System z For SAP Business Applications Red Hat Network Satellite ManagementExtended Update Support High Availability High Performance Network Load Balancer Resilient Storage Scalable File System Smart Management Extended Lifecycle SupportWeb Server Developer Studio Portfolio Edition JBoss Operations Network FuseSource Integration Products Web Framework Kit Application Platform Data Grid Portal Platform SOA Platform Business Rules Management System (BRMS) Data Services Platform Messaging JBoss Community or JBoss enterprise
SolutionsApplication development Business process management Enterprise application integration Interoperability Operational efficiency Security VirtualizationMigrate to Red Hat Enterprise Linux Systems management Upgrading to Red Hat Enterprise Linux JBoss Enterprise Middleware IBM AIX to Red Hat Enterprise Linux HP-UX to Red Hat Enterprise Linux Solaris to Red Hat Enterprise Linux UNIX to Red Hat Enterprise Linux Start a conversation with Red Hat Migration services
TrainingPopular and new courses JBoss Middleware Administration curriculum Core System Administration curriculum JBoss Middleware Development curriculum Advanced System Administration curriculum Linux Development curriculum Cloud Computing and Virtualization curriculum
ConsultingStandard Operating Environment (SOE) Strategic Migration Planning Service-oriented architecture (SOA) Enterprise Data Solutions Business Process Management
October 12, 2006
- Introducing Fedora Core 6
- Fedora status report: Announcing Zod
- Enterprise 2.0: Trendy term, real revolution
- Dogtail's object oriented tree API (and how to use it)
- Creative Commons comic: A Spectrum of Rights
- Ask Shadowman
- Tips & tricks
- Truth is happening
- >> more
Got a nasty bug you can't replicate in your test environment? Frysk lets you monitor and debug in real time. Find out how to rapidly locate and squash the bugs that plague your open source app.
The Frysk Monitor
by Sami Wagiaalla
One of the ways Frysk can be used is as an execution analysis tool.
"What is an execution analysis tool," you ask?
An execution analysis tool is a piece of software that enables a user to monitor the execution of a program in anticipation of problems. And when those problems occur, it enables that user to dive in and analyze those problems through the tools provided by a traditional debugger.
Frysk, then, is a non-traditional debugger. It does, of course, provide the functionalities provided by all debuggers, but it can also be used to monitor the debugee before the problems occur. Plus it gives the user a chance to debug while the debugee is still alive and the problem is still present.
Some of the functionalities of Frysk were addressed in the article "Frysk: Debugging or Monitoring Tool?" by Rick Moseley, published in the previous issue of this magazine. This article will focus on the monitoring side of Frysk.
Before we dive into the details of the Frysk Monitor, let's talk about its grand goal. As mentioned by Rick in his article, one of the requirements given by the Red Hat Customer Advisory Board (CAB) members is that the desired tool should be able to debug large-scale multi-threaded applications, and even problems that may span more than one application.
How does one debug an application with a thousand threads? How does one display this large sum of information in an abstracted way that is still relevant to the user? How does one allow the user to request more information when required? These are the grand goals of the Frysk Monitor.
Sound tough? I agree.
The first window the user sees when he or she runs Frysk is the Startup Manager Dialog.
The Startup Manager allows the user to choose the mode they would like to run Frysk in. The user can debug an existing process, which allows the user to select a process and go directly to a source window where he or she can debug it much as one would do with a traditional debugger.
The other two options involve Debug Sessions. A session is a way to narrow down the focus of Frysk Monitor, and Frysk in general, to the process or processes that the user is interested in. In the Startup Manager, the user also has the option of opening a blank session with a terminal. A session with a terminal gives the user a Linux command line terminal, and the session is then populated with the processes that are run from under that terminal. The user can also create a new session or open one that they have previously created.
New takes the user to the Create Session Assistant. There the user gives a name to the session and chooses the processes that he or she is interested in by moving them from the list on the left, representing all the processes currently running in the system, to the list of the right.
The process groups list groups together processes that have a common executable. The reason for this is that the executable path, as opposed to the ID of a process, remains relevant even when Frysk is restarted. A process ID could have been claimed by another process or it could no longer refer to a process at all. Hence, the user only selects the executable path and Frysk is then responsible for populating the session with processes that have that path.
Next takes the user to the next page where they can choose the observers they want to add to these processes as well as create custom observers. Observers and Custom Observers will be addressed in detail later in this article. Clicking
Finish ends the session creation process and starts the Frysk Monitor.
The Frysk Monitor is composed of three main sections: the process view on the left, the status view on the top right, and the log on the bottom right.
Processes view shows the list of processes on which the current session is focused and displays some information about them. As can be seen here, this session only has one process: the
firefox-bin we selected when creating the session. The right-click context menu allows the user to manipulate these process and add observers to them.
Status view contains event traces for each process in the session and each thread belonging to each one of those processes. The traces basically display a line each time an event occurs. For example, an observer that has been added to that process/thread fires. Hovering over an event line displays more information about the event. Future development plans include enabling the user to click on an event line and go to the relevant area in the source code. In this screen shot we can see that the process called funit-child has just made a clone system call resulting in a new thread being added to the process.
As Frysk implements more observers, the user will be able to add an observer to watch for virtually any event in the process' code. The resulting traces provide the user with an abstracted view of the process space that hides the gory details--until they are required--while still correctly modeling process behavior.
This abstraction and correct modeling is exactly what users seek when they use
The third part of the Frysk Monitor window, the
Main Log view, is currently utilized to print statements logged by observers when they fire.
The observer paradigm is one of the fundamental design concepts Frysk. The Frysk core communicates to the GUI only though requests and events. Observers are the clients that listen for those events and notify the interested parties.
The basic observers provided by Frysk can be customized to a certain extent through the Frysk UI. Through the UI the user can create custom observers by adding filters and actions to them. A
filter is simply a way of more narrowly focusing on one of the parameters of an event received by the observer. And
actions are tasks to be performed once that observer fires. Common examples of actions are spawning a source window showing the current position of execution in the code, and then logging the event.
A simple example of how the primitive Frysk observers can be combined to create more elaborate functionality is the program observer. The job of the program observer is to catch newly-spawned programs precisely at the moment when they start executing their first instruction after the
exec system call. A program observer is basically a fork observer that is added to a process. As soon as that process makes a fork system call, the program observer adds itself to the newly-created child as an
exec observer. When the child calls
exec the program observer catches that event, checks the arguments of the
exec and decides whether this is the executable of interest or not. By adding the Frysk program observer to processes in the system that are commonly responsible for creating new processes (such as
gnome-panel) one is able to catch most events of new processes as they are launched. This is fundamental to Frysk sessions, since now they will be able to correctly populate their process list with newly created instances of the executables that the user has chosen, no matter how short-lived those processes are.
Development continues in high flux on all frontiers of Frysk. Development in the Frysk core will result in observers with much higher resolution than is currently available. Frysk Monitor trace lines are being developed to make them more sophisticated, robust, and flexible. As development continues, and as we continue to come closer to understanding the debugging experience, we hope to see the Frysk Monitor revolutionize debugging, and become the tool that we envision it to be.
How to get involved with Frysk
If you want to become involved with Frysk by working on code, submitting ideas for enhancement requests or just monitoring the development, please visit the Frysk website. Here you can subscribe to the Frysk mailing list or find out where the Frysk developers hang out on a public IRC channel.