THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#424 - zombie dialogs in state 5
User who did this - Daniel-Constantin Mierla (miconda)
----------
You didn't provide all messages for processing that request. You can see that it stays to ref 1, then tm detects retransmission (you provided logs up to here), then is the message cleanup from core, including execution of post-script callbacks which cleans the dialog.
Can you provide the logs up the messages related to destroying avps for bye request (they are the last printed for a request after config execution in this case -- I haven't provided them in the above logs, but they are printed).
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=424#comment1634
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#424 - zombie dialogs in state 5
User who did this - Ovidiu Sas (osas)
----------
Yes, it does remain stuck. My logs are different then yours and you can see that at the end there still one reference left.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=424#comment1633
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#424 - zombie dialogs in state 5
User who did this - Daniel-Constantin Mierla (miconda)
----------
I got the time to test it a bit and the dialog is cleaned up in such situation:
<code>
4(28491) INFO: <script>: ============== [2] exiting event_route[dialog:end]
4(28491) DEBUG: dialog [dlg_hash.c:872]: dlg_unref(): unref dlg 0x109d7e240 with 1 -> 3
4(28491) DEBUG: dialog [dlg_hash.c:854]: dlg_ref(): ref dlg 0x109d7e240 with 1 -> 4
4(28491) DEBUG: dialog [dlg_handlers.c:1285]: dlg_onroute(): BYE successfully processed
4(28491) DEBUG: dialog [dlg_hash.c:872]: dlg_unref(): unref dlg 0x109d7e240 with 2 -> 2
4(28491) DEBUG: dialog [dlg_hash.c:872]: dlg_unref(): unref dlg 0x109d7e240 with 1 -> 1
4(28491) DEBUG: dialog [dlg_hash.c:711]: internal_get_dlg(): ref dlg 0x109d7e240 with 1 -> 2
4(28491) DEBUG: dialog [dlg_hash.c:714]: internal_get_dlg(): dialog callid='2pHz2yNmDfEylHpQxnRUJDPBQBKvPtWZ' found
on entry 758, dir=1
4(28491) DEBUG: dialog [dlg_profile.c:511]: set_current_dialog(): setting current dialog [758:7585]
4(28491) DEBUG: dialog [dlg_hash.c:1066]: next_state_dlg(): dialog 0x109d7e240 changed from state 5 to state 5, due event 7 (ref 2)
4(28491) DEBUG: dialog [dlg_hash.c:872]: dlg_unref(): unref dlg 0x109d7e240 with 1 -> 1
4(28491) DEBUG: tm [t_lookup.c:1373]: t_newtran(): DEBUG: t_newtran: msg id=2 , global msg id=1 , T on entrance=0xffffffffffffffff
4(28491) DEBUG: tm [t_lookup.c:527]: t_lookup_request(): t_lookup_request: start searching: hash=22509, isACK=0
4(28491) DEBUG: tm [t_lookup.c:470]: matching_3261(): DEBUG: RFC3261 transaction matched, tid=PjGad24LDN.vST7cXbP-hVJYEhNXB0agt.
4(28491) DEBUG: tm [t_lookup.c:726]: t_lookup_request(): DEBUG: t_lookup_request: transaction found (T=0x109d82308)
4(28491) DEBUG: tm [t_reply.c:1623]: t_retransmit_reply(): DEBUG: reply retransmitted. buf=0x1095403d0: SIP/2.0 2..., shmem=0x109d84cf8: SIP/2.0 2
4(28491) DEBUG: dialog [dlg_hash.c:654]: dlg_lookup(): ref dlg 0x109d7e240 with 1 -> 2
4(28491) DEBUG: dialog [dlg_hash.c:656]: dlg_lookup(): dialog id=7585 found on entry 758
4(28491) DEBUG: dialog [dlg_var.c:58]: dlg_cfg_cb(): dialog with no expected trasaction after config execution
4(28491) DEBUG: dialog [dlg_hash.c:872]: dlg_unref(): unref dlg 0x109d7e240 with 1 -> 1
4(28491) DEBUG: dialog [dlg_hash.c:872]: dlg_unref(): unref dlg 0x109d7e240 with 1 -> 0
4(28491) DEBUG: dialog [dlg_hash.c:872]: dlg_unref(): ref <=0 for dialog 0x109d7e240
4(28491) DEBUG: dialog [dlg_hash.c:355]: destroy_dlg(): destroying dialog 0x109d7e240 (ref 0)
4(28491) DEBUG: dialog [dlg_hash.c:371]: destroy_dlg(): removed timer for dlg 0x109d7e240 [758:7585] with clid '2pHz2yNmDfEylHpQxnRUJDPBQBKvPtWZ' and tags 'lEyM6a2sWu4eUMznDJpgwew7Bs6h3h4A' '6f853e802780e732afe74b37489b8ba1.6e9a'
</code>
Can you check with kamctl if dialog still exists?
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=424#comment1632
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#424 - zombie dialogs in state 5
User who did this - Daniel-Constantin Mierla (miconda)
----------
It is impossible to ensure that dlg callbacks can be executed if added after the transaction was created. Think about the case when it takes more than a second to execute your event route, once it is finished, the transaction created by the other BYE could be in 'wait-for-delete' state, with the reply already sent out.
What I tried to do with the patch -- if the request is not creating a transaction by itself, then unref not to get dialog in zombie state. But apparently there is a 'bug' to the patch. This mechanism is used also for initial INVITE that is stateless replied from config, after a dlg_manage() - that situation created zombies in the past as well.
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=424#comment1631
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#424 - zombie dialogs in state 5
User who did this - Daniel-Constantin Mierla (miconda)
----------
The tm does the job of catching the 'retransmission'. As written in previous commits, it's hard to detect what is the retransmission and by config, all requests should get same processing with the other modules until tm discards one the same requests.
The problem is dlg specific, as it skips some internal processing if there is no change in dlg state.
Maybe you can give more specific example where an eventual fix in tm will benefit to other modules.
Were you testing with master branch? If not, what version and patches on top?
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=424#comment1629
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.