Frysk minutes 20060905

[Elena Zannoni <ezannoni at redhat dot com>]

testing: we need to get latest test coverage:
Stan will do today

Dogtail status: still no headless mode. Please Phil, file a bug
against rhel5 and make it a beta2 blocker
Problem also having dogtail rpms built often enough for fc6 and fc5.
There are also bugs in the playback functionality, it doesn't work.
File bugs against RHEL5.

After that: increase coverage of gui testing.

Phil says: please use the gui more often, to find more bugs. Let's not
wait until we have to do a demo. 

Nurdin: write tests for eventviewer as well.

Phil: increase coverage of monitor tests.

Andrew: will try to record/play a demo with dogtail.

Phil: more intelligent handling of the core exceptions/panic: need to
improve that. Currently it's not really doing the right thing. Is there
a way to figure out a severity of the error coming? Not really. 
Please have discussion on mailing list.

Chris: is it possible to do automated testings via cron jobs. Roland
suggests to run everyday in rhts. Can rhts run rawhide?
Len: do you know? Is this possible?

Is anybody running on fc6? Phil is still yum updating. Please run make
check. Mark runs make check on fc6. Some improvements with the latest
patches from Roland. This is from last week.  Are there anymore "the
whole machine hangs" kind of failures? Roland thinks no.
Are there more "make check errors" probably yes. 
Yum update can be automated which would pull in the latest kernel,
frysk cvs update and rebuild can be automated
Chris to try to complete the automation of the above.

Chris: 0xff: can anybody see the same sequence in the frysk logs?
Please reply to Chris.

libunwind: please test Alex patches. Andrew: to review. We can start
plug it into the sourcewindow, in the space reserved for it already.
The patches from Alex are not checked in yet. Please review and check
in asap.

Backtrace window: how does the stack backtrace deal with the inlined
fnctions. Need to tink about this. Libunwind backtrace will not have
inline info at all, you'll need to get this from the debuginfo. So the
frame model for frysk will need to have that information in it.

Rick: on vacation Sept 6 through Sept 18

Adam will have to pick that one up. Together with Mike. We cannot wait
for Rick.

Stan: posted what he has so far. Please review: using CNI, what's in
Java, what's in C++: Comments? Display statics and locals. No frame
support yet. Need to add more addressing modes.  Interfacing to libdw
is in frysk/imports.  How about the command line interface? you can
use print at the moment, but the GUI is not hooked up. 

GUI: hovering over a variable should display values: Hooks are there,
Adam did them. So we need to use those to call into the expression
evaluator. Also have an expression window in the source window: so
that could do cut and paste of expressions.

Eventviewer: fixing scrollbars. Weird errors, if focus is in a
different window. Goes from longer scrollbar to shorter one.  Consult
with other teams, desktop, gnome.  GTK textview code used.  Only these
bugs are left. And writing tests. Try to wrap things up in a week and
a half.

Mark: Breakpoints: Mark: cleaning up syscalls and signals
interoperability with breakpoints. Writing tests too.  Low level stuff
should be done now.  Does the source window have all the necessary
stuff in the DOM? to map addresses to line numbers and vice versa.
One to many? Many to one? Need to make sure we handle multiple
breakpoints for one line. 

Tim: the high level breakpoint task it doesn't need GUI interaction
right now, just manipulate from cli. User in gui will want to click on
source line and set a breakpoint there. DOM has information to handle
that.

First: file:line-->address is first that we should be targetting,
because that is the type of request when user clicks on line in the
source window. The break "foo" stuff is more complicated.

column information is emitted by the dwarf library, but gcc has no
info about this.

Did the syscall tracing get finished? ftrace you cannot track an
already running process. It can ftrace a newly created program,
started under ftrace. ftrace only works on x86, it doesn't really know
about the syscalls on other arches. Didn't IBM have patches for ppc?
It's just the syscall table missing. 

32/64: Table for 32 bit syscalls on 64 bit machines, is different from
pure 32 bit case(?).  Mapping of 32-bit registers in 64-bit mode is
also different.  How do we test this? transition of a 64 bit to a 32
bit back and forth (forking a 32 bit from a 64 bit process and vice
versa). Lots of corner cases. Could IBM look at this for ppc? But Tim
should finish this as he started it.

Disassembly: should it go in the source window as well? Yes. As a
separate pane. This can be started now. Adam?

Phil: concern about Java gnome: spent lot of time tracking a bug in
it, and java-gnome people weren't really helpful. Memory management
problem (premature free). Still not finished. Bug is still there.