structure search error

We install new version of jchem 3.1.3 on EM64T IBM machine with SLES 9 update 2 and oracle 10.2.0.1.0 - 64bit Production. Now when we perform structure search we got the following error:


ORA-29902: error in executing ODCIIndexStart() routine


ORA-29516: Aurora assertion failure: Assertion failure at joeintp.c:373


Interpreter hit null Java opcode.


ORA-06512: at "JCHEM.JCHEM_BLOB_PKG", line 55


ORA-06512: at "JCHEM.JC_IDXTYPE_IM", line 589


What we are doing wrong? Thanks for info/advice.

This looks like a low-level Oracle JVM problem. I could not find anything on Metalink that would give a hint. The best advice I can currently give you is to raise a technical assistance request with Oracle.

Can the problem be related that we have 181 java classes are not compiled in oracle. Example: chemaxon/marvin/modules/MChart.


We have the following errors:ORA-29521: referenced name com/objectplanet/chart/LineChart could not be found


ORA-29521: referenced name com/objectplanet/chart/ChartSample could not be found

If you look at a working JChem Cartridge installation, you also have lots of "non-compiled" classes in Oracle. The expression "compiled" is used in this context misleadingly with the meaning of "resolved". During JChem Cartridge installation, pre-compiled Java classes are loaded into Oracle. Oracle needs to resolve dependencies between the loaded classes before they are executed.





There are two ways of resolving a class: (a) the greedy way: immediately after a class has been loaded into Oracle or (b) the lazy way: before a class is first executed. While the first method requires that we load the classes in their dependency order (first the classes that do not depend on any other (JChem) classes, secondly those depending on the first ones, etc...), with the second method Oracle itself determines the dependency chain and resolves dependencies in the appropriate order. Since method (a) would overly complicate the installation process, we use method (b).





The last step of the JChem Cartridge installation process is to execute the test.sh script whose primary purpose is to check and see if the installation was successful. It is also by running this script that resolution of the needed classes is triggered. This script calls a Java stored procedure in the class chemaxon.jchem.cartridge.JFunctions, so the dependencies related to the this class are recursively resolved. Since chemaxon.jchem.cartridge.JFunctions is the only entry point for JChem Cartridge classes, by the time the test.sh script completes successfully all needed classes should have been resolved. (There is actually another, less frequently used entry point class, but that class itself calls exclusively JFunctions.) Resolved dependencies are "persistently cached" by Oracle, so Oracle does not have to resolve dependencies again until you change the Java class in Oracle (typically by loading into Oracle a different version of the class). It follows that if the test.sh script successfully completed, there is should be no need to resolve JChem classes again (and especially no need to compile them).





So I do not think that "non-compiled" classes should be a problem in themselves.

A minor correction to my previous post:





With recent JChem Cartridge versions, resolution of the JChem classes occurs during the execution of the install.sh script -- before execution of the test.sh script.





Peter

The "ORA-29516: Aurora assertion failure" problem is quite consistently reproduceable in my 64-bit environment (EM64T conform Intel dual Xeon, Fedora Core 4 x86_64, Oracle 10gR2 64-bit). With our standard set of query structures for SSS the Aurora problem hits at either the 13th or 14th search. Increasing the java pool and the shared pool (up to 320 megabytes each) did not have any effect.





In order to rule out the possibility that this is an Oracle 10gR2 specific problem, I ran the same test with Oracle 10gR2 on Windows XP (on a dual core EM64T processor system) without being able to reproduce the problem.





I double-checked with Oracle 10gR1 on Fedora 3 32-bit -- on the same machine where the 64-bit environment can be found. In 32-bit mode I could not reproduce the problem.





I believe that we have run into an Oracle bug specific to the EM64T processors (Intel only???) in 64-bit mode. It is possible that this is a new bug in Oracle 10gR2 x86_64. If so, chances are that this bug will be fixed soon. I will check to see if the problem occurs with Oracle 10gR1 x86_64. Also, I will try to find some kind of workaround.





Peter

This problem appears to affect only Oracle 10gR2 for x86_64 linux and Microsoft Windows.





Note that on Microsoft Windows the Aurora assertion failure already appears during index creation.





10gR2 works on 32 bit linux and Microsoft Windows, while 10gR1 works on both 32 bit and x86_64 versions of linux and Microsoft Windows.





10gR2 also works in 64-bit mode on the Sparc/Solaris platform.








Peter

The problem can be avoided by installing Oracle Database 10g Products from the Oracle Database Companion CD. I have tested with JChem 3.2.3.