Bug 239991
|
Description
Austin
2007-05-14 07:18:38 UTC
You just discovered a bug in the laucher patch we added to work around other bugs :(
To get eclipse working again, you should just have to move ~/.eclipse out of the
way and start eclipse again.
mv ~/.eclipse{,.back}
But I'd like to know what is causing the segmenation fault. Could you run
eclipse with gdb:
gdb /usr/bin/eclipse
and then type 'run' at the gdb prompt. When you hit the seg fault, type 'bt' and
post the results. Thanks.
Created attachment 154622 [details]
A diff of the two directory structures
This file was created with :
diff -r .eclipse .eclipse_old_070514/ > eclipse_dir_structure_differences.log
Cool - synchronised posting. Have Eclipse working with a new .eclipse directory. Lowered priority. Will attach gdb results (however unhelpful they may be). If you could post a tar of the old .eclipse directory, that might be useful too. BTW, thanks for the bug report. Created attachment 154623 [details]
Results of running Eclipse with gdb
As requested, the results of running gdb /usr/bin/eclipse
(In reply to comment #4) > If you could post a tar of the old .eclipse directory, that might be useful too. > BTW, thanks for the bug report. I'm unsure I will be able to, due to the potentially classified nature of the directory, and the fact that I don't know what is stored in there. See attachment #154622 [details] for more information. (In reply to comment #6) > I'm unsure I will be able to, due to the potentially classified nature of the > directory, and the fact that I don't know what is stored in there. Ok, no problem. > See attachment #154622 [details] [edit] for more information. That doesn't help much. As for the gdb output, I forgot to mention that you'll need to install the eclipse-debuginfo package to make the information useful. Thanks. Installed eclipse-debuginfo-3.2.1-4.fc6 and the results didn't change. Ok, I'll try to reproduce this on my box. What were the permissions on the original .eclipse? drwxr-x--- (same as the current eclipse) ok, and does this file exist in the old .eclipse directory?: org.eclipse.platform_3.2.0/configuration/org.eclipse.update/platform.xml I'm looking at the following chunck of code from this patch: http://cvs.fedora.redhat.com/viewcvs/rpms/eclipse/FC-6/eclipse-launcher-addplatformtotildeeclipse.patch?rev=1.4&view=markup + platform_xml = g_strconcat(g_get_home_dir(), "/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/platform.xml", NULL); + touched = g_strconcat(g_get_home_dir(), "/.eclipse/.homedirmodified-fedora", NULL); + + + if (!g_file_test(platform_xml, G_FILE_TEST_EXISTS)) + { + /* If platform.xml doesn't exist, Eclipse has yet to be started. + * We don't have worry about doing anything now and in the future + * so add the appropriate file to ~/.eclipse. */ + if (g_mkdir(g_strconcat(g_get_home_dir(), "/.eclipse", NULL), 493) < 0) + { + g_print("Error creating ~/.eclipse/."); + g_print(g_strconcat(error->message, "\n\0", NULL)); + g_free(error); + } The seg fault is coming from this line: g_print(g_strconcat(error->message, "\n\0", NULL)); because g_mkdir() does raise a GError: http://library.gnome.org/api/glib/2.8/glib-File-Utilities.html.en#g-mkdir This is my mistake and I will put an update out to fix this, thank you. I'd still like to figure out why your laucher is hitting this section. Let me know if you have any ideas. When I delete the .eclipse directory, Eclipse will start, and ask me for the workspace directory. I press enter (accepting defaults), and it finds existing projects, and a list of files I previously had open. I will then close Eclipse, and it saves the workspace, and brings back the prompt with no other messages. I try to start Eclipse again, and I get: Error creating ~/.eclipse/.Segmentation fault Does this mean I need to remove my .eclipse directory each time I want to start it? (In reply to comment #11) > ok, and does this file exist in the old .eclipse directory?: > > org.eclipse.platform_3.2.0/configuration/org.eclipse.update/platform.xml The only files in that directory are: .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/ .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/.lock In fact - removing my .eclipse directory and recreating as described above, gives me the following directory tree: .eclipse/ .eclipse/.homedirmodified-fedora .eclipse/org.eclipse.platform_3.2.0/ .eclipse/org.eclipse.platform_3.2.0/configuration/ .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/ .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/.lock .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi/ .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi/.bundledata.1 .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi/.lazy.1 .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi/.manager/ .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi/.manager/.fileTable.4 .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi/.manager/.fileTableLock .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi/.manager/.fileTable.5 .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi/.state.1 .eclipse/org.eclipse.platform_3.2.0/configuration/.settings/ .eclipse/org.eclipse.platform_3.2.0/configuration/.settings/org.eclipse.ui.ide.prefs .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.core.runtime/ .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.core.runtime/.manager/ .eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.core.runtime/.manager/.fileTableLock HTH. I managed to reproduce the seg fault by changing the permissions on .eclipse to 760 and removing org.eclipse.platform_3.2.0/configuration/org.eclipse.update/platform.xml. Eclipse should be able to start in this condition. Here are the changes that need to be made to this patch to fix this bug: * check to see if platform.xml and ~/.eclipse both don't exist to determine if eclipse has yet to be run * remove these lines: g_print(g_strconcat(error->message, "\n\0", NULL)); g_free(error); * use the current umask value for directory creation (In reply to comment #12) > Does this mean I need to remove my .eclipse directory each time I want to start it? No, this is a bug that will be fixed. I'll have new packages for you to test by tomorrow morning (UTC/GMT +9). Thanks. Here is the test plan for this fix. The new package will be 3.2.2-6.fc6. -> Ensure that the test plan from bug #238107 still passes (tests 1 - 3): 1) ensure update manager works if there org.eclipse.rcp_3.2.1.r321_v20060801-clWbqCmjexIWDqg in platform.xml -> install eclipse-3.2.2-2.fc6 -> ensure org.eclipse.rcp_3.2.1.r321_v20060801-clWbqCmjexIWDqg is in platform.xml: grep -r rcp_3.2.1 ~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/platform.xml -> if not, running eclipse twice should put rcp_3.2.1 in platform.xml -> install eclipse-3.2.2-6.fc6 -> start eclipse and ensure 3.2.1.r321_v20060801-clWbqCmjexIWDqg is not in platform.xml -> ensure that the update manager works 2) ensure that update manager works with a new configuration -> install eclipse-3.2.2-6.fc6 -> rm -r ~/.eclipse -> run eclipse -> close eclipse -> run eclipse again -> ensure org.eclipse.rcp_3.2.1.r321_v20060801-clWbqCmjexIWDqg is not in platform.xml: grep rcp_3.2.1 \ ~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/platform.xml -> ensure that the update manager works 3) ensure that original bug is fixed -> install 3.2.1-4.fc6 -> rm -r ~/.eclipse -> start eclipse -> close eclipse -> update to eclipse-3.2.2-6.fc6 -> ensure update manager works 4) ensure that this bug is fixed -> install eclipse-3.2.2-6.fc6 -> start eclipse -> close eclipse -> change permissions of .eclipse to 750 -> mv ~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/platform.xml{,.back} -> ensure eclipse starts -> ensure update manager works I didn't finish with the tests so I'm not going to push a new build tonight. I'll finish up tomorrow and push a build then. All four tests pass with my local build. The updated patch has been committed and an official build is underway. Once the build is done, I'll request the package get moved to updates-testing. eclipse-3.2.2-6.fc6 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report. Austin, could you test the update? You should be able to install it with something like: sudo yum --enablerepo=updates-testing install eclipse-sdk Please report back. Thanks. Ran the command as suggested, and tried to run eclipse. I was presented with a dialog that read: "An error has occurred. See the log file /home/austin/.eclipse/org.eclipse.platform_3.2.0/configuration/1179442941623.log" I'll preview the file then attach if data is OK. Created attachment 154962 [details]
Log file that was created after startup crash.
Ran eclipse from the command prompt immediately after installing it.
I'll now remove the ~/.eclipse directory and try again.
Removed the ~/.eclipse directory and Eclipse started fine. It asked me where my workspace was, and loaded up the files that were previously open. I closed Eclipse without incident, but upon starting it again (immediately afterwards), Eclipse asked me where my workspace was again. It didn't used to do that. It was then that I noticed the "This is my default workspace - don't ask again" tick box wasn't selected. (I'm sure it used to be). Selecting that, appears to have solved that issue. I was looking over the tests you suggested in comment #16, and they all reference a file in ~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/ When I went to check mine, I don't have any files in there: $ ls ~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/ total 0 I've run Eclipse 6 times now since the first failure and no files are in there. Is this expected? (In reply to comment #24) > I was looking over the tests you suggested in comment #16, and they all > reference a file in > ~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/ > > When I went to check mine, I don't have any files in there: > > $ ls ~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/ > total 0 > > I've run Eclipse 6 times now since the first failure and no files are in there. > Is this expected? No, but if Eclipse is working for you, I wouldn't worrry about the missing files. The tests referenced in comment #16 were just for me and not really intended for you to run becuase of the missing files. Sorry, I should have mentioned that. As for the failure from comment #22, I'm not sure what's going on there so if eclipse is now working, I don't think I will investigate that problem. Let me know if you have any other problems. If not, I'll release this update. What if the files in an existing user's .eclipse directory (as present with a previous release) causes this new release to barf. I copied the "old" .eclipse directory back that I had before the most recent upgrade, and this error is still present. It appears to be configuration based: Root exception: org.eclipse.core.runtime.CoreException: Cannot create configuration in file:/home/austin/.eclipse/org.eclipse.platform_3.2.0/configuration/ It mentions directory, but not a file in there. I'm not sure what's going on here. I'll hold off pushing this to final until we sort this out. Since you can't attach your .eclipse directory, would you be able to figure out what you need to change in a working .eclipse to make it a non-working .eclipse so that I can try to track down the problem? Thanks, Ben Created attachment 155070 [details]
Differences between a working an non working .eclipse directory structure.
I diff'd the directories that result in this new version crashing
(.eclipse_old), and the structure that's created when there is no .eclipse
directory (.eclipse_new)
Hopefully, this will show you enough file differences that you might be able to
point at a particular file. In the mean time, I'll do a file-by-file comparison
and see if there's a single point of failure.
Created attachment 155071 [details]
A narrower file tree of the directory which causes the problem.
I've narrowed the problem down to the
~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi directory,
as when I remove that and start eclipse it works fine.
The directory with .bak is the one which will cause Eclipse to fail. The
directory without the .bak is the one that was created by Eclipse when there
was no org.eclipse.osgi directory.
HTH.
In the mean time, I'll try to narrow it a little further.
It appears to be related to the .bundledata.5 file in the osgi directory. If I renamed that file (.bak.bundledata.5) then Eclipse starts up OK and creates a .bundledata.6 file. If I remove this newly created file and put the old copy back (.bak.bundledata.5 -> .bundledata) then Eclipse will fail with another log file. Does this information, combined with the log file help? Should I attached another log file? Interesting, the patch doesn't touch anything in ~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi. Here's some background on the patch: Files stored in ~/.eclipse are private files for eclipse internal configuration. In order to fix a number of issues with the update manager, we removed the preset configuration in /usr/share/eclipse so that each user could have their own private configuration. The only problem with this move was that user's would have been required to remove their ~/.eclipse. To avoid this, we added a patch to tweak some of the files in ~/.eclipse. But our tweaking messed things up - so I added some logic to workaround the problems we caused with the first set of changes. -- As you can see, we kinda went down a bad path here playing with the private data in ~/.eclipse. Back to the problem at hand. I think that there might be a problem with the files in ~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.osgi being out of sync with ~/.eclipse/org.eclipse.platform_3.2.0/configuration/org.eclipse.update/platform.xml. The only thing is, you don't have this file. Since I've never seen that, I don't really know what's going on. Actually, I have an idea. Have you ever run eclipse as root? If so, that might be causing problems. Can you check to see if this directory exists?: /usr/share/eclipse/configuration If it's there, that's probably what's causing the problem. In this case, you should remove all of eclipse, rm -r /usr/share/eclipse and re-install eclipse. The configuration in your home directory will probably still be out of sync but there's not much I can do to work around that. Anyway, please let me know what you find. Thanks, Ben (In reply to comment #30) > It appears to be related to the .bundledata.5 file in the osgi directory. If I > renamed that file (.bak.bundledata.5) then Eclipse starts up OK and creates a > .bundledata.6 file. If I remove this newly created file and put the old copy > back (.bak.bundledata.5 -> .bundledata) then Eclipse will fail with another log > file. > > Does this information, combined with the log file help? Should I attached > another log file? No, unfortunately it doesn't help too much. My ~/.eclipse doesn't have .bundledata.5 and I'm hesitant start playing with more files in ~/.eclipse. One other thing related to comment #29. The configuration stored in /usr/lib/eclipse/configuration/org.eclipse.osgi should look like this: ./.state.1 ./.manager ./.manager/.fileTableLock ./.manager/.fileTable.4 ./.manager/.fileTable.5 ./.bundledata.1 ./.lazy.1 ./bundles ./bundles/4 ./bundles/4/1 ./bundles/4/1/.cp ./bundles/4/1/.cp/libswt-awt-gtk-3236.so ./bundles/4/1/.cp/libswt-gtk-3236.so ./bundles/4/1/.cp/libswt-mozilla-gtk-3236.so ./bundles/4/1/.cp/libswt-glx-gtk-3236.so ./bundles/4/1/.cp/libswt-pi-gtk-3236.so ./bundles/4/1/.cp/libswt-gnome-gtk-3236.so ./bundles/4/1/.cp/libswt-cairo-gtk-3236.so ./bundles/4/1/.cp/libswt-atk-gtk-3236.so ./bundles/13 ./bundles/13/1 ./bundles/13/1/.cp ./bundles/13/1/.cp/os ./bundles/13/1/.cp/os/linux ./bundles/13/1/.cp/os/linux/x86 ./bundles/13/1/.cp/os/linux/x86/libupdate.so ./bundles/16 ./bundles/16/1 ./bundles/16/1/.cp ./bundles/16/1/.cp/os ./bundles/16/1/.cp/os/linux ./bundles/16/1/.cp/os/linux/x86 ./bundles/16/1/.cp/os/linux/x86/liblocalfile_1_0_0.so If you have other stuff in there, you should also remove /usr/lib/eclipse when your uninstall and reinstall eclipse (if this is the problem). (In reply to comment #31) > Actually, I have an idea. Have you ever run eclipse as root? If so, that might > be causing problems. Can you check to see if this directory exists?: > > /usr/share/eclipse/configuration Yes, I do have this directory. It has a time stamp of 11th Dec '06. Sounds suspicious enough. It had an osgi sub-directory and a bundles sub-directory of that. No files though. Will remove and see if that fixes things. Is an Eclipse re-install really required? (In reply to comment #34) > Will remove and see if that fixes things. Is an Eclipse re-install really required? If you're able to remove the correct files, you should be able to fix this without re-installing - it's just the recipe I usually dish out for this problem. Just make sure that /usr/share/eclipse/configuration isn't there and that the /usr/lib/eclipse/configuration/org.eclipse.osgi directory has the same files as comment #33. Thanks, Ben (In reply to comment #33) > One other thing related to comment #29. The configuration stored in > /usr/lib/eclipse/configuration/org.eclipse.osgi should look like this: <snip> The directory contents match those listed. I will take a wild punt, and assume that by removing /usr/share/eclipse, I'll have to also re-install the plugins after an eclipse re-install? /usr/share/eclipse/configuration isn't there, and using the same ~/.eclipse directory structure that caused problems before, causes problems still. (In reply to comment #36) > (In reply to comment #33) > > One other thing related to comment #29. The configuration stored in > > /usr/lib/eclipse/configuration/org.eclipse.osgi should look like this: > <snip> > The directory contents match those listed. > > I will take a wild punt, and assume that by removing /usr/share/eclipse, I'll > have to also re-install the plugins after an eclipse re-install? If you're going to remove and re-install you should do this: sudo yum remove eclipse-ecj eclipse-rcp libswt3-gtk2 sudo rm -r /usr/share/eclipse /usr/lib/eclipse sudo yum install eclipse-sdk <+other eclipse plugins> > /usr/share/eclipse/configuration isn't there, and using the same ~/.eclipse > directory structure that caused problems before, causes problems still. This may be unresolvable if the configuration in ~/.eclipse was made when the configuration in /usr/lib/eclipse and /usr/share/eclipse was botched up. Created attachment 155080 [details]
Eclipse's latest barf
Is it safe to assume from this log that I'm going to need to re-install
eclipse? I've tested something that I've not put back properly, and I've lost
track of the file / directory.
Hopefully you know a way around this? Or at least what to check for?
Created attachment 155081 [details]
List of what yum wants to remove
Ouch. If I get yum to remove eclipse, it will try to remove a _lot_ of
packages.
Is this the only choice I've got left?
(In reply to comment #38) > Created an attachment (id=155080) [edit] > Eclipse's latest barf > > Is it safe to assume from this log that I'm going to need to re-install > eclipse? I've tested something that I've not put back properly, and I've lost > track of the file / directory. > > Hopefully you know a way around this? Or at least what to check for? Sorry, don't know the cause off hand. (In reply to comment #39) > Created an attachment (id=155081) [edit] > List of what yum wants to remove > > Ouch. If I get yum to remove eclipse, it will try to remove a _lot_ of > packages. > > Is this the only choice I've got left? You can use this line instead: sudo yum remove eclipse-rcp libswt3-gtk2 and then don't blindly delete /usr/lib/eclipse and /usr/share/eclipse. Instead remove everything *but* what's listed in the eclipse-ecj package: rpm -ql eclipse-ecj That should cut down the number of packages removed. HTH, Ben Went ahead with the yum erase eclipse*, removed the /usr/lib/eclipse and /usr/share/eclipse directories and reinstalled using yum so I should be back to "normal", right? Well... I've now got this: $ eclipse Error creating ~/.eclipse/.Segmentation fault Sooo... I must be using the "old" one? $ rpm -qa eclipse-sdk eclipse-sdk-3.2.2-5.fc6 But if the offending files are gone from the system's directories, and eclipse has not been run as root - why does the problem still exist? I'll remove my ~/.eclipse and just run as is. 3.2.2-6.fc6 has the fix. You need to run: sudo yum --enablerepo=updates-testing install eclipse-sdk Sorry, I forgot about that. So, is it safe to release this update (3.2.2-6.fc6)? Can't see why not. If you can't see a way around the problem mentioned earlier, then go for it. I've already deleted the relevant directories (albeit accidentally), so I'm unable to help diagnose any further. |