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=detail&atid=1086410&aid=2948561&group_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? Is this it? Regards, Anca ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086410&aid=2948561&group_id=232389 _______________________________________________ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel