Bugzilla – Full Text Bug Listing
| Summary: | Severe loss of variable view contents | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Olivier Thomann <Olivier_Thomann> | ||||||||
| Component: | Debug | Assignee: | JDT-Debug-Inbox <jdt-debug-inbox> | ||||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||||||
| Severity: | blocker | ||||||||||
| Priority: | P3 | CC: | sonia_dimitrov | ||||||||
| Version: | 3.3 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Olivier Thomann
It is really bad if I scroll down in the variable view. But even if I don't, after a while the view is flushed. If necessary, I can share a debug session on my machine with someone to investigate the problem. Could not reproduce using I20070228-0930. Tried multiple types of breakpoints in multiple VMs. I don't need to give the focus to the variable view. Once the debugger stops on a breakpoint, after a while (2/3s), the variable view is flushed. I could reproduce on Sonia's machine following these steps: 1) Start a fresh installation of the 20070228-0930 build 2) In the eclipse.ini file, I set up a VM: -vm .... path to a JDK1.5.0_11 VM ...\java.exe 3) Start a fresh workspace 4) Import the project that I will attach 5) Put a breakpoint on line 303 in org.eclipse.jdt.core.contrib.ant.Converter 6) Put the attached xml log in a test folder. Let's say: d:\temp\logs 7) Start a debug session on the class org.eclipse.jdt.core.contrib.ant.Converter and set up the following command line arguments: -i d:\temp\logs -r -v 8) Once the breakpoint is hit, simply click around in the variable view or the debug view. In my case, the debug sessions dies. Nothing in the .log, no error message, nothing! It simply dies. Created attachment 60086 [details]
Project to import using import wizard (existing project into workspace from an archive file)
Created attachment 60087 [details]
Test log to save in d:\temp\logs
Please let me know if you can reproduce it. I need to debug this app to find out why the line breaks are not there and right now I can't do anything. Thanks. I can reproduce it using I20070228-0930 in Linux, using my existing workspace. 1. start debug session (I was debugging the debugger at the time :)) 2. stop at a breakpoint 3. hit step over a couple of times 4. WHAM variables view is empty and I have lost the instruction pointer Thanks. So I am not the only one :-). I could get it using an existing workspace or setting up a new one from scratch. I think the difference in my case is that I can reselect a stackframe and everything comes back, whereas for you, Oliver, it is completely broken after this happens??? Once it is dead, selecting the thread doesn't help for me. I'll attach a test case of the way it looks in the debug view once the variable view has been flushed. Created attachment 60093 [details]
Screenshot
Olivier I am having one heck of a time reproducing the problem using the steps you outlined. At no point do I lose the threads of my target, and I only lose the variables view contents when the selection in the launch view is lost (which happens sometimes). Do you have any funky logical structures, or are you running any long-running evaluations? Do you see anything in the launch view if show system threads? I did notice that some of the system calls in the class you mentioned take a very long time to run (specifically the method call getAllFiles(sourceDir, XML_FILTER) taks about 5 minutes to return when I try to step over it) does opening and closing the view bring back the threads etc? Curtis has had some luck success reproducing your exact bug, and we found this to as a workaround. This feels like a viewer bug... Workaround: Turn off filtering of system threads (view drop down menu > show system threads) Shortly after the breakpoint is hit, a [Keep Alive Timer] system thread is terminated. When that thread is filtered, the view does not update properly (the child count and view count are incorrect). Darin is investigating. This is the same problem that causes bug 170857. A thread is removed and (virtual) fitlers are not updated properly. In combination with bug 173571, the view is not updated properly. Workaround is to turn off system thread filters (or close/re-open the debug view). *** This bug has been marked as a duplicate of bug 170857 *** (In reply to comment #14) > Do you have any funky logical structures, or are you running any long-running > evaluations? I don't think so. > Do you see anything in the launch view if show system threads? No. > I did notice that some of the system calls in the class you mentioned take a > very long time to run (specifically the method call getAllFiles(sourceDir, > XML_FILTER) taks about 5 minutes to return when I try to step over it) My breakpoint is after the xml file search. Depending on the input folder, it can be faster. If you specify the root of your disk, the whole disk is searched. I patched debug.ui with Darin's patch and I could no longer reproduce the failure. If you can tell me what debug options I could use to see what was wrong with my first test case, I can run it again. I had nothing in the .log file, no VM crash, no errors. Olivier - Michael's question about logical structures etc. (comment#14), seems to be a delayed bugzilla email from last week. We were able to reproduce the problem and understand it. |