Bugs item #2948561, was opened at 2010-02-09 16:38
Message generated for change (Settings changed) made by wdoekes
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=1086410aid=2948561group_id=232389
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: 1.6.x
Status: Open
Resolution: Accepted
Priority: 1
Private: No
Submitted By: Walter Doekes (wdoekes)
Assigned to: Anca Vamanu (anca_vamanu)
Summary: deadlock on pua presentity lock
Initial Comment:
Hi,
when sending the PUBLISH messages to self, using:
modparam(pua_dialoginfo, presence_server, sip:a.b.c.d:5060) # send
PUBLISH messages to self
I get a deadlock of the entire opensips daemon.
If I send the messages to somewhere else, the deadlock does not occur.
If I release the locks as per the attached patch, the deadlock doesn't occur
either.
But according to the comments in the code, the lock is not meant to be freed
just yet. So I'm not sure what my patch breaks instead. (I'm not even sure I'm
supposed to publish to self, but it seems like it, as I want to generate
notifies based on the state changes found in the publish.)
I'm running 1.6-svn (r6568)
Regards,
Walter Doekes
OSSO B.V.
--
Comment By: Walter Doekes (wdoekes)
Date: 2010-02-24 07:59
Message:
Furthermore, I can add that I used children=1.
(Having children as 1 also led me to believe that setting $var()s in
startup_route could be used as process-wide constants, which they cannot.
This should clear up some more of the odd issues I was having. How would
you feel about a process_startup_route? I cannot believe I'm the only one
who likes constants at the top of the file.)
--
Comment By: Walter Doekes (wdoekes)
Date: 2010-02-12 09:11
Message:
Hi Anca,
Thanks for your quick reply.
I've tried to reduce/declutter my config file to make it easily
reproducable, but during this reduction the problem goes away. I can hardly
give you the full config file as it's a bit of a complex hack, and
incomplete at that ;)
Yes, what I want to do is implement BLF on OpenSIPS. To do this, I do
basically this:
route {
if (uri == myself) {
if ($si == e.f.g.h) { # my IP
if (method == PUBLISH) {
handle_publish(sip:mys...@myself.myself);
exit;
}
}
if (method == SUBSCRIBE) {
handle_subscribe();
exit;
}
if (method == INVITE) {
dialoginfo_set();
record_route();
}
if ($si == a.b.c.d) {
$var(local) = sip: + $(hdr(X-PIDstAccount)[-1]) + @anydomain;
lookup(opensips_location, , $var(local));
} else {
$rd = a.b.c.d;
}
t_relay();
}
}
(Add a bit of nat handling, registration handling and transaction
handling.)
Modules loaded are:
loadmodule xlog.so# logging (xlog)
loadmodule sl.so # stateless functions (sl_*)
loadmodule tm.so # t_*: transactions in memory
loadmodule signaling.so # send reply according to state
loadmodule rr.so # record route
loadmodule nathelper.so # fix_nated_*()
loadmodule textops.so # append_hf
loadmodule uri.so # has_totag
loadmodule db_mysql.so# mysql
loadmodule auth.so# digest auth
loadmodule auth_db.so # digest auth
loadmodule group.so # groups (for acls)
loadmodule permissions.so # permissions (provide acls together with
groups)
loadmodule usrloc.so # user location
loadmodule registrar.so # lookup/save/registered
loadmodule dialog.so # ...
loadmodule presence.so# handle SUBSCRIBE events
loadmodule presence_dialoginfo.so # handle SUBSCRIBE events for
dialoginfo
loadmodule presence_xml.so# handle SUBSCRIBE events for dialoginfo
loadmodule pua.so # ...
loadmodule pua_dialoginfo.so # ...
...
modparam(pua_dialoginfo, presence_server, sip:e.f.g.h:5060) # send
PUBLISH messages to self
Now, it's quite possible that I'm doing things wrong. My grandstream test
phone has not answered at all to the opensips NOTIFY's sent by
handle_publish().
I'll try re-adding and reorganising my config file to get back the
complete behaviour I want (with or without the deadlock). In the mean time
you can consider this report INVALID/WORKSFORME and I can file a new one if
the problem re-appears.
Regards,
Walter
--
Comment By: Anca Vamanu (anca_vamanu)
Date: 2010-02-09 17:53
Message:
Hi Walter,
That is not the right fix, because that lock must actually be kept until
the reply is received. I want to reproduce this myself to be able to
investigate. I don't understand exactly which is the case when you get
deadlock. You subscribe for dialog event to yoursefl?
