Frysk logo Home  |  Wiki  |  Use Cases  |  Work Flows  |  FAQ  |  Get Involved  |  Bugzilla  |  Build  |  Blog  |  Documentation

More Questions?

Bugzilla Questions?
Build and Test Questions?

If your question isn't answered, post it to the frysk@ mailing list or ask it on IRC.

Some frysk Questions, With Answers

Is frysk Free?
frysk is available under a "GPL + Exception" license. You can read the license on the license text page or get more information on the annotated license text page.
What is an Execution Analysis Tool?
An Execution Analysis Tool emphasizes being able to examine, analyze, monitor, and visualize an application as it continues to execute normally.

With frysk, other operations to more directly control and manipulate the application (such as starting and stopping threads, or modifying variables) are also available.

How does frysk compare to other execution analysis tools, such as oprofile and systemtap?
frysk oprofile systemtap
Strictly user mode Require kernel modules
Requires elevated privilege
Require kernel modules
Requires elevated privilege
100% reliable information Uses sampling 100% reliable information
Active control: can stop or restart a single thread, a process, or an entire application N/A Passive
How does frysk compare to a traditional command-line debugger, such as adb or sdb?
Here is a quick comparison table that highlights some of the differences:
traditional frysk
single thread; single process; single host multi-thread; multi-process; multi-host
either the program is running or it is stopped—there is no middle ground non-stop: threads, processes, and hosts can be monitored individually or as a group; by default all are left running
explicit attach: the user must explicitly start or attach to a process under the debugger's control; operations are strictly limited to the process currently under the debugger's control always on: the user specifies the operation, frysk handles the details (attaching if and when needed)
explicit control: the user must explicitly stop, start, or otherwise control the program event driven: the user specifies the events of interest (program start, exec call, variable change, ...), frysk handles the details
command-line based graphical, visual
assume unoptimized C assume optimized, inline, multi-threaded, object-oriented, and event-driven code
debug information loaded immediately, kept in memory debug information loaded on demand, left on disk, or on the server
implemented in C; single-threaded, procedural, blocking and polling implemented in Java and C++; multi-threaded, object-oriented, event-driven
Will there be a scripting language?
Because the frysk core is directly programmable, the addition of a scripting language such as Guile, Perl, or Python is more than feasible. In fact, there have already been multiple proposals to directly integrate jython into frysk.
As for which scripting language? That choice is yours.
Will there be a command-line interpreter?
Because the frysk core is directly programmable, the addition of a command-line interpreter such as the High-Performance Debugger Forum Interface or ADB is more than feasible. In fact, the code base already contains a skeleton of the HPD command-line.
Will there be stand-alone utilities?
frysk's modular design makes possible the implementation of stand-alone utilities including ftrace and fstack.
Why is frysk written in Java?
Why not use the systems programming language of choice, C?
frysk is principally written in native Java. Where performance is a significant factor, or where system interfaces are involved, C++/CNI has been used. This has a number of advantages:
  • Those developers who are focused on the rapid development of domain object models and graphical interfaces have access to a modern, object-oriented garbage-collecting language.
  • It avoids the quagmire that comes with fudging objects using a procedure-based language.
  • It provides a solid overlap between developers and users: software engineers working on large, multi-thread, multi-process, object-oriented, distributed applications.
Why use the Java-Gnome Toolkit?
Like anything, there is a trade off. Below is a quick comparison table highlighting some of the differences. The requirement is for a modern, lightweight toolkit that provides a native look-and-feel, relying only on Free tools.
  Swing SWT Java-GNOME
  • Mostly JVM independent
    (but is the Free JVM complete?)
  • Native look and feel, sort of
  • Some local knowledge
  • Modern toolkit
  • Some momentum
  • glade GUI builder
  • dogtail GUI tester
  • Not native look-and-feel
  • Not really cross-platform
  • Is the Free implementation complete enough?
  • Free gui builder?
  • Free testing tool?
  • Not true native look-and-feel
  • Somewhat messy
  • Free gui builder?
  • Free testing tool?
  • Under development (mature?)
Will frysk be integrated into Eclipse?
The frysk core is designed with direct and tight integration into the Eclipse IDE in mind. However, the more immediate need is to provide users with a light-weight, standalone, graphical tool that wraps around the frysk core.
Does frysk replace the traditional command-line debugger?
However, traditional debugger users will appreciate frysk when they take on challenging tasks such as analyzing large, complex applications.
Why doesn't GCC enable -fasynchronous-unwind-tables by default?
See [PATCH] PR 16373: -fomit-frame-pointer when optimizing on x86 and [PATCH] Omit frame pointer and fix %ebp by default on x86 (take 3).