Re: Solaris 8/Oracle 8 C++ program segmentation fault on connect

Ken Miller wrote:
>
> I'm running a C++ program on a Solaris 8 system, with Oracle 8.1.7
> installed. I'm trying to connect to an Oracle 7.3.4 database. In
> the parent process, the exec sql connect work fine. However, in
> forked processes, the exec sql connect fails with a segmentation
> fault, as you can see in the backtrace below:
>
> > gdb auth -core=core
>
> 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 "sparc-sun-solaris2.8"...
> Core was generated by `./auth -c auth.conf'.
> Program terminated with signal 11, Segmentation Fault.
> Reading symbols from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0...done.
> Loaded symbols for /home/oracle/OraHome1/lib/libclntsh.so.8.0
> Reading symbols from /usr/lib/libxnet.so.1...done.
> Loaded symbols for /usr/lib/libxnet.so.1
> Reading symbols from /usr/local/lib/libstdc++.so.2.10.0...done.
> Loaded symbols for /usr/local/lib/libstdc++.so.2.10.0
> Reading symbols from /usr/lib/libm.so.1...done.
> Loaded symbols for /usr/lib/libm.so.1
> Reading symbols from /usr/lib/libc.so.1...done.
> Loaded symbols for /usr/lib/libc.so.1
> Reading symbols from /home/oracle/OraHome1/lib/libwtc8.so...done.
> Loaded symbols for /home/oracle/OraHome1/lib/libwtc8.so
> Reading symbols from /usr/lib/libnsl.so.1...done.
> Loaded symbols for /usr/lib/libnsl.so.1
> Reading symbols from /usr/lib/libsocket.so.1...done.
> Loaded symbols for /usr/lib/libsocket.so.1
> Reading symbols from /usr/lib/libgen.so.1...done.
> Loaded symbols for /usr/lib/libgen.so.1
> Reading symbols from /usr/lib/libdl.so.1...done.
> Loaded symbols for /usr/lib/libdl.so.1
> Reading symbols from /usr/lib/libsched.so.1...done.
> Loaded symbols for /usr/lib/libsched.so.1
> Reading symbols from /usr/lib/libaio.so.1...done.
> Loaded symbols for /usr/lib/libaio.so.1
> Reading symbols from /usr/lib/libmp.so.2...done.
> (gdb) backtrace
> #0 0xfed1b02c in upirtrc () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #1 0xfed1a644 in upirtr () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #2 0xfed485c8 in kpugemh () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #3 0xfed47b28 in kpusebh () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #4 0xfed20184 in kputxabt () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #5 0xfecdd884 in sqlv8c () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #6 0xfecde220 in sqllam () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #7 0xfecbe8a8 in sqllo3t () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #8 0xfecbb658 in sqlcnt () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #9 0xfecbdb50 in sqlexp () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #10 0xfecb58b0 in sqlcmex () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #11 0xfecb5efc in sqlcxt () from
> /home/oracle/OraHome1/lib/libclntsh.so.8.0
> #12 0xabbcc in database::connect (this=0x1d2a28, userid=_at_0x1d2a30,
> password=_at_0x1d2a34, sid=_at_0xffbeeff8) at db-database.pc:74
> #13 0xab83c in database::database (this=0x1d2a28, userid=_at_0x1d1b28,
> password=_at_0x1d1b2c, sid=_at_0xffbeeff8) at db-database.pc:51
> #14 0x7f094 in auth_backend (_pe=0xfebd0068, _mq=0x1d1a80)
> at auth-backend.cc:271
> #15 0x79df0 in start_process (type=pt_backend) at auth-watchdog.cc:170
> #16 0x7a55c in check_processes (server_startup=0) at
> auth-watchdog.cc:250
> #17 0x7af0c in auth_watchdog (_pet=0x1f2d90, _mq=0x1d1a80)
> at auth-watchdog.cc:433
> #18 0x791ac in main (argc=3, argv=0xffbef304) at auth-main.cc:117
>
> This codes functions fine if it is compiled against Oracle 7.3.4
> (and has been fine for about 3 years)
>
> I can write sample programs using the same database connection
> libraries that use for the above program, and they work fine. I
> can also fork() additional processes, and connect to the database
> fine.
>
> Why would a child process die with a segfault when trying to connect?
> I've verified the parameters, and they all look fine. I'm using this
> make sequence to compile all my code:
>
> ./qproc user=userid/password_at_sid \
> lines=y sqlcheck=full code=cpp cpp_suffix=cc test.pc
> g++ -fno-implicit-templates -ggdb -gstabs+ -DCOMPILE -DSQLCA_NONE
> -I/home/oracle/OraHome1/precomp/public -I../support -c -o test.o
> test.cc
> g++ -otest test.o -L../support -ltemplates -lsupport
> -L/home/oracle/OraHome1/lib -lclntsh -L. -ldatabase -L../support
> -lsupport
> rm test.cc
>
> The system I'm developing on is not hosting any databases; it's
> acting as a client only.
>
> Could this be a proc configuration/option problem? After reading
> the documentation, I'm not sure it is, but I'm open to any hints...
>
> Any suggestions would be much appreciated. I've searched usenet,
> but not found any hits on this particular problem. Searching on
> Oracle's site has not yielded any results either.
>
> Thanks!
>
> -klm.

I had the same problem and had to compile a separate executable for the oracle7 and oracle8 databases. The executable compiled in the oracle7 environment would not run against the oracle8 database or vice versa.

-- 

Gerard H. Pille