Library call fail on HP 11i with Oracle client 9.2

[Peter Yas]

Hi
I'm using a code wich calls a dynamicly linked oracle libclntsh library. On Sun 64 bit and 32 bit and HP 32 bit compilation the code works fine, On HP 64 bit compilation I get a SIGBUS error and these messages on the debugger:

warning: section .data not found in /usr/local/opt/oracle/product/9.2.0/lib/libw
tc9.sl

Program received signal SIGBUS, Bus error.
0x800003ffe7e9e390 in pthread_default_stacksize_np+0xe8 ()
from /lib/pa20_64/libpthread.1

This is the stack on the point of failure

(gdb) bac
#0 0x800003ffe7e9e390 in pthread_default_stacksize_np+0xe8 ()
from /lib/pa20_64/libpthread.1
#1 0x800003ffe8e5dca0 in Ldipme10+0x84a618 ()
from /usr/local/opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0
#2 0x800003ffe89f49e0 in Ldipme10+0x3e1358 ()
from /usr/local/opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0
#3 0x800003ffe89f8138 in Ldipme10+0x3e4ab0 ()
from /usr/local/opt/oracle/product/9.2.0/lib/libclntsh.sl.9.0

The Ldipme10 seems to be in an infinite loop, but I can't see a way to solve this problem

Any help will be appriciate.
The ORACLE function which causes all this is OCIServerAttach, and I can't work without it.
And, I asked DBA's and Metalink forum, no answer there...

[Robert-Jan Goossens]

HI Peter,

-----

1-10 Administratorâ s Reference
When the program is executed, it generates the following errors:
/usr/lib/pa20_64/dld.sl: Cannot dlopen load module
'/usr/lib/pa20_64/libpthread.1' because it contains thread specific data.
/usr/lib/pa20_64/dld.sl: Cannot dlopen load module '/usr/lib/pa20_64/libcl.2'
because it contains thread specific data.
The new LD_PRELOAD environment variable resolves these errors.
To prevent errors occurring when an application uses the shl_load() function
call to attach a shared library that directly or indirectly contains HP-UX TLS
libraries, perform the following steps:
Relinking Executables
1. Set the value of the LD_PRELOAD environment variable to include a
colon-separated or whitespace-separated list of the TLS libraries that your
program uses, for example:
$ export LD_PRELOAD=/usr/lib/pa20_64/libpthread.1:/usr/lib/pa20_64/libcl.2
The dynamic loader treats the libraries specified by the LD_PRELOAD variable
as the first libraries in the link line and pre-loads these libraries implicitly at
application startup.
2. Enter the following command to execute your program, where prog is the
name of your program:
$ prog
The errors shown on the previous page should not appear.

-----

HTH,
Robert-

[T G Manikandan]

I would trace the program using
tusc.

I can give you more information.

Install tusc on the machine and trace the program as what the real problem is

$tusc -faepo ./tusc.out

REvert

[T G Manikandan]

Can you use the TNS/Net library instead of the OCI?

REvert

[Peter Yas]

I must use OCI library in order to keep my code compatible with several different Oracle versions, and platphorm independent.
Besides, the problem arose during the beta testing, and its too late to switch.

As to LD_PRELOAD, I tried, it didn't help. More than that, on the HP machine with 32 bit Oracle 8.0.6 driver, there's no such variable, and still the program compiles and runs fine.

[T G Manikandan]

Peter,

I would also add another point

you must be looking into 32 and 64 bit libraries.
Looking into your messages it looks like it takes the 64 bit libraries.9i is 64 bit.
There is a problem

Try doing,

There is a dir lib32 with 9i installation.
Make sure you add this to your LD_LIBRARY_PATH or SHLIB_PATH and remove the $ORACLE_HOME/lib which will point to the 64 bit libraries

REvert on this

[Anirban Das]

Hey Peter,
I faced a similar problem with my application and the solution was:
I found that the libc library was being linked before libpthread into my application. I simply modified the makefile to put libc after libpthread... and you knwo what IT WORKED.
The application stopped giving the error.
See the posting from "Mike Stroyan" in the following link:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=73484
"There is a fairly common problem with linking libpthread with the wrong libraries,
or linking libc in front of libpthread. You can use the the 'info share' command in gdb to see what shared libraries have been loaded and in what order. "
Regards
Anirban