Bugzilla – Full Text Bug Listing
| Summary: | contention between debug console and SWT | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Rafael Chaves <eclipse> | ||||
| Component: | Debug | Assignee: | Platform-Debug-Inbox <platform-debug-inbox> | ||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | alex.blewitt, ben.grommes, Brian_Young, byron.hawkins, cocoakevin, eclipse, jeffmcaffer, kurt2002, mandrew, pascal, Tod_Creasey | ||||
| Version: | 2.1 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 5455 [details]
test case (standard Java application).
SWT is not Eclipse. Is this UI? Sorry if it isn't. Tod, is UIJob the culprit here? We don't do anything with the console - it looks like Rafaels application is blocking the UI Thread as the consolke is part of that. Moving to Debug for comment. When I debug this, the hang/delay is occurring in OS.GetDC(int) (which is a native). When I attempt to step over/into, things lock up. It is being called from Display.internal_new_GC(GC data). Doesn't seem to matter if I use java vs. javaw. I can get rid of the "lock up" by pressing enter in the console. Then, it locks up in Display.init(), in a call to OS.CreateWindowEx. Again, pressing ENTER makes allows the program to resume. The Eclipse console only "writes" to the input stream of programs when ENTER is pressed. I will investigate if this is the cause of the problem. Luc, could you see if the same problem exists on Linux? I don't get the problem on linux. When I launch the test case, I get the
following in the console without doing anything :
>Running
Got display
Kevin, can you try this one on the Mac to see what happens. works fine on Mac, got the same output as Luc. Moving to SWT. Debug is not able to detemine that we are doing anything wrong, and it appears to be specific to Windows. Carolyn to investigate. This happens to be a known issue: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809647 It has nothing to do with SWT itself (it blocks System.loadLibrary), and is triggered by the fact that the input stream of the launched VM is hooked by debug (Process.getOutputStream()). I believe the fact Sun's class libraries are licensed by other vendors is the reason why it can be reproduced on other VMs. The bug report mentioned above provides a workaround. Moving back to debug for consideration. The workaround provided in the bug report (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4809647) is a workaround that must be performed in the target (client) code. It's not something the Eclipse launcher can do. *** Bug 53784 has been marked as a duplicate of this bug. *** *** Bug 140838 has been marked as a duplicate of this bug. *** *** Bug 186216 has been marked as a duplicate of this bug. *** *** Bug 229400 has been marked as a duplicate of this bug. *** *** Bug 250639 has been marked as a duplicate of this bug. *** |
Eclipse build i20030526 When running a SWT application from inside Eclipse, several SWT operations such as getting the display for the first time will block if there is a thread reading from the console. I am not sure why is that, but I will attach a simple class that shows the problem. In summary, there is two threads: one is reading from the console (System.in): new Thread() { public void run() { BufferedReader br = new BufferedReader(new InputStreamReader(System.in)); while (true) { System.out.print("\n>"); try { br.readLine(); } catch (IOException e) { e.printStackTrace(); } } } } .start(); And after the previous thread is create, trying to get a display for the first time (among other operations) wuill block. An workaround is to change the loop above to use Reader.isReady() before trying to read from the stream. If there is no data, wait for some time, and then try again.