Hi,
On Sun, 2006-02-26 at 20:52 -0500, Mark Phippard wrote:
> I have looked at the JavaHL code some more and I do not see why what we are
> doing in svnClientAdapter would interfere with their initializing of the
> native resources. We are just doing the System.loadLibrary(), but we then
> construct and use an SVNClient(). All of the initialization should happen
> when this object is first constructed. I do not see anything in the JavaHL
> code that would skip over this because we have loaded the library.
>
> What do you think?
Yeah, it's weird. The SVNClient class has a static{} block that's
supposed to load and init the native library. The crash is in the
SVNClient() constructor and apparently the native library has not been
initialized at that point.
according to the loadLibrary docs, "If this method is called more than
once with the same library name, the second and subsequent calls are
ignored."
Here's a conspiracy theory: Subclipse and JavaHL end up loading the lib
using a different name passed to load()/loadLibrary(). I don't know what
Java does in that case, but I can imagine that it loads the lib twice.
If we guess that javahl loads it first and isAvailable() loads it
second, then the uninitialized isAvailable() version could "win"
It *kind of* makes sense, since the sequence of events could be:
- JVM loads the SVNClient class prior to running isAvailable(),
resulting in a loadLibrary()
- isAvailable() calls loadLibrary(), somehow changing the
loaded library
- isAvailable() calls new SVNClient()
But, I can't claim to understand JVMs or the Linux linker well enough to
know if this is plausible or just crazy.
Havoc
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Mon Feb 27 03:01:42 2006