Community
Participate
Working Groups
Created attachment 77791 [details] Backtrace of the NPE leading to view creation failure CQ:WIND00103648 Starting Eclipse with RSE I20070816-0800 on Windows XP SP2 host causes RSE view creation failure. All existing target connections are unavailable and no new ones can be created. See attached screen captures. This installation has been used successfully since Aug 28, until today. See attached backtrace, the NPE happens in RSEDOMImporter.java:76, which corresponds to this line: boolean defaultPrivate = getBooleanValue(dom.getAttribute( IRSEDOMConstants.ATTRIBUTE_DEFAULT_PRIVATE).getValue()); It looks like the attribute ATTRIBUTE_DEFAULT_PRIVATE does not exist in the DOM in question. Workarounds: Start eclipse on a new empty workspace, or delete the profile dir: <workspace>/.metadata/.plugins/org.eclipse.rse.core/profiles This bug is critical because the whole RSE is not usable any more. In spite of the workarounds, data of the target connections is lost and there seems no way to restore them - only workaround is to delete the entire profile. Expected behavior: 1.) RSE should ensure that no broken profiles are ever written. Right now, I have no idea how a broken profile could be created. 2.) When the RSEDOMImporter comes across an exception, that exception should be cought and handled in a way that allows at least the RSE SystemView to come up, even if it might be empty. -----------Enter bugs above this line----------- TM 2.0 I20070816-0800 installation : eclipse-SDK-3.3 (I20070625-1500), cdt-4.0.0, emf-2.3.0 RSE install : I20070816-0800 java.runtime : Sun 1.5.0_11 os.name: : Windows XP 5.1, Service Pack 2 ------------------------------------------------ systemtype : Windows-local ------------------------------------------------
Created attachment 77792 [details] Error dialog during startup
Created attachment 77793 [details] Erroneous RSE view contents
Created attachment 77794 [details] Patch to make the RSEDomImporter more fault tolerant Attached patch makes the RSEDOMImporter more fault tolerant. I'm not 100% sure if this is the right way to go, since importing broken profiles may lead to other problems later on; on the other hand, we try and preserve data as we can in case something is broken. Dave can you please review the patch and potentially apply it. What do you think, how can we have the right granularity of fault tolerance?
Martin -- could you attach the profile that's causing the trouble?
Created attachment 77812 [details] .metadata/.plugins/org.eclipse.rse.core/profiles causing trouble Attaching the profiles causing the trouble
It appears that profiles\PRF.svl-mstanek-d1_2\node.properties has been filled with all zeros. We have no idea how this could happen. There were no unusual logs during RSE shutdown. Just startup seemed to take unnaturally long. Could it be that RSE wiped its own node.properties with zeros from Thread A while reading it with Thread B?
Interesting that the node.properties in the Profile (PRF.svl-mstanek-d2) and the host (H.local_16) have been wiped with zeros, while all others seem to be good. Also interesting that the files have not just been truncated to length 0 but actually been filled with zeros (up to a given length which might relate to the original file's length).
Martin -- I was just noticing the same thing. The node.properties file for the svl-mstanek-D1 profile is completely blank (hex 00). I'm not sure how this could be. All other nodes in this profile and the Team profile are written correctly. The odd thing is that it appears to be of a correct length. In this case, there may be a way to recover since there is some redundancy built into the structure of the profile. There are reference properties (links) in the persistent form that refer to externally referenced files. These links are followed when a profile is loaded. If these are missing (as they they are in this case) we could attempt a repair by assuming their existence from the directory structure. Such a repair is unreliable in general since there are cases where it would be difficult to determine if such a repair should be made or not. It might be best to just mark the profile as bad and not use it. Without this kind of repair the patch you made will get rid of the NPE and should cause the DOM representing the profile to be imported, but none of the filter pools or hosts will be restored since the links to them have been severed. Those nodes would not be present in the DOM. I'm going to incorporate your patch since it does prevent the NPE, but the real fix is to find out why that node.properties file was written (or overwritten) incorrectly in the first place.
Pls wait a little incorporating the patch -- I tried it on the test data, and it gives NPE's later on, because filter pools with NULL names are being created. I'll come up with a better patch. And, we'll need to find out why the files could be wiped with hex 0x00.
Created attachment 77826 [details] Patch to make the RSEDOMImporter robust and log problems Attached patch makes the RSEDOMImporter as robust as I can possibly make it, and adds logging for unforseen cases. Hopefully, this additional logging will help us to find out why the node.properties was nulled out. Dave please review the patch and apply.
Created attachment 77880 [details] Amended patch to log missing systemTypes Attached is a further improved patch, which also logs missing systemTypes when restoring the profile (see bug 202621 for details).
The patch looks quite good and tests OK. I'll apply it.
patch applied
*** Bug 202621 has been marked as a duplicate of this bug. ***
