javahl-1.3.0-related crash

> I rebuilt the javahl native libs with some
logging/assertions, and I
> believe the problem is that the global initialization
function for
> javahl has not been called when the SVNClient is
constructed in
> isAvailable(). If you look at
> org/tigris/subversion/javahl/NativeResources.java in
javahl, when the
> native lib is loaded javahl calls
SVNClient.initNative(). subclipse
> isAvailable() does native lib loading while skipping
this step.

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?

Mark


____________________________________________________________
_________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe
Plc by IBM Email Security Management Services powered by
MessageLabs. 
____________________________________________________________
_________________

------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribesubclipse.tigris.org
For additional commands, e-mail: users-helpsubclipse.tigris.org

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?

Oh wait, simpler theory -
eclipse/plugins/org.tigris.subversion.subclipse.core_0.9.37/
lib/svnjavahl.jar
contains an older SVNClient which does not call the init
stuff since
older versions of javahl didn't have it. Does that make any
sense? 
I don't really know enough about the broader context to
know.

Havoc



------------------------------------------------------------
---------
To unsubscribe, e-mail: users-unsubscribesubclipse.tigris.org
For additional commands, e-mail: users-helpsubclipse.tigris.org

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-unsubscribesubclipse.tigris.org
For additional commands, e-mail: users-helpsubclipse.tigris.org