Community
Participate
Working Groups
This is going to be a poor bug report, because the bug is one of these random bogon bugs and not necessarily reproducable... but I thought I should log into the bugzilla, anyway. After doing some various UI tasks (such as configuring my launch configurations), I am getting an "Invalid thread access" message when I close the project I am working on (it happens to be an eclipse plugin). I will attack my log from the relevant run of eclipse. mike
Created attachment 1491 [details] relevant section of my workspace's .metadata/.log file
I suppose I should provide some more details of the system I'm running on: Debian sid/unstable (I can provide library version details if necessary) Sun's JDK1.4.0 java -version: java version "1.4.0" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92) Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode) Ant version 1.5beta1 /usr/bin/ant -version: Apache Ant version 1.5Beta1 compiled on May 26 2002 mike
d'oh. silly bugzilla. That was meant for a different bug report... (the JVM I used when this stack trace was generated was Blackdown's 1.3.1, so it's not even useful information) mike
This is actually a good bug report, thanks. However, please indicate which build you were running in PRs. Among other things, this helps in figuring out which code is referred to by line numbers in stack dumps. The thread exception is due to PDE's log view not doing a syncExec or asyncExec when talking to the viewer. In these cases, log entries are being added by threads other than the UI thread, and the log view is notified in the same thread. Marking as critical because this bug makes the log view unusable. There are secondary errors here from VCM and JDT Debug. Also, it doesn't look like the log entries being added when the thread exception occurred actually ended up in the log. For the last stack, line 120 of SyncFileChangeListener is: } catch(CVSException e) { CVSProviderPlugin.log(e.getStatus()); // line 120 } and I don't see any CVSException or its subclasses in the log. Core should check that it writes to the log file -before- notifying listeners.
The "non-existant" project errors logged by the debugger are the result of agressive error logging. The referenced project may no longer exist in the workspace (or may be closed). The launch config dialog still operates.
d'oh. Yeah, this occured on F3.
Consider fixing for F4 - react to log notification using asyncExec
The cvs bug in the log has been fixed by 20421 since F3.
Created new bug 20680 to add improved support for logging messages and exceptions. The problem (w.r.t. log file writing) was that the PDE log file listener threw an Error and therefore no other listeners (inluding the platform log listener) had a chance to log the original CVS exception.
Fixed
