commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Jason.C.Bu...@wellsfargo.com>
Subject RE: [daemon]UnsatisfiedLinkError: net exception thown through JSVC but not when natively called
Date Sat, 24 Jul 2010 00:01:14 GMT
Sorry Martin,  still at a loss.  I don't get the reference as to how
stripping debug code from libraries applies here (I understand what you're
saying and agree with it, I just don't see how it is relevant here).

I have an application that ran fine under IBM JRE 5 and jsvc 1.0.1 and
1.0.2.  I upgraded to IBM JRE 6 and now I get the link exception.  The code
hasn't changed - unless you're referring to the IBM JRE library?  If that
was the case, why would it work when the JVM is created by the JRE's
bin/java command?

Perhaps someone knows of a way to get more debugging information from the
JVM?  As I showed in my previous post, we can see where in the code the link
error is happening, but perhaps a more verbose JRE library would tell me
why?  Anyone know of such a thing?

Or have any other ideas?

Jason


> -----Original Message-----
> From: Martin Gainty [mailto:mgainty@hotmail.com]
> Sent: Friday, July 23, 2010 11:29 AM
> To: user@commons.apache.org
> Subject: RE: [daemon]UnsatisfiedLinkError: net exception thown through
> JSVC but not when natively called
> 
> 
> 
> 
> sometimes when programmers strip their debug code they also strip working
> code so the rule is
> 
> debug library always work..a programmer could'nt declare working code
> without a debug library
> 
> production library (without the debug statements) usually work..if not
> fall back to debug library
> 
> 
> 
> take a look at Doug Kileys solution for JSVC problem with Snow Leopard..he
> used 1.02 commons daemon to fix
> 
> https://issues.apache.org/jira/browse/DAEMON-129
> 
> in this case the culprit was commons-daemon 1.01
> 
> upgrade to commons-daemon 1.01 with patches or
> 
> upgrade to commons-daemon 1.02 and see if that resolves
> 
> 
> 
> keep us apprised,
> Martin Gainty
> ______________________________________________
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
> 
> 
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-
> Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la
> copie de ceci est interdite. Ce message sert à l'information seulement et
> n'aura pas n'importe quel effet légalement obligatoire. Étant donné que
> les email peuvent facilement être sujets à la manipulation, nous ne
> pouvons accepter aucune responsabilité pour le contenu fourni.
> 
> 
> 
> 
> 
> > From: Jason.C.Burns@wellsfargo.com
> > To: user@commons.apache.org
> > Date: Thu, 22 Jul 2010 19:42:34 -0500
> > Subject: RE: [daemon]UnsatisfiedLinkError: net exception thown through
> JSVC but not when natively called
> >
> > Thanks for the reply Martin, but I'm a little confused. After reading
> the
> > page you sent, it seems kdb is a kernel debugger for processing system
> > dumps. This is a java exception from the JVM running in user space.
> There
> > is no dump file and unless I'm missing something, I don't know how the
> > kernel trace is going to help me here. Can you perhaps just give a bit
> more
> > information about what you had in mind? Thanks for taking the time to
> > reply.
> >
> > Jason
> >
> > > -----Original Message-----
> > > From: Martin Gainty [mailto:mgainty@hotmail.com]
> > > Sent: Thursday, July 22, 2010 5:28 PM
> > > To: user@commons.apache.org
> > > Subject: RE: [daemon]UnsatisfiedLinkError: net exception thown through
> > > JSVC but not when natively called
> > >
> > >
> > > load in kdb and read the debug output back
> > > http://www.aixmind.com/?p=637
> > >
> > >
> > >
> > > hth
> > > Martin Gainty
> > > ______________________________________________
> > > do not alter ot disrupt this transmission. Thank You
> > >
> > >
> > >
> > >
> > > > From: Jason.C.Burns@wellsfargo.com
> > > > To: user@commons.apache.org
> > > > Date: Thu, 22 Jul 2010 17:18:56 -0500
> > > > Subject: [daemon]UnsatisfiedLinkError: net exception thown through
> JSVC
> > > but not when natively called
> > > >
> > > > Hopefully the mailing list can help where I have failed after
> pulling my
> > > > hair out for three days. Any advice will be greatly appreciated.
> > > >
> > > > I have an AIX 5.2 machine with daemons 1.0.2 and IBM's latest JRE 6
> > > > installed:
> > > >
> > > > bash-3.1# ./jre/bin/java -version
> > > > java version "1.6.0"
> > > > Java(TM) SE Runtime Environment (build pap3260sr8-20100409_01(SR8))
> > > > IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 AIX ppc-32
> > > > jvmap3260sr8-20100401_55940 (JIT enabled, AOT enabled)
> > > > J9VM - 20100401_055940
> > > > JIT - r9_20100401_15339
> > > > GC - 20100308_AA)
> > > > JCL - 20100408_01
> > > >
> > > > 1.0.2 is compiled with
> > > >
> > > > ./configure --with-java=$(JAVA_HOME)
> > > > make
> > > >
> > > > This includes a small patch to location.c and appsupport.m4 just to
> > > enable
> > > > jsvc to find the jvm.cfg and libjvm.so files during startup.
> > > >
> > > > I have a Java application that implements the Daemon class. I'm
> trying
> > > to
> > > > update the JRE from 5 to 6 - this application worked fine under 5
> and
> > > > upgraded on other OSes to 6 with no issues. Part of the
> initialization
> > > of
> > > > this class is a routine to create an RMI registry. A partial example
> is
> > > > below:
> > > >
> > > > From the Daemon class:
> > > >
> > > > public void init(DaemonContext arg0) throws Exception
> > > > {
> > > > log.debug("Initializing client from the Daemon process.");
> > > >
> > > > log.debug("Setting environment variables.");
> > > > System.setProperty("javax.net.ssl.trustStore", "<snip>");
> > > > System.setProperty("javax.net.ssl.trustStoreType", "jks");
> > > >
> > > > <snip>
> > > >
> > > > log.debug("Initializing client.");
> > > > client = new Client();
> > > > if (arg0 == null)
> > > > client.init(null);
> > > > else
> > > > client.init(arg0.getArguments());
> > > >
> > > > <snip>
> > > >
> > > > hasInit = true;
> > > > log.debug("Initializing done.");
> > > > }
> > > >
> > > > And from the Client class:
> > > >
> > > > public void init(String[] cmdArgs)
> > > > {
> > > > log.debug("Initializing Client.");
> > > >
> > > > <snip>
> > > >
> > > > try
> > > > {
> > > > // Set up RMI for <something>. Start with the registry.
> > > > if (rmiRegistry == null)
> > > > {
> > > > log.debug("Trying to start the rmi registry.");
> > > > rmiRegistry = LocateRegistry.createRegistry(rmiport);
> > > > log.debug("Registry started.");
> > > > }
> > > > <snip>
> > > > }
> > > > catch (Exception e)
> > > > <snip>
> > > > }
> > > >
> > > >
> > > > When this process starts up through JSVC, it crashes in
> createRegistry
> > > with
> > > > a UnsatisfiedLinkError. Below is the jsvc debug output:
> > > >
> > > >
> > > > jsvc debug: +-- DUMPING PARSED COMMAND LINE ARGUMENTS --------------
> > > > jsvc debug: | Detach: False
> > > > jsvc debug: | Show Version: No
> > > > jsvc debug: | Show Help: No
> > > > jsvc debug: | Check Only: Disabled
> > > > jsvc debug: | Stop: False
> > > > jsvc debug: | Wait: 0
> > > > jsvc debug: | Run as service: No
> > > > jsvc debug: | Install service: No
> > > > jsvc debug: | Remove service: No
> > > > jsvc debug: | JVM Name: "null"
> > > > jsvc debug: | Java Home: "null"
> > > > jsvc debug: | PID File: "<client home>/run/client.pid"
> > > > jsvc debug: | User Name: "null"
> > > > jsvc debug: | Extra Options: 2
> > > > jsvc debug: |
> > > > "-Djava.class.path=./libs/commons-daemon.jar:./ClientSoftware.jar"
> > > > jsvc debug: | Class Invoked: "<package>.Daemon"
> > > > jsvc debug: | Class Arguments: 0
> > > > jsvc debug: +-------------------------------------------------------
> > > > jsvc debug: Home not specified on command line, using environment
> > > > jsvc debug: Attempting to locate Java Home in <client home>/jre
> > > > jsvc debug: Attempting to locate VM configuration file <client
> > > > home>/jre/jre/lib/jvm.cfg
> > > > jsvc debug: Attempting to locate VM configuration file <client
> > > > home>/jre/lib/jvm.cfg
> > > > jsvc debug: Attempting to locate VM configuration file <client
> > > > home>/jre/jre/lib/ppc/jvm.cfg
> > > > jsvc debug: Attempting to locate VM configuration file <client
> > > > home>/jre/lib/ppc/jvm.cfg
> > > > jsvc debug: Found VM configuration file at <client
> > > home>/jre/lib/ppc/jvm.cfg
> > > > jsvc debug: Found VM j9vm definition in configuration
> > > > jsvc debug: Checking library <client
> > > home>/jre/jre/lib/ppc/j9vm/libjvm.so
> > > > jsvc debug: Checking library <client
> home>/jre/lib/ppc/j9vm/libjvm.so
> > > > jsvc debug: Found VM client definition in configuration
> > > > jsvc debug: Checking library <client
> > > home>/jre/jre/lib/ppc/client/libjvm.so
> > > > jsvc debug: Checking library <client
> home>/jre/lib/ppc/client/libjvm.so
> > > > jsvc debug: Cannot locate library for VM client (skipping)
> > > > jsvc debug: Found VM server definition in configuration
> > > > jsvc debug: Checking library <client
> > > home>/jre/jre/lib/ppc/server/libjvm.so
> > > > jsvc debug: Checking library <client
> home>/jre/lib/ppc/server/libjvm.so
> > > > jsvc debug: Cannot locate library for VM server (skipping)
> > > > jsvc debug: Found VM hotspot definition in configuration
> > > > jsvc debug: Checking library <client
> > > home>/jre/jre/lib/ppc/hotspot/libjvm.so
> > > > jsvc debug: Checking library <client
> home>/jre/lib/ppc/hotspot/libjvm.so
> > > > jsvc debug: Cannot locate library for VM hotspot (skipping)
> > > > jsvc debug: Found VM classic definition in configuration
> > > > jsvc debug: Checking library <client
> > > home>/jre/jre/lib/ppc/classic/libjvm.so
> > > > jsvc debug: Checking library <client
> home>/jre/lib/ppc/classic/libjvm.so
> > > > jsvc debug: Found VM native definition in configuration
> > > > jsvc debug: Checking library <client
> > > home>/jre/jre/lib/ppc/native/libjvm.so
> > > > jsvc debug: Checking library <client
> home>/jre/lib/ppc/native/libjvm.so
> > > > jsvc debug: Cannot locate library for VM native (skipping)
> > > > jsvc debug: Found VM green definition in configuration
> > > > jsvc debug: Checking library <client
> > > home>/jre/jre/lib/ppc/green/libjvm.so
> > > > jsvc debug: Checking library <client
> home>/jre/lib/ppc/green/libjvm.so
> > > > jsvc debug: Cannot locate library for VM green (skipping)
> > > > jsvc debug: Java Home located in <client home>/jre
> > > > jsvc debug: +-- DUMPING JAVA HOME STRUCTURE ------------------------
> > > > jsvc debug: | Java Home: "<client home>/jre"
> > > > jsvc debug: | Java VM Config.: "<client home>/jre/lib/ppc/jvm.cfg"
> > > > jsvc debug: | Found JVMs: 2
> > > > jsvc debug: | JVM Name: "j9vm"
> > > > jsvc debug: | "<client home>/jre/lib/ppc/j9vm/libjvm.so"
> > > > jsvc debug: | JVM Name: "classic"
> > > > jsvc debug: | "<client home>/jre/lib/ppc/classic/libjvm.so"
> > > > jsvc debug: +-------------------------------------------------------
> > > > jsvc debug: redirecting stdout to /dev/null and stderr to /dev/null
> > > > jsvc debug: Using default JVM in <client
> > > home>/jre/lib/ppc/j9vm/libjvm.so
> > > > jsvc debug: Attemtping to load library <client
> > > > home>/jre/lib/ppc/j9vm/libjvm.so
> > > > jsvc debug: JVM library <client home>/jre/lib/ppc/j9vm/libjvm.so
> loaded
> > > > jsvc debug: JVM library entry point found (0x2004E12C)
> > > > jsvc debug: +-- DUMPING JAVA VM CREATION ARGUMENTS -----------------
> > > > jsvc debug: | Version: 0x010006
> > > > jsvc debug: | Ignore Unrecognized Arguments: False
> > > > jsvc debug: | Extra options: 3
> > > > jsvc debug: |
> > > > "-Djava.class.path=./libs/commons-daemon.jar:./ClientSoftware.jar"
> > > > (0x00000000)
> > > > jsvc debug: +-------------------------------------------------------
> > > > jsvc debug: Java VM created successfully
> > > > jsvc debug: Class org/apache/commons/daemon/support/DaemonLoader
> found
> > > > jsvc debug: Native methods registered
> > > > jsvc debug: java_init done
> > > > jsvc debug: Daemon loading...
> > > > java.lang.reflect.InvocationTargetException
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > at
> > > >
> > >
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> > > 48
> > > > )
> > > > at
> > > >
> > >
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
> > > pl
> > > > .java:25)
> > > > at java.lang.reflect.Method.invoke(Method.java:600)
> > > > at
> > > >
> > >
> org.apache.commons.daemon.support.DaemonLoader.load(DaemonLoader.java:156)
> > > > Caused by: java.lang.UnsatisfiedLinkError: net (A file or directory
> in
> > > the
> > > > path name does not exist.)
> > > > at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:1008)
> > > > at
> > > >
> java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:972)
> > > > at java.lang.System.loadLibrary(System.java:470)
> > > > at
> > > > sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:69)
> > > > at
> > > >
> java.security.AccessController.doPrivileged(AccessController.java:202)
> > > > at java.net.InetAddress.<clinit>(InetAddress.java:217)
> > > > at java.lang.J9VMInternals.initializeImpl(Native Method)
> > > > at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
> > > > at sun.rmi.transport.tcp.TCPEndpoint.<clinit>(TCPEndpoint.java:95)
> > > > at java.lang.J9VMInternals.initializeImpl(Native Method)
> > > > at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
> > > > at sun.rmi.transport.LiveRef.<init>(LiveRef.java:75)
> > > > at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:77)
> > > > at
> > > >
> java.rmi.registry.LocateRegistry.createRegistry(LocateRegistry.java:198)
> > > > at <package>.Client.init(Client.java:570)
> > > > at <package>.Daemon.init(Daemon.java:95)
> > > > ... 5 more
> > > > 22/07/2010 14:42:42 1077390 jsvc error: Cannot load daemon
> > > > jsvc debug: java_load failed
> > > > 22/07/2010 14:42:42 1130686 jsvc error: Service exit with a return
> value
> > > of
> > > > 3
> > > >
> > > >
> > > > Removing jsvc from the picture by creating a main method in Daemon
> that
> > > just
> > > > creates a Daemon object, calls daemon.init(), then calls
> daemon.start()
> > > runs
> > > > as expected (well, except for actually being a daemon =) ).
> > > >
> > > > An unsatified error of 'net' really intrigued me since this looks
> like
> > > maybe
> > > > "java.net"? How could it not find a runtime library? I thought that
> > > > perhaps jsvc was setting some odd boot path or class path for the
> jvm,
> > > so I
> > > > printed out all the system properities in the Daemon.init method.
> The
> > > list
> > > > of properties from the jsvc run and the bin/java run are exactly the
> > > same.
> > > > So it doesn't appear to be that easy of a solution.
> > > >
> > > > Running both jsvc and bin/java with the verbose flag and checking
> which
> > > > order the classes load shows something interesting:
> > > >
> > > > jsvc:
> > > >
> > > > <snip>...
> > > > class load: java/net/InetAddress
> > > > class load: sun/security/action/LoadLibraryAction
> > > > class load: java/lang/UnsatisfiedLinkError
> > > > class load: java/lang/J9VMInternals$1
> > > > java.lang.reflect.InvocationTargetException
> > > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> > > > ...<snip>
> > > >
> > > > bin/java:
> > > >
> > > > <snip>...
> > > > class load: java/net/InetAddress
> > > > class load: sun/security/action/LoadLibraryAction
> > > > class load: java/net/InetAddress$Cache
> > > > class load: java/net/InetAddress$Cache$Type
> > > > ...<snip>
> > > >
> > > >
> > > > So if the code is loading the libraries in a consistent fashion
> (don't
> > > think
> > > > this is guaranteed, but the rest of the class loading output seems
> to
> > > imply
> > > > that this is probable), it seems that the code when run through jsvc
> > > bombs
> > > > when trying to load the Cache internal class to InetAddress? This
> seems
> > > odd
> > > > to me since they should be in the same library, no?
> > > >
> > > >
> > > > Anyway, I'm at a loss at this point. This code upgraded to JRE 6 on
> all
> > > > other platforms just fine. On this AIX platform, however, it just
> > > doesn't
> > > > seem to like jsvc. I'm hoping someone else has seen this or has more
> > > > intimate knowledge with the JVM and can point me in the right
> direction.
> > > > Again, I appreciate any assistance anyone can provide.
> > > >
> > > > Thanks,
> > > > Jason
> > > >
> > >
> > > _________________________________________________________________
> > > The New Busy is not the old busy. Search, chat and e-mail from your
> inbox.
> > >
> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON
> > > :WL:en-US:WM_HMP:042010_3
> 
> _________________________________________________________________
> Hotmail has tools for the New Busy. Search, chat and e-mail from your
> inbox.
> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON
> :WL:en-US:WM_HMP:042010_1

Mime
View raw message