OCCI一个程序卡死的问题,附GDB的一些信息

sanluojiyi3344 2015-03-09 04:58:48
原帖:http://bbs.csdn.net/topics/390994303

由于OCCI的接口无法调试(汇编看不懂),而且GDB今天才第一天使用。。。
总之看信息像是在OCCI的createConnection函数中卡住了?
下面是GDB的一些信息,求帮忙,这几天被这快搞疯了。。
[ChangLin@ChangLin SCTLX_DBOper_5.0]$ ps -ef | grep -v grep | grep test
ChangLin 3472 3382 98 16:44 pts/1 02:43:42 ./testDBOper.exe
ChangLin 15240 1 0 14:40 ? 00:00:12 kdevelop --profile KDECppIDE file:///home/ChangLin/Desktop/SCTLX_DBOper_5.0/testDBOperConf.ini

[ChangLin@ChangLin SCTLX_DBOper_5.0]$ gdb -p 3472
GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5)
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Attaching to process 3472
Reading symbols from /mnt/hgfs/Shared Files/SCTLX_DBOper_5.0/testDBOper.exe...done.

warning: .dynamic section for "/lib/libnsl.so.1" is not at the expected address

warning: difference appears to be caused by prelink, adjusting expectations
Reading symbols from libSCTLX_DBOper.so...done.
Loaded symbols for libSCTLX_DBOper.so
Reading symbols from /lib/i686/nosegneg/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 0xadbf7b90 (LWP 25741)]
[New Thread 0xb03fbb90 (LWP 25740)]
[New Thread 0xae5f8b90 (LWP 25739)]
[New Thread 0xaf9fab90 (LWP 25738)]
[New Thread 0xb0dfcb90 (LWP 25737)]
[New Thread 0xb17fdb90 (LWP 25736)]
[New Thread 0xb21feb90 (LWP 25735)]
[New Thread 0xb2bffb90 (LWP 25734)]
[New Thread 0xb37afb90 (LWP 25733)]
[New Thread 0x7facb90 (LWP 25732)]
[New Thread 0x719bb90 (LWP 25731)]
[New Thread 0x679ab90 (LWP 25730)]
[New Thread 0x532eb90 (LWP 25729)]
[New Thread 0x492db90 (LWP 25728)]
[New Thread 0x3f2cb90 (LWP 25727)]
[New Thread 0x5d99b90 (LWP 25726)]
[New Thread 0x352bb90 (LWP 25725)]
[New Thread 0xaeff9b90 (LWP 25723)]
[New Thread 0x2554b90 (LWP 3477)]
Loaded symbols for /lib/i686/nosegneg/libpthread.so.0
Reading symbols from /usr/lib/libstdc++.so.5...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libstdc++.so.5
Reading symbols from /usr/lib/libstdc++.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libstdc++.so.6
Reading symbols from /lib/i686/nosegneg/libm.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/i686/nosegneg/libm.so.6
Reading symbols from /lib/libgcc_s.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/i686/nosegneg/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/i686/nosegneg/libc.so.6
Reading symbols from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1...(no debugging symbols found)...done.
Loaded symbols for /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
Reading symbols from /home/ChangLin/OCCI/instantclient_10_2/libocci.so.10.1...(no debugging symbols found)...done.
Loaded symbols for /home/ChangLin/OCCI/instantclient_10_2/libocci.so.10.1
Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /home/ChangLin/OCCI/instantclient_10_2/libnnz10.so...(no debugging symbols found)...done.
Loaded symbols for /home/ChangLin/OCCI/instantclient_10_2/libnnz10.so
Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /home/ChangLin/OCCI/instantclient_10_2/libociei.so...(no debugging symbols found)...done.
Loaded symbols for /home/ChangLin/OCCI/instantclient_10_2/libociei.so
Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/libnss_files.so.2
0x004a8402 in __kernel_vsyscall ()
(gdb) bt
#0 0x004a8402 in __kernel_vsyscall ()
#1 0x00d2a7b9 in __lll_lock_wait () from /lib/i686/nosegneg/libpthread.so.0
#2 0x00d25e0f in _L_lock_885 () from /lib/i686/nosegneg/libpthread.so.0
#3 0x00d25cd6 in pthread_mutex_lock () from /lib/i686/nosegneg/libpthread.so.0
#4 0x00ae5421 in SCTDBConnect(char const*, int*, char*) ()
from libSCTLX_DBOper.so
#5 0x0804b317 in main ()
(gdb) frame 1
#1 0x00d2a7b9 in __lll_lock_wait () from /lib/i686/nosegneg/libpthread.so.0
(gdb) print *((int*)($ebx)+2)
$5 = 25730
(gdb) info thr
20 Thread 0x2554b90 (LWP 3477) 0x004a8402 in __kernel_vsyscall ()
19 Thread 0xaeff9b90 (LWP 25723) 0x004a8402 in __kernel_vsyscall ()
18 Thread 0x352bb90 (LWP 25725) 0x004a8402 in __kernel_vsyscall ()
17 Thread 0x5d99b90 (LWP 25726) 0x004a8402 in __kernel_vsyscall ()
16 Thread 0x3f2cb90 (LWP 25727) 0x004a8402 in __kernel_vsyscall ()
15 Thread 0x492db90 (LWP 25728) 0x004a8402 in __kernel_vsyscall ()
14 Thread 0x532eb90 (LWP 25729) 0x004a8402 in __kernel_vsyscall ()
13 Thread 0x679ab90 (LWP 25730) 0x017fde06 in lxoCvChar ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
12 Thread 0x719bb90 (LWP 25731) 0x004a8402 in __kernel_vsyscall ()
11 Thread 0x7facb90 (LWP 25732) 0x004a8402 in __kernel_vsyscall ()
10 Thread 0xb37afb90 (LWP 25733) 0x004a8402 in __kernel_vsyscall ()
9 Thread 0xb2bffb90 (LWP 25734) 0x004a8402 in __kernel_vsyscall ()
8 Thread 0xb21feb90 (LWP 25735) 0x004a8402 in __kernel_vsyscall ()
7 Thread 0xb17fdb90 (LWP 25736) 0x004a8402 in __kernel_vsyscall ()
6 Thread 0xb0dfcb90 (LWP 25737) 0x004a8402 in __kernel_vsyscall ()
5 Thread 0xaf9fab90 (LWP 25738) 0x004a8402 in __kernel_vsyscall ()
4 Thread 0xae5f8b90 (LWP 25739) 0x004a8402 in __kernel_vsyscall ()
3 Thread 0xb03fbb90 (LWP 25740) 0x004a8402 in __kernel_vsyscall ()
2 Thread 0xadbf7b90 (LWP 25741) 0x004a8402 in __kernel_vsyscall ()
* 1 Thread 0xb7eea6d0 (LWP 3472) 0x004a8402 in __kernel_vsyscall ()
(gdb) thr 13
[Switching to thread 13 (Thread 0x679ab90 (LWP 25730))]#0 0x017fde06 in lxoCvChar () from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
(gdb) bt
#0 0x017fde06 in lxoCvChar ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#1 0x018d0e08 in LdiMatchString ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#2 0x0188f89d in ldipmbf ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#3 0x0188e7c2 in Ldisnf ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#4 0x0188b1f0 in LdiParseForInputType ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#5 0x0188b60a in LdiParseForInput ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#6 0x018889d4 in LdiInitDef ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#7 0x00f03009 in kpussi ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#8 0x00f5c07b in kpuauthxa ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#9 0x00f5b84d in kpuauth ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#10 0x00f9674f in kpuspsessionget ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#11 0x00fee04e in OCISessionGet ()
from /home/ChangLin/OCCI/instantclient_10_2/libclntsh.so.10.1
#12 0x005029c8 in oracle::occi::ConnectionImpl::openConnection(OCIEnv*, OCIError---Type <return> to continue, or q <return> to quit---
*, void*, unsigned int, void*, unsigned int, void*, unsigned int, void*, unsigned int, unsigned int) ()
from /home/ChangLin/OCCI/instantclient_10_2/libocci.so.10.1
#13 0x004ffa22 in _ZN6oracle4occi14ConnectionImplC9EPNS0_15EnvironmentImplERKSsS5_S5_ () from /home/ChangLin/OCCI/instantclient_10_2/libocci.so.10.1
#14 0x005040ab in oracle::occi::ConnectionImpl::ConnectionImpl(oracle::occi::EnvironmentImpl*, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) () from /home/ChangLin/OCCI/instantclient_10_2/libocci.so.10.1
#15 0x004fe763 in oracle::occi::EnvironmentImpl::createConnection(std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
from /home/ChangLin/OCCI/instantclient_10_2/libocci.so.10.1
#16 0x00ae5798 in SCTDBConnect(char const*, int*, char*) ()
from libSCTLX_DBOper.so
#17 0x0804991d in SCTTestThread(void*) ()
#18 0x00d23869 in start_thread () from /lib/i686/nosegneg/libpthread.so.0
#19 0x0040ee9e in clone () from /lib/i686/nosegneg/libc.so.6

...全文
459 7 打赏 收藏 转发到动态 举报
写回复
用AI写文章
7 条回复
切换为时间正序
请发表友善的回复…
发表回复
卓喻创新 2018-12-27
  • 打赏
  • 举报
回复
"try..catch 一直都有的,我也觉得这问题诡异,不管是用OCCI还是OCILIB都有这种情况,现在我临时的解决方法也只有像你之前说的,做个超时的判断,创建连接的时候我放到一个新建的线程中去createConnetion,本线程自己只做一下计时,超时的话那只能pthread_cancel了"

超时结束线程会有内存泄漏,程序迟早要宕机。我也遇到这个问题,createConnetion卡死不返回,请问高手后来如何解决的。
空的 2015-03-11
  • 打赏
  • 举报
回复
当系统出现数据库服务器宕机或网线插拔的情况时, 进程将阻塞于正调用的OCI函数上,如果故障不能及时恢复, OCI函数将长时间阻塞,对应用程序来讲,大多数情况下这是不允许的 上面这个网上找的,oci/occi 只是实现方式不同吧,功能差不多吧,不知道对不对的上 建议长ping oracleserver ,看看网络连接稳不稳,或者手工试下~
sanluojiyi3344 2015-03-11
  • 打赏
  • 举报
回复
引用 5 楼 erhou134 的回复:
没啥想法了,connect的时候加个try catch试试?
try..catch 一直都有的,我也觉得这问题诡异,不管是用OCCI还是OCILIB都有这种情况,现在我临时的解决方法也只有像你之前说的,做个超时的判断,创建连接的时候我放到一个新建的线程中去createConnetion,本线程自己只做一下计时,超时的话那只能pthread_cancel了。。
空的 2015-03-11
  • 打赏
  • 举报
回复
没啥想法了,connect的时候加个try catch试试?
sanluojiyi3344 2015-03-11
  • 打赏
  • 举报
回复
引用 3 楼 erhou134 的回复:
当系统出现数据库服务器宕机或网线插拔的情况时, 进程将阻塞于正调用的OCI函数上,如果故障不能及时恢复, OCI函数将长时间阻塞,对应用程序来讲,大多数情况下这是不允许的 上面这个网上找的,oci/occi 只是实现方式不同吧,功能差不多吧,不知道对不对的上 建议长ping oracleserver ,看看网络连接稳不稳,或者手工试下~
这是一种可能,但是我这个应用不会是这个问题,因为数据库就安装在本机的oracle用户上的。。。
空的 2015-03-10
  • 打赏
  • 举报
回复
话说你数据库连的上吗,特别是程序卡死的时候,手工sqlplus 连连看,如果oracle连接超了或者什么的,那是一直卡着的 这个SCTDBConnect可以设置超时吗,或者来个定时器中断,或者搞成try_lock几次,锁不上就返错,避免全都等锁释放
sanluojiyi3344 2015-03-10
  • 打赏
  • 举报
回复
引用 1 楼 erhou134 的回复:
话说你数据库连的上吗,特别是程序卡死的时候,手工sqlplus 连连看,如果oracle连接超了或者什么的,那是一直卡着的 这个SCTDBConnect可以设置超时吗,或者来个定时器中断,或者搞成try_lock几次,锁不上就返错,避免全都等锁释放
只有你一个人有在关注我的这个问题。。。 非常感谢!! 程序卡死的时候,使用sqlplus是可以连接数据库的,连接数或者游标数在问题一出现的时候就第一时间去查看了,都是正常的。 我的代码中确实是 Lock() createConnection() UnLock() 这样的顺序,所以确实可以将锁去掉以保证其他线程不会卡死,但是这不是好方法,因为如果某个线程卡在createConnection()里死活出不来,那么就算其他线程可以工作,也早晚会一个个完蛋的。 而且该线程一直卡着的话也会影响业务。 至于设置超时,我是有这么打算,但是好像没有好的方法,有什么好的建议吗?

23,114

社区成员

发帖
与我相关
我的任务
社区描述
Linux/Unix社区 应用程序开发区
社区管理员
  • 应用程序开发区社区
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧