From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Description of problem:
I noticed this message has popped up again latley:
The platform metadata area could not be written:
I just rebuilt my system (disk was misbehaving) and I reinstalled 8.0
with the relevant Eclipse bits and pieces. It occured to me I had a
really old snapshot:
so I installed:
but the I still get the error. I can't remember if there was any action
on the user side that was needed to get around it; I know Andrew patched
it awhile ago. It seems to be wanting to write to /usr/lib again.
Exception in thread "main" java.lang.reflect.InvocationTargetException:
org.eclipse.core.runtime.CoreException: The platform metadata area could
not be written: /usr/lib/eclipse/runtime-workspace/.metadata. By
default the platform writes its content
under the current working directory when the platform is launched. Use
the -data parameter to
specify a different content area for the platform.
at java.lang.reflect.Method.invoke(Native Method)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Create a plug-in example
2.Select Run->Run As->Runtime Workbench
3.See console window for error
Actual Results: Console indicates Eclipse unable to run as it cannot write to
Expected Results: Should have created another instance of the workbench with
your plug-in running in memory
I tried this today and wasn't able to reproduce it.
I'm closing the PR on the theory that it somehow got fixed.
Can you reproduce this?
Reopened for tracking, and investigation
From: Andrew Haley <firstname.lastname@example.org>
To: Tom Tromey <email@example.com>
Subject: I fixed the mystery bug!
Date: Wed, 3 Sep 2003 20:18:32 +0100
After a very long struiggle, I have discovered the problem.
Okay, the bug was this. In launcher.Main, we have some code that
converts from a .jar file to a .so, so that we run compiled code
rather than starting the interpreter. We added this code to the point
where we look for the .jar.
The problem is that the boot file was being searched for in two
separate places, dammit, rather than the one that we patched. So,
sometimes we run the .so and sometimes we run the .jar, depending on
which code path we follow. This triggers a gcj bug whereby there is a
problem accessing static fields in a .jar from a .so.
So, I made the code that looks for the solib into a private method and
called it from *both* places. This fixes the problem.
2003-09-03 Andrew Haley <firstname.lastname@example.org>
* src/org/eclipse/core/launcher/Main.java (findBootSolib): New method.
(getDevPath): Call findBootSolib.
(processConfiguration): Call findBootSolib.