Bus Error (Core Dump) HPUX B11.11

[Vibhavari]

Hi,

I have compiled my code in HP-UX B11.11 for 64 bit. The GCC version used is 3.4.2. Also we link the code to oracle 10G (64 bit).
But while executting some of the executables, I get Bus Error (Core Dump). Some executables work fine.
The output of "what" command is,
core:
libcl.sl version B.11.01.18 - Jan 3 2003
Pthread Interfaces
$Revision: libpthread.1: @(#) depot-64pa CUP11.11_BL2002_0405_3 PATCH_11.11 PHCO_26466 Fri Apr 5 12:29:35 PST 2002 $
$Revision: libxti.2: STREAMS: PATCH_11.11 (PHNE_27703) Fri Sep 27 13:17:12 PDT 2002 $
$ PATCH_11.11/PHCO_29955 Jan 28 2004 01:23:25 $
HP-UX libm shared pa20_rtm64 C Math Library 20000331 (200955) UX11.01
$ B.11.11_LR Oct 26 2000 23:11:44 $
92453-07 linker command s800.sgs dld PA64 B.11.41 PBO 040821

[A. Clay Stephenson]

You are going to have to use a debugger (eg gdb) to get a stack trace. Ideally, you will compile your code with -g to include debugger data in the object files and then with any luck the stack trace can pinpoint the offending source line in the offending source file. The bad news is that if you have to ask, you probably aren't the person who needs to do this.

[Vibhavari]

gdb does not work properly on the core file.

Below is output of GDB
----------------------
gdb ./rate core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "hppa2.0w-hp-hpux11.00"..."/home/test/sbin/rate": not in executable format: File format not recognized

"/home/test/sbin/core" is not a core dump: File format not recognized
--------------------------------------------
Even I tried adb. But doesn't give useful backtrace.

The output of "strings" command on core is,
strings core
------------
>!P;
>!P;
>!P;
>!P;
>!P;
/libocii

If I debug the code, then it is crashing while opening database connection. But there are some other executables which do almost same activity and able to open the data base connection. Even the ldd output of the executables are exactly same.

[Dennis Handly]

You should download HP's gdb, perhaps it can do better with the 64 bit corefile?
http://www.hp.com/go/wdb

[Vibhavari]

Currently we use OCI calls to connect to DB in our code. If we use Oracle 9i, it works fine. But when we connect to oracle 10G it gives Bus Error.

[Vibhavari]

Finally I got some back trace from gdb,

Here it is,

HP gdb 5.1.1 for PA-RISC 2.0 (wide), HP-UX 11.00
and target hppa2.0w-hp-hpux11.00.
Copyright 1986 - 2001 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 5.1.1 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
Core was generated by `rate'.
Program terminated with signal 10, Bus error.
BUS_UNKNOWN - Unknown Error

warning: Load module /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1 has been stripped.
Debugging information is not available.


warning: Load module /disk3/Ora10g_hp11i//lib/libnnz10.sl has been stripped.
Debugging information is not available.

#0 0xc0000000001e3338 in getsockopt+0x48 () from /lib/pa20_64/libxnet.2
(gdb) bt
#0 0xc0000000001e3338 in getsockopt+0x48 () from /lib/pa20_64/libxnet.2
#1 0xc00000006f7fa82c in lsxvTypeDrvMatrix+0x4dbe64 () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#2 0xc00000006f6c511c in lsxvTypeDrvMatrix+0x3a6754 () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#3 0xc00000006f6c8b94 in lsxvTypeDrvMatrix+0x3aa1cc () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#4 0xc00000006f6c5b30 in lsxvTypeDrvMatrix+0x3a7168 () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#5 0xc00000006f6c7130 in lsxvTypeDrvMatrix+0x3a8768 () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#6 0xc00000006f6c7074 in lsxvTypeDrvMatrix+0x3a86ac () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#7 0xc00000006f6a5074 in lsxvTypeDrvMatrix+0x3866ac () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#8 0xc00000006f6ca280 in lsxvTypeDrvMatrix+0x3ab8b8 () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#9 0xc00000006f75c9b4 in lsxvTypeDrvMatrix+0x43dfec () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#10 0xc00000006f6d3f1c in lsxvTypeDrvMatrix+0x3b5554 () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#11 0xc00000006f3ce3cc in lsxvTypeDrvMatrix+0xafa04 () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#12 0xc00000006f4d468c in lsxvTypeDrvMatrix+0x1b5cc4 () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#13 0xc00000006f4b4cb0 in lsxvTypeDrvMatrix+0x1962e8 () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#14 0xc00000006f3ce724 in lsxvTypeDrvMatrix+0xafd5c () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
#15 0xc00000006f497240 in lsxvTypeDrvMatrix+0x178878 () from /disk3/Ora10g_hp11i//lib/libclntsh.sl.10.1
Error accessing memory address 0x0: Invalid argument.

[Dennis Handly]

>Finally I got some back trace from gdb

Well it indicates that getsockopt doesn't like its input. You should set a breakpoint there and print out all 5 parms.

Looking at the man page, it seems there are 3 separate versions, where using 64 bits, will kill you! size_t, int, socklen_t.

Are you sure you should be linking with libxnet? What does Oracle's libclntsh.sl.10.1 expect?

[Vibhavari]

Yes I need libxnet form connection. And libclntsh is used for OCI calls.
Below is the ldd results for y executables,
librangeroracle.sl.0 => /disk3/raghup/RangerRoot/lib/librangeroracle.sl.0
libdl.1 => /lib/pa20_64/libdl.1
librt.2 => /lib/pa20_64/librt.2
libxnet.2 => /lib/pa20_64/libxnet.2
libdameoracle.sl.0 => /home/ranger/local/lib/libdameoracle.sl.0
libclntsh.sl.10.1 => /disk1/ora10g/lib/libclntsh.sl.10.1
libstdc++.sl.6 => /usr/local/pa64//lib/libstdc++.sl.6
libm.2 => /lib/pa20_64/libm.2
libc.2 => /lib/pa20_64/libc.2
libdl.1 => /usr/lib/pa20_64/libdl.1
libxti.2 => /usr/lib/pa20_64/libxti.2
libc.2 => /lib/pa20_64/libc.2
libnnz10.sl => /disk1/ora10g/lib/libnnz10.sl
librt.2 => /lib/pa20_64/librt.2
libpthread.1 => /lib/pa20_64/libpthread.1
libnss_dns.1 => /lib/pa20_64/libnss_dns.1
libdl.1 => /lib/pa20_64/libdl.1
libnsl.1 => /lib/pa20_64/libnsl.1
libm.2 => /lib/pa20_64/libm.2
libc.2 => /lib/pa20_64/libc.2
libcl.2 => /lib/pa20_64/libcl.2
libm.2 => /lib/pa20_64/libm.2
libc.2 => /lib/pa20_64/libc.2
libdl.1 => /usr/lib/pa20_64/libdl.1
libdl.1 => /usr/lib/pa20_64/libdl.1

[Vibhavari]

I debugged my code and found that it is crashing at OCIServerAttach call. I am not able to get any error code as it is crashing

[Dennis Handly]

>Yes I need libxnet form connection.

Why? You are using one version sockets and Oracle another. If you can take the default, you won't have this problem.

[Vibhavari]

How can I get the libxnet form connection ?

Sockets we are using for IPC with =in our product. And our backend DB is oracle.

[Dennis Handly]

>How can I get the libxnet form connection?

All I know is there are 2 different types of socket interfaces. HP-UX supports two different styles of Socket API, BSD style and
X/Open Style. If Oracle is using one, you must use the same style. Using _XOPEN_SOURCE_EXTENDED will cause problems.

Another customers have had this problem and there was a proposed solution to this in a future? patch. I don't have all the details with me.

I have this bug report, CR JAGaf97778:
socklen_t defn creates libxnet/libc incompatibility in 64-bit programs

But I don't see any solutions yet.

[Vibhavari]

I am attaching tusc command output for our application on 10G and 9i oracle. We got some sample probram from oracle which works fine with 10G and 9i version.Also I am attaching tusc output for it.

Can you let me know the patch (if you can)?

[Dennis Handly]

>Can you let me know the patch (if you can)?

I didn't see any evidence of a patch for that enhancement CR JAGaf97778:
socklen_t defn creates libxnet/libc incompatibility in 64-bit programs

As I said before, you must NOT use X/Open style socket calls (libxnet) if you expect to inter-operate with your Oracle calls and use 64 bit mode.