The source window when it is inintially brought up and either the "Up One Stack Frame" or "Down One Stack Frame" button is clicked on, a backtrace is generated as follows: java.lang.ArrayIndexOutOfBoundsException: 0 at frysk.gui.srcwin.SourceWindow.doStackDown(SourceWindow.java:1300) at frysk.gui.srcwin.SourceWindow$15.actionEvent(SourceWindow.java:631) at org.gnu.gtk.Action.fireActionEvent(libgtkjava-2.8.so) at org.gnu.gtk.Action.handleActivate(libgtkjava-2.8.so) at org.gnu.gtk.Gtk.gtk_main(libgtkjava-2.8.so) at org.gnu.gtk.Gtk.main(libgtkjava-2.8.so) at frysk.gui.Gui.gui(Gui.java:245) at frysk.gui.FryskGui.main(FryskGui.java:70) If you select a stack frame from the Current Stack window before clicking one of those buttons, all is well. It seems this problem occurs because not stack frame is selected when the window is brought up. Probably the most current stack frame should be auto-selected at start-up. Another item that is in the same vein, once no more stack frames can be selected in a particular direction, that button should be de-sensitized.
More bugs/suggestions from the IBM guys: 1) If we click one frame in StackWindow, appropriate lines are highlighted, but the SourceWindow do *not* adjust the content in it to display the highlighted lines, and always display source code from line #1. Could we make SourceWindow to refresh, and display the highlighted lines in the middle of SourceWindows, when we click on frame? 2) When I click one frame, there are multiple lines are highlighted. For example, If I click "baz" in StackWindow, line #42, #50, and #57 are highlighted at the same time. Is it expected? IMO, we could only highlight the *current* frame, instead of call tree, which has been displayed in StackWindow. 3) Multiple source file is not support. If I put do_it() in tester1.c, and compile the test like this, $ gcc -g tester1.c tester2.c -o test -lpthread and then fire frysk, we could find do_it() in StackWindow, and the line number is #11(the correct line number), but line #11 in tester2.c is highlighted, instead of line #11 in teser1.c.
Log message: 2006-10-10 Mike Cvet <mcvet@redhat.com> * SourceWindow.java (doStackUp): Fixed up for #3327. (doStackDown): Ditto. (doStackBottom): Ditto. (currentStackChanged): Ditto.
Log message: 2006-10-11 Mike Cvet <mcvet@redhat.com> * SourceBuffer.java (createTags): Strip spaces from the function string. * SourceView.java (scrollToFunction): Get rid of newlines and spaces in the incoming string. * SourceWindow.java (updateShownStackFrame): Upon call, send the function string to the SourceView to scroll to. Fixes #3327.
2006-10-17 Mike Cvet <mcvet@redhat.com> * SourceBuffer.java (setCurrentLine): Only highlight currently selected stack frame. Addresses #3327.
Hi, Mike, here is a new problem about Up/Down button. Step to reproduce, 1) fire frysk, ""Debugging an Existing Process" -> Select a test caes(with debug infor) 2) After SourceWindow opend, slecect one stack frame in StackView, and click Up/Down, now these two buttons still work. 3) Click "Run" and then click "Stop", the "Up/Down" could *not* work.
This problem is being worked by Adam Jocksch. Mike cleaned up several problem with this buugzilla, Adam is working this particular issue. He is a fulltime student and parttime Red Hat employee.
I tested this today and it appears that multiple source files now work thanks to some changes in the DOM checked in by Rick yesterday. I tested it in a manner similar to the one described by Yao in his initial description. I believe Rick has a slightly more complicated example with which it also works. I'm now taking a look at the other problem that Yao mentioned (intermittantly broken behavior for the stack control buttons when running/stopping).
I've done some more searching on this bug and it appears that the reason why the buttons become inoperative is that the array returned by this.stackView.getSelection().getSelectedRows() has length zero. I'm not yet sure why this is the case and I will continue looking into it.
Button problem moved to #3537. Original reason for this bug being opened is now fixed!