free()被mutex锁住的问题

xinxuran

遇到好几次了，都不知道是为什么，下面是gdb下的stack：
#0  0x00497402 in __kernel_vsyscall ()
#1  0x002e496e in __lll_mutex_lock_wait () from /lib/libc.so.6
#2  0x0027501e in _L_lock_14512 () from /lib/libc.so.6
#3  0x00274544 in free () from /lib/libc.so.6
#4  0x0028a5ff in tzset_internal () from /lib/libc.so.6
#5  0x0028af0d in tzset () from /lib/libc.so.6
#6  0x0028f5a6 in strftime_l () from /lib/libc.so.6
#7  0x002d44cf in __vsyslog_chk () from /lib/libc.so.6
#8  0x002d4997 in vsyslog () from /lib/libc.so.6
#9  0x00269108 in __libc_message () from /lib/libc.so.6
#10 0x00270efd in _int_free () from /lib/libc.so.6
#11 0x00274550 in free () from /lib/libc.so.6
#12 0x0070b082 in syst_IFVlanFree (pstIfVlan=0x971c20 at st_vlan.c:78
#13 0x006f54e0 in syst_LogicalFree (pstLogicInfo=0x971c17 at st_cli.c:6454

下面的是与上面同一个进程中的另一个线程，也被锁住了：
#0  0x00497402 in __kernel_vsyscall ()
#1  0x002e496e in __lll_mutex_lock_wait () from /lib/libc.so.6
#2  0x0027501e in _L_lock_14512 () from /lib/libc.so.6
#3  0x00274544 in free () from /lib/libc.so.6
#4  0x0013f407 in PQclear () from /usr/local/pgsql/lib/libpq.so.5
#5  0x00bf9ada in db_ClearRes (pstDBH=0xb2795580) at db_driver.c:100
#6  0x00bfa25e in db_Exec (pstDBH=0xb2795580, pcSqlStr=0xb1c025e8 "DEALLOCATE
info_devmac2id" at db_driver.c:261

咋回事呢？

flw2

在信号处理函数中干什么了？

Aquester

这样的问题，通常是一个线程进入了信号处理，在信号处理过程中，调用打印语句都可能造成死锁。

_nosay

有哪位遇到这种情况解决了，欢迎指教 。

_nosay

你好，关于调用free()的时候，程序停留在__lll_mutex_lock_wait ()的问题，想请教你怎么去思考解决的办法。
有高手告诉我可能是写越界导致的，但我个人觉得如果是写越界，有大量数据输入的情况下，程序应该很快就会挂掉，而且程序不会每次都那麽有规律的停在同一个free()的地方；
听你说大多是因为信号处理导致的，但我现在的程序相比之前的版本，信号处理部分一点都没有修改，之前的版本能运行的很稳定，如果你有处理过这种问题，想向你请教一下方法。
回复 3# Aquester


   

_nosay

你好，关于调用free()的时候，程序停留在__lll_mutex_lock_wait ()的问题，想请教你怎么去思考解决的办法。
有高手告诉我可能是写越界导致的，但我个人觉得如果是写越界，有大量数据输入的情况下，程序应该很快就会挂掉，而且程序不会每次都那麽有规律的停在同一个free()的地方；
听你说大多是因为信号处理导致的，但我现在的程序相比之前的版本，信号处理部分一点都没有修改，之前的版本能运行的很稳定，如果你有处理过这种问题，想向你请教一下方法。
回复 2# flw2


   

Aquester

_nosay 发表于 2013-01-07 15:57
你好，关于调用free()的时候，程序停留在__lll_mutex_lock_wait ()的问题，想请教你怎么去思考解决的办法。 ...

越界也是会造成死锁，原因是将锁的计算数值改了

_nosay

嗯，但是太有规律了，我自己想像有两种情况：
① 如果是普通的写越界，打个不形象的比喻，程序执行起来就会像个“疯狂的画家”，到处乱写乱涂，程序不会那麽有规律的每次都被锁在free()里，而且也运行不到三天的时间；
② 如果真的是写越界，那程序仍然是“画家”，但是一个低调、有规律的“画家”，到某个特定的时机时，他会到一个特定的地方点上一笔（即导致free()锁住的那个变量），那麽这个“画家”是什么？这个特定的时机又是什么？
目前，我注释了一些无关紧要的东西，并把整个模块的结构做了一个比较大的改动，程序竟然已经稳定的运行了一个星期了，真无解！
回复 7# Aquester


   

crazyhadoop

这个没有具体的场景不好分析啊

Aquester

_nosay 发表于 2013-01-22 09:13
嗯，但是太有规律了，我自己想像有两种情况：
① 如果是普通的写越界，打个不形象的比喻，程序执行起来就会 ...

有没有，使用valgrind跑一下就知道了，借助工具，可以省去很多力气。