Root crashes on Oracle database access

ROOT
1

On our local installation of root, we include the --enable-oracle option
in order to get Oracle database support. However, when we do simple
tests, we get strange crashes. An example of a back trace is
attached. The crashed happened after the commands, entered by hand:

TSQLServer *db = TSQLServer::Connect(“oracle://host:port”,“user”, “pass”);
std::cout << db->GetHost() << std::endl;
std::cout << db->ServerInfo() << std::endl;

The crash happened at ServerInfo() call, while root was processing
the return result set from “SELECT * FROM V$SESSION”. We cannot
reproduce the problem on lxplus, so we suspect some sort of installation
or compile problem? The config options used are:

–build=debug --enable-oracle --enable-python
–with-oracle-libdir=/opt/wbm/programs/oracle_client/10.2.0.1/lib
–with-oracle-incdir=/opt/wbm/programs/oracle_client/10.2.0.1/rdbms/public

The system is 32 bit Linux:
uname -a
Linux srv-C2D05-05 2.6.9-55.EL.cernsmp #1 SMP Thu May 10 18:16:29 CEST 2007 i686 i686 i386 GNU/Linux

Any ideas on what we might be doing wrong?

2

Here is the backtrace:

GNU gdb Red Hat Linux (6.3.0.0-1.143.el4rh)
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 “i386-redhat-linux-gnu”…Using host libthread_db library “/lib/tls/libthread_db.so.1”.

(gdb) run
Starting program: /opt/wbm/programs/root/5.21.04/bin/root.exe
[Thread debugging using libthread_db enabled]
[New Thread -1208289600 (LWP 4912)]

  •                                     *

  •    W E L C O M E  to  R O O T       *

  •                                     *
  • Version 5.21/04 2 October 2008 *
  •                                     *
  • You are welcome to visit our Web site *
  •      [root.cern.ch](http://root.cern.ch)            *

  •                                     *

ROOT 5.21/04 (trunk@25661, Oct 14 2008, 23:17:00 on linux)

CINT/ROOT C/C++ Interpreter version 5.16.29, Jan 08, 2008
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
Detaching after fork from child process 4954.
cmsonr1-v

Program received signal SIGABRT, Aborted.
[Switching to Thread -1208289600 (LWP 4912)]
0x004e07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0 0x004e07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x0755f7a5 in raise () from /lib/tls/libc.so.6
#2 0x07561209 in abort () from /lib/tls/libc.so.6
#3 0x07593a1a in __libc_message () from /lib/tls/libc.so.6
#4 0x0759a2bf in _int_free () from /lib/tls/libc.so.6
#5 0x0759a63a in free () from /lib/tls/libc.so.6
#6 0x0035a041 in operator delete () from /usr/lib/libstdc++.so.6
#7 0x0033bd6f in std::string::_Rep::_M_destroy () from /usr/lib/libstdc++.so.6
#8 0x0033bff2 in std::basic_string<char, std::char_traits, std::allocator >::~basic_string () from /usr/lib/libstdc++.so.6
#9 0x0040955b in TOracleStatement::GetString (this=0x8e9b358, npar=0)
at sql/oracle/src/TOracleStatement.cxx:792
#10 0x00403756 in TOracleServer::ServerInfo (this=0x8e4b6d8)
at sql/oracle/src/TOracleServer.cxx:519
#11 0x0516cd43 in G__G__Net_272_0_21 ()
from /opt/wbm/programs/root/5.21.04/lib/libNet.so
#12 0x00c01a23 in Cint::G__ExceptionWrapper (
funcp=0x516cd12 <G__G__Net_272_0_21(G__value*, char const*, G__param*, int)>, result7=0xbfe04530, funcname=0x8e28ec0 “\001”, libp=0xbfdfe6b0, hash=0)
at cint/cint/src/Api.cxx:381
#13 0x00ca8efe in G__execute_call (result7=0xbfe04530, libp=0xbfdfe6b0,
ifunc=0x8e28ec0, ifn=0) at cint/cint/src/newlink.cxx:2330
#14 0x00ca961e in G__call_cppfunc (result7=0xbfe04530, libp=0xbfdfe6b0,
ifunc=0x8e28ec0, ifn=0) at cint/cint/src/newlink.cxx:2516
#15 0x00c8b16c in G__interpret_func (result7=0xbfe04530,
funcname=0xbfe04130 “ServerInfo”, libp=0xbfdfe6b0, hash=1027,
p_ifunc=0x8e28ec0, funcmatch=1, memfunc_flag=1)
at cint/cint/src/ifunc.cxx:5265
#16 0x00c71a3c in G__getfunction (item=0xbfe07374 “ServerInfo()”,
known3=0xbfe0678c, memfunc_flag=1) at cint/cint/src/func.cxx:2534
#17 0x00d61a1b in G__getstructmem (store_var_type=112,
varname=0xbfe04780 “p\016ß”, membername=0xbfe07374 “ServerInfo()”,
tagname=0xbfe04990 “db”, known2=0xbfe0678c, varglobal=0xdffdc0, objptr=2)
at cint/cint/src/var.cxx:6624
#18 0x00d55b0a in G__getvariable (item=0xbfe07370 “db->ServerInfo()”,
known=0xbfe0678c, varglobal=0xdffdc0, varlocal=0x0)
at cint/cint/src/var.cxx:5253
#19 0x00c65689 in G__getitem (item=0xbfe07370 “db->ServerInfo()”)
at cint/cint/src/expr.cxx:1884
#20 0x00c5c969 in G__getexpr (
expression=0xbfe08bd0 “std::cout<< db->ServerInfo()<< std::endl”)
at cint/cint/src/expr.cxx:1288
#21 0x00cdbc2c in G__exec_statement (mparen=0xbfe09060)
at cint/cint/src/parse.cxx:6608
#22 0x00c41db0 in G__exec_tempfile_core (file=0x0, fp=0x8eab398)
at cint/cint/src/debug.cxx:251
#23 0x00c432f0 in G__exec_tempfile_fp (fp=0x8eab398)
at cint/cint/src/debug.cxx:791
#24 0x00ce809a in G__process_cmd (
line=0x8eb7638 “std::cout << db->ServerInfo() << std::endl;”,
prompt=0x8c23214 “”, more=0x8c2320c, err=0xbfe126cc, rslt=0xbfe126d0)
at cint/cint/src/pause.cxx:3236
#25 0x0071ac60 in TCint::ProcessLine (this=0x8c231f0,
line=0x8eb7638 “std::cout << db->ServerInfo() << std::endl;”, error=0x0)
at core/meta/src/TCint.cxx:420
#26 0x00623a0f in TApplication::ProcessLine (this=0x8c45998,
line=0x8eb7638 “std::cout << db->ServerInfo() << std::endl;”, sync=false,
err=0x0) at core/base/src/TApplication.cxx:820
#27 0x0029988e in TRint::HandleTermInput (this=0x8c45998)
at core/rint/src/TRint.cxx:514
#28 0x00297752 in TTermInputHandler::Notify (this=0x8dffea8)
at core/rint/src/TRint.cxx:123
#29 0x0029a670 in TTermInputHandler::ReadNotify (this=0x8dffea8)
at core/rint/src/TRint.cxx:115
#30 0x0072e316 in TUnixSystem::CheckDescriptors (this=0x8c20918)
at core/unix/src/TUnixSystem.cxx:1190
#31 0x0072d704 in TUnixSystem::DispatchOneEvent (this=0x8c20918,
pendingOnly=false) at core/unix/src/TUnixSystem.cxx:897
#32 0x00694286 in TSystem::InnerLoop (this=0x8c20918)
at core/base/src/TSystem.cxx:391
#33 0x00694054 in TSystem::Run (this=0x8c20918)
at core/base/src/TSystem.cxx:341
#34 0x006244a6 in TApplication::Run (this=0x8c45998, retrn=false)
at core/base/src/TApplication.cxx:959
#35 0x0029911a in TRint::Run (this=0x8c45998, retrn=false)
at core/rint/src/TRint.cxx:386
#36 0x08048de3 in main (argc=1, argv=0xbfe14bb4) at main/src/rmain.cxx:29
(gdb) q
The program is running. Exit anyway? (y or n)

3

Hi, William

Can you check that ROOT uses correct Oracle libraries? Just type:

ldd $ROOTSYS/lib/libOracle.so

You should see which libocci.so and libclntsh.so libraries are used. For you configuration they should be from /opt/wbm/programs/oracle_client/10.2.0.1/lib directory. If not, put this path in front of LD_LIBRARY_PATH variable:

export LD_LIBRARY_PATH=/opt/wbm/programs/oracle_client/10.2.0.1/lib:$LD_LIBRARY_PATH

Regards,
Sergey

4

I checked libOracle.so , and found that it was using
some oracle libraries in /usr/lib. Shouldn’t the
–with-oracle-libdir qualifier have overridden that?

Anyhow, with LD_LIBRARY_PATH explicitly pointing
to the correct oracle library area, I have rebuilt the root libraries,
and “ldd libOracle.so” look correct. However, I am still
getting the same crash as above.

5

Hi, William

Are you sure your that correct LD_LIBRAY_PATH configured when you start your script? Can it be, that some other oracle libs missing in your local directory and taken from /usr/lib? Your problem looks really like library mismatch.

Sergey