Community
Participate
Working Groups
I initially reported this on the forum: " I am a relative newcomer to using mylyn/Tasktop with Subversive in a distributed C++ environment. mylyn & Tasktop were added about a week ago, the other components I have been using for several months. Just as of today, Create Patch has started taking intolerable amounts of time, with eclipse.exe consuming ~50% of a relatively decent Core 2 Duo machine. Create Patch is being invoked from the Synchronize view - I am right-clicking the relevant project under the relevant change set, and selecting Create Patch... off the context menu. I can name the patchfile with no issues. However, any change to the 'Include changes' window causes the CPU to peg for approximately 5-10 minutes. e.g. deselect the root of the project, wait five minutes. select one file, wait ten minutes, select another file, wait seven minutes... I tried restarting eclipse. Same behavior. I tried rebooting the machine. Same behavior " I got this reply from Dani Megert: " Please file a bug report and attach stack traces that show where the time is spent. " What build of Eclipse you are using - see attached file eclipse-help-about-details-configuration.txt What VM you are using (version and vendor). Use "java -version" to find out version information. C:\Documents and Settings\JBreh7100805>java -version java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) Client VM (build 17.1-b03, mixed mode, sharing) What you were doing at the time of the deadlock (what dialog, wizard, editor, etc) - Synchronize view > rt-clk on project > Local > Create Patch ... > select or deselect folders or files in the Include changes window. Each selection or deselection puts the UI to sleep, with CPU pegged (as viewed by taskmgr.exe), for 5-10 minutes Whether it is reproducible; if so, provide steps - Yes, it is reproducible in multiple projects, and multiple change sets. see above for steps to recreate. Once the bug report is created, attach a stack trace (also known as thread dump), using the "Create a New Attachment" link in bugzilla.
Created attachment 186315 [details] data on eclipse & plugins
Explicitly adding files under the project heirarchy to SVN's ignore list seems to reduce the amount of time spent waiting on the machine out to lunch. I am doing this from Synchronize view > select project > rt-clk on files not needing CM > Add to svn:ignore However, this seems to be required per project, per change set - each change set seems to be populated with products from the build process, not needing CM, even though they have already ben explicitly added to svn:ignore from another Change Set in the same project. I am working on getting a stack trace....
Moving to Subversive. Please capture a stack trace when the problem occurs and attach it: http://wiki.eclipse.org/Mylyn_Contributor_Reference#Debugging .
I am trying to use the adaptj mechanism for obtaining a stack dump. The instructions at the link above state: On Windows use the tool found at the adaptj home page: * Follow the link and select button "Launch" and run the applet * Select menu Process > Thread Dump * In the combo box "Process ID" select the Java VM and click OK I am able to launch the applet. However, the other two steps seem to be reversed? Thread Dump is greyed out on the Process menu unless I first make a selection in the Process ID box. Even at this, I seem to be encountering an issue. Here is the output in the lower window of the StackTrace tool, showing the results from both the running processes on my machine: 5424 javaw.exe ( StackTrace - <Untitled> ) session:0 threads:23 parent:4784 There is no valid license. ================================================================================ 5660 java.exe ( Create Patch ) session:0 threads:60 parent:4292 There is no valid license. I'll try to employ another mechanism for captureing the stack trace. Please be patient - I'm not a Java guy, and these tools are new to me.
I need to retract a statment above - I am not in fact seeing artifacts that must be added to the svn:ignore list on a per-project, per-changeSet basis. Once added to svn:ignore for a given project from within a change set, they seem to be handled appropriately for other change sets. Still encountering difficulty obtaining a stack trace. Method 2 fails as well. The Create Patch window is modal. Accordingly, I cannot get to the Console view to enter a Ctrl-Break.
Created attachment 186540 [details] thread dump - jvisualvm I think this is the requested thread dump. I captured this using jvisulvm during the time the UI for the Create Patch was stalled.
Thank you, all the information was helpful. I've simplified code and reduced amount of calls to the tree UI. Fix will be included into the next development build. If there still some issues with this functionality even after the fix is applied, then please reopen the report.
