Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 296456

Summary: [Import/Export] File -> Import filesystem w/cyclical symbolic folder links causes OOME
Product: [Eclipse Project] Platform Reporter: Prakash Rangaraj <prakash>
Component: UIAssignee: Prakash Rangaraj <prakash>
Status: VERIFIED FIXED QA Contact: Prakash Rangaraj <prakash>
Severity: normal    
Priority: P3 CC: amanji, bokowski, celek, daniel_megert, Dmitry_Karasik, john.arthorne, john.camelon, krzysztof.daniel, makandre, mober.at+eclipse, pwebster, stevenyj, tomasz.zarna
Version: 3.6   
Target Milestone: 3.6 M7   
Hardware: PC   
OS: Linux   
Whiteboard:
Bug Depends on: 285804    
Bug Blocks: 253941, 293159    
Attachments:
Description Flags
Patch v01 none

Description Prakash Rangaraj CLA 2009-11-30 07:03:33 EST 
The original bug was fixed in 3.5.1. I guess this needs to be fixed in 3.6 as well


+++ This bug was initially created as a clone of Bug #285804 +++

Build ID: M20090211-1700

Steps To Reproduce:
With a their source code base (55K files spread across the directory
structure), the customer tried to import the File tree into a new (and empty)
eclipse workspace.  

The OOM gets hit even with -Xmx1024M. 

Closing Eclipse and copying the files directly into the workspace root and
restarting Eclipse works, so the issue seems isolated to the memory complexity
of the Resources UI dialog. 

We encourage this workflow in Jazz SCM, is there something else we should be
doing?
Comment 1 Martin Oberhuber CLA 2009-11-30 11:45:15 EST 
I just learned about this bug and reviewed the original diff in 3.5.1.

I originally wrote the PrefixPool for bug 105554, where we had to check for cyclic symbolic links in the Workspace refresh, making sure that Performance was not degraded when no symbolic links were present. We therefore used the EFS IFileInfo to first check whether any node is a symbolic link, and only perform the getCanonicalPath() for nodes which actually are symbolic links. Since only few nodes in the structure were checked, we had to do Prefix checks on the canonical paths.

Here, in the import wizards, Performance is way not that critical. The current code performs more than one getCanonicalPath() call for each folder, because it does not use the "isSymbolicLink" property from EFS. Since getCanonicalPath() is called for each folder in the structure anyways, checking for Prefixes is unnecessary -- checking equality / existence of canonical paths in a HashMap is sufficient.

Such a solution has been implemented already for "Import existing Projects", see the final patch on bug 187318. This solution is MUCH simpler than the PrefixPool one, and also performs better than what is in CVS now since it (a) never does more than one getCanonicalPath() per folder, and (b) does all lookups without String manipulation (substring, append etc).

I suggest using the approach from bug 187318 here as well, rather than using the PrefixPool.
Comment 2 Prakash Rangaraj CLA 2010-03-18 07:16:02 EDT 
Created attachment 162389 [details]
Patch v01

Patch v01
Comment 3 Prakash Rangaraj CLA 2010-03-22 05:47:48 EDT 
Patch v01 released to HEAD
Comment 4 Prakash Rangaraj CLA 2010-04-27 04:23:19 EDT 
Verified in I20100425-2000