#21 Nested mutex deadlock

[Anonymous]

I often encounter the following error with the
'opengatekeeper':

Assertion fail: file tlibthrd.cxx, Line 953
Nested mutex deadlock

After that, the gatekeeper still remains alive but is
unable to accept registrations and calls.

I attach my opengate.ini configuration file.

Has anyone solved this problem?

[Nobody/Anonymous]

Configuration file

[Nobody/Anonymous]

Logged In: NO

I have the similar problem but with the 1188 line of
tlibthrd.cxx. In my config IsGKrouted is set to 1. I ran an
h323 simulator to perform intensives tests.

By analysing the core dump I obtain this with gdb :

gdb opengate core
bt
#0 0x401c4801 in __kill () from /lib/i686/libc.so.6
#1 0x4003b067 in __pthread_restart_new (th=0x410c7c00) at
pthread.c:1038
#2 0x4003cc61 in __pthread_alt_unlock (lock=0x8559800) at
restart.h:24
#3 0x40039d54 in __pthread_mutex_unlock (mutex=0x85597f0)
at mutex.c:195
#4 0x082b0991 in PMemoryHeap::Wrapper::~Wrapper
(this=0x416c7678, __in_chrg=2) at ../common/object.cxx:293
#5 0x082b0bcb in PMemoryHeap::Allocate (nSize=12,
file=0x8440dc6 "../common/contain.cxx", line=410, className=0x0)
at ../common/object.cxx:356
#6 0x083fe766 in operator new (nSize=12, file=0x8440dc6
"../common/contain.cxx", line=410) at
/root/pwlib/include/ptlib/object.h:940
#7 0x082a8622 in PContainer::PContainer (this=0x416c77c0,
initialSize=0) at ../common/contain.cxx:410
#8 0x082a7f20 in PCollection::PCollection (this=0x416c77c0,
initialSize=0) at /root/pwlib/include/ptlib/contain.inl:367
#9 0x082a5b60 in PHashTable::PHashTable (this=0x416c77c0)
at ../common/collect.cxx:1373
#10 0x082a857d in PAbstractDictionary::PAbstractDictionary
(this=0x416c77c0) at /root/pwlib/include/ptlib/contain.inl:460
#11 0x083ac1ad in
Q931::InternalInformationElements::InternalInformationElements
(this=0x416c77c0) at /root/openh323/include/q931.h:332
#12 0x081d0b8b in Q931::Q931 (this=0x416c77ac) at q931.cxx:148
#13 0x0808f1a2 in SignallingThread::ReceiveMesg
(this=0x85f0178, FromCaller=false) at CallThread.cxx:783
#14 0x0808f411 in SignallingThread::Main (this=0x85f0178) at
CallThread.cxx:826
#15 0x082a04aa in PThread::PX_ThreadStart (arg=0x85f0178) at
tlibthrd.cxx:639
#16 0x40038bfd in pthread_start_thread (arg=0x416c7c00) at
manager.c:262

It seems to be a bug with glibc.6 with the Mutex functions.
It appears when a second thread is blocked by Mutex lock.

[Nobody/Anonymous]

Logged In: NO

I have exactly the same problem:

Assertion fail: file tlibthrd.cxx, Line 953
Nested mutex deadlock

I haven't solved the problem, but I have verified that this
error only happens when you make a call to somebody that is
not registered on your GKR. If you do that, your GKR sends
LRQ messages to other known GKRs, and if any GKR answers
with an LCF, then the called is registered on your GKR as a
temporary user (AkaIsLocal parameter is set to false). After
that, the GKR starts a timeout . When it's finished the GKR
should remove this user from the Endpoint Table, but
when it tries to do that...the error appears!
You can change the general endpoint TTL on your opengate.ini
configuration file, so you can control when the error
happens, but it will always appear; or you can change this
TTL directly on RasServer.cxx , adding the TTL parameter to
Endpont->Insert on DecodeLCF function.
If you do nothing the error will appear exactly ten
minutes after you made the call (TTL default value).

Does anyone know how to solve this problem?

[Nobody/Anonymous]

Logged In: NO

-- Date: 2001-09-10 06:55
-- Sender: nobody
-- Logged In: NO
--
-- I have exactly the same problem:
--
-- Assertion fail: file tlibthrd.cxx, Line 953
-- Nested mutex deadlock
--
-- I haven't solved the problem, but I have
verified that this
-- error only happens when you make a call to
somebody that is
-- not registered on your GKR. If you do that,
your GKR sends
-- LRQ messages to other known GKRs, and if any
GKR answers
-- with an LCF, then the called is registered on
your GKR as a
-- temporary user (AkaIsLocal parameter is set
to false). After
-- that, the GKR starts a timeout .

I wanted to say 'timer' and not 'timeout'. Sorry...

[...]