Hi

I have developed a Java program, which uses JNI to talk to native C
APIs.

This program is working well on Windows, Solaris, HP-UX and Linux.

However, when I try to run this on AIX, I'm getting an error (Illegal
Insruction - core dumped).

This error occurs when the Java program tries to load the JNI shared
library.


Part of the error is as follows:

-----------------
Sun Sep 21 23:52:30 2003
SIGILL received at 0xd058efec in /usr/lib/libC.a. Processing
terminated.
Current Thread Details
----------------------
"main" sys_thread_t:0x3020E708
----- Native Stack -----
at 0xD0219BD8 in qs1
at 0xD029E724 in dlopen
at 0xD48CDB9C in sysLoadLibrary
at 0xD475D74C in JVM_LoadLibrary
at 0xD4750298 in IBMJVM_LoadLibrary
at 0xD3DD0F5C in Java_java_lang_ClassLoader_00024NativeLibrary_load
----------------


Has any one encountered this before?

thanks,
Naresh

Naresh Agarwal <nagarwal@informatica.com> wrote:
NA> Hi

NA> I have developed a Java program, which uses JNI to talk to native C
NA> APIs.

NA> This program is working well on Windows, Solaris, HP-UX and Linux.

NA> However, when I try to run this on AIX, I'm getting an error (Illegal
NA> Insruction - core dumped).

NA> This error occurs when the Java program tries to load the JNI shared
NA> library.
NA>
NA>
NA> Part of the error is as follows:
NA>
NA> -----------------
NA> Sun Sep 21 23:52:30 2003
NA> SIGILL received at 0xd058efec in /usr/lib/libC.a. Processing NA> terminated.

I think libC.a is kinda C++-ish. What's the process doing there?

Regards,

Nicholas

--
"Why shouldn't I top-post?" http://www.aglami.com/tpfaq.html
"Meanings are another story." http://www.ifas.org/wa/glossolalia.html

Nicholas Dronen wrote:

> NA> However, when I try to run this on AIX, I'm getting an error (Illegal
> NA> Insruction - core dumped).
>
> NA> This error occurs when the Java program tries to load the JNI shared
> NA> library.
> NA>
> NA>
> NA> Part of the error is as follows:
> NA>
> NA> -----------------
> NA> Sun Sep 21 23:52:30 2003
> NA> SIGILL received at 0xd058efec in /usr/lib/libC.a. Processing NA> terminated.
>
> I think libC.a is kinda C++-ish. What's the process doing there?

Actually, I think the question is, how did you build your module?
What is the command line, exactly?

--
Gary R. Hook / AIX PartnerWorld for Developers / These opinions are MINE
__________________________________________________ ______________________

"Gary R. Hook" <nospam@nospammers.net> wrote in message news:<hdZbb.146$0S4.18@newssvr24.news.prodigy.com> ...
> Nicholas Dronen wrote:
>
> > NA> However, when I try to run this on AIX, I'm getting an error (Illegal
> > NA> Insruction - core dumped).
> >
> > NA> This error occurs when the Java program tries to load the JNI shared
> > NA> library.
> > NA>
> > NA>
> > NA> Part of the error is as follows:
> > NA>
> > NA> -----------------
> > NA> Sun Sep 21 23:52:30 2003
> > NA> SIGILL received at 0xd058efec in /usr/lib/libC.a. Processing NA> terminated.
> >
> > I think libC.a is kinda C++-ish. What's the process doing there?
>
> Actually, I think the question is, how did you build your module?
> What is the command line, exactly?

The build script I'm using is as follows:

xlC_r -g -G -+ -brtl -I../include -I/usr/java131/include CancelCallBack.cpp JLMC
onnection10Impl.cpp JLMDriver10Impl.cpp JLMSession10Impl.cpp JLMTask10Impl.cpp J
LMUtilImpl.cpp JLMWorkflow10Impl.cpp LogSegmentCallback.cpp Utility.cpp -L../lib
-lACE -lglobalcS -lpmdec -lpminfapi -lpmser -ltls4dshr -lpmasrt -lpmi18n -lpmIC
E -lpmlmapi -lpmuti -o ../lib/libJavaLMApi.a

thanks,
Naresh

Naresh Agarwal wrote:

> The build script I'm using is as follows:

Hmmm...where to start....

> xlC_r -g -G -+ -brtl

1) Do _not_ use both -G and -brtl. The docs clearly state
that -G implies -brtl, and -brtl is only to be used for main
applications.
2) I don't see "-qmkshrobj" here, but current levels of
the compiler understand that -G implies -qmkshrobj. That
would be recent levels of the V6 compiler.

-I../include -I/usr/java131/include CancelCallBack.cpp JLMC
> onnection10Impl.cpp JLMDriver10Impl.cpp JLMSession10Impl.cpp JLMTask10Impl.cpp J
> LMUtilImpl.cpp JLMWorkflow10Impl.cpp LogSegmentCallback.cpp Utility.cpp -L../lib
> -lACE -lglobalcS -lpmdec -lpminfapi -lpmser -ltls4dshr -lpmasrt -lpmi18n -lpmIC
> E -lpmlmapi -lpmuti -o ../lib/libJavaLMApi.a

Runtime linking is an attribute of an _application_. You _enable_
a module for runtime linking, but the app must support it if you
rely on load-time symbol resolution. In all likelihood, your module
contains unresolved references that _require_ RTL for resolution,
but Java doesn't do RTL. And probably won't, ever.

To check your module, do 'dump -Tv libJavaLMApi.a | grep "\.\."'.
If you find any ".." imports, then your module is going to
have to be rebuilt to remove them. This means building (linking)
against any required dependents, such that your module is fully
resolved at link time. It will likely load and run once you
accomplish this task.

You can read a bunch of stuff in the article
http://www-1.ibm.com/servers/esdd/pdfs/aix_ll.pdf

--
Gary R. Hook / AIX PartnerWorld for Developers / These opinions are MINE
__________________________________________________ ______________________

"Gary R. Hook" <nospam@nospammers.net> wrote in message news:<oKhcb.338$tm1.13@newssvr24.news.prodigy.com> ...
> Naresh Agarwal wrote:
>
> > The build script I'm using is as follows:
>
> Hmmm...where to start....
>
> > xlC_r -g -G -+ -brtl
>
> 1) Do _not_ use both -G and -brtl. The docs clearly state
> that -G implies -brtl, and -brtl is only to be used for main
> applications.
> 2) I don't see "-qmkshrobj" here, but current levels of
> the compiler understand that -G implies -qmkshrobj. That
> would be recent levels of the V6 compiler.
>
> -I../include -I/usr/java131/include CancelCallBack.cpp JLMC
> > onnection10Impl.cpp JLMDriver10Impl.cpp JLMSession10Impl.cpp JLMTask10Impl.cpp J
> > LMUtilImpl.cpp JLMWorkflow10Impl.cpp LogSegmentCallback.cpp Utility.cpp -L../lib
> > -lACE -lglobalcS -lpmdec -lpminfapi -lpmser -ltls4dshr -lpmasrt -lpmi18n -lpmIC
> > E -lpmlmapi -lpmuti -o ../lib/libJavaLMApi.a
>
> Runtime linking is an attribute of an _application_. You _enable_
> a module for runtime linking, but the app must support it if you
> rely on load-time symbol resolution. In all likelihood, your module
> contains unresolved references that _require_ RTL for resolution,
> but Java doesn't do RTL. And probably won't, ever.
>
> To check your module, do 'dump -Tv libJavaLMApi.a | grep "\.\."'.
> If you find any ".." imports, then your module is going to
> have to be rebuilt to remove them. This means building (linking)
> against any required dependents, such that your module is fully
> resolved at link time. It will likely load and run once you
> accomplish this task.
>
> You can read a bunch of stuff in the article
> http://www-1.ibm.com/servers/esdd/pdfs/aix_ll.pdf


I'm not getting anything when I run, 'dump -Tv libJavaLMApi.a | grep
"\.\."'
Seems that there are no ".." imports in jni lib.

However, I tried linking with libC_r.a instead of libC.a

By doing this, I'm able to load the jni library, when I try to run
Java sample program, but I'm getting a crash in first function call
itself in libjvm.a

I'm getting the following crash now...

---
SIGILL received at 0xdcebb87c in
/usr/java131/jre/bin/classic/libjvm.a. Processing terminated.
Current Thread Details
----------------------
"main" sys_thread_t:0x3020E908
----- Native Stack -----
at 0xD464282C in Java_com_informatica_powercenter_sdk_lm_JLMDriver1 0_nativeInitialize
at 0xDCEBB87C in sysInvokeNative
at 0xDCE96120 in mmisInvokeJniMethodHelper
at 0xDCEBBC64 in changeCodes
-------------------------------------------------------------------

nativeInitialize is first native function call made by Java sample
program

thanks,
Naresh

Naresh Agarwal wrote:

> I'm not getting anything when I run, 'dump -Tv libJavaLMApi.a | grep
> "\.\."'
> Seems that there are no ".." imports in jni lib.

It would be worthwhile to check _all_ of the modules that you
reference when you build liBjavaLMApi.a. All the way down the
tree.

> However, I tried linking with libC_r.a instead of libC.a

Actually, xlC_r does that for you. But if you've added that to
the command line, perhaps in front of other modules, then the
next step would be to check for symbol resolution conflicts.

> ---
> SIGILL received at 0xdcebb87c in

This is still most likely caused by trying to call a function
that isn't resolved. Either a deferred import or a ".." import.

> /usr/java131/jre/bin/classic/libjvm.a. Processing terminated.
> Current Thread Details
> ----------------------
> "main" sys_thread_t:0x3020E908
> ----- Native Stack -----
> at 0xD464282C in Java_com_informatica_powercenter_sdk_lm_JLMDriver1 0_nativeInitialize
> at 0xDCEBB87C in sysInvokeNative
> at 0xDCE96120 in mmisInvokeJniMethodHelper
> at 0xDCEBBC64 in changeCodes
> -------------------------------------------------------------------
>
> nativeInitialize is first native function call made by Java sample
> program

Investigate the work nativeInitialize is attempting to do, including
function calls, constructors, etc.

--
Gary R. Hook / AIX PartnerWorld for Developers / These opinions are MINE
__________________________________________________ ______________________

"Gary R. Hook" <nospam@nospammers.net> wrote in message news:<doYcb.724$lk7.616@newssvr24.news.prodigy.com >...
> Naresh Agarwal wrote:
>
> > I'm not getting anything when I run, 'dump -Tv libJavaLMApi.a | grep
> > "\.\."'
> > Seems that there are no ".." imports in jni lib.
>
> It would be worthwhile to check _all_ of the modules that you
> reference when you build liBjavaLMApi.a. All the way down the
> tree.
>
> > However, I tried linking with libC_r.a instead of libC.a
>
> Actually, xlC_r does that for you. But if you've added that to
> the command line, perhaps in front of other modules, then the
> next step would be to check for symbol resolution conflicts.
>
> > ---
> > SIGILL received at 0xdcebb87c in
>
> This is still most likely caused by trying to call a function
> that isn't resolved. Either a deferred import or a ".." import.
>
> > /usr/java131/jre/bin/classic/libjvm.a. Processing terminated.
> > Current Thread Details
> > ----------------------
> > "main" sys_thread_t:0x3020E908
> > ----- Native Stack -----
> > at 0xD464282C in Java_com_informatica_powercenter_sdk_lm_JLMDriver1 0_nativeInitialize
> > at 0xDCEBB87C in sysInvokeNative
> > at 0xDCE96120 in mmisInvokeJniMethodHelper
> > at 0xDCEBBC64 in changeCodes
> > -------------------------------------------------------------------
> >
> > nativeInitialize is first native function call made by Java sample
> > program
>
> Investigate the work nativeInitialize is attempting to do, including
> function calls, constructors, etc.


As you said there were some unresolved symbols in some of shared
libraries we were using. We removed the -G compiler option and built
these libraries again with "-bnoentry -bnosymbolic -bnoautoexp -bM:SRE
" flags. We could see that there were now no deferred imports using
dump. Now we are able to load the JNI library but get unsatisfied link
error when try to call native function.

It seems that no symbols have been exported from the shared libraries
we built again using "-bnoentry -bnosymbolic -bnoautoexp -bM:SRE"
flags. What is the way to export symbols from a shared library, we
tried looking for it and it seems that making an export file and using
-bE:SymbolsToExport.exp is one option but that is too cumbersome, is
there any automatic way to export all the symbols?

Thanks
Naresh