[asterisk-bugs] [Asterisk 0012140]: [patch] Attempted to delete nonexistent schedule entry

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12140 
====================================================================== 
Reported By:                slavon
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12140
Category:                   Channels/chan_sip/General
Reproducibility:            always
Severity:                   tweak
Priority:                   normal
Status:                     new
Asterisk Version:           SVN 
SVN Branch (only for SVN checkouts, not tarball releases):  trunk 
SVN Revision (number only!): 106010 
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             03-04-2008 23:32 CST
Last Modified:              03-05-2008 10:23 CST
====================================================================== 
Summary:                    [patch] Attempted to delete nonexistent schedule
entry
Description: 
In DEBUG messages i see many messages like this:
ast_sched_del: Attempted to delete nonexistent schedule entry 0!

i look to backtrace and see this:
http://bugs.digium.com/view.php?id=0  ast_sched_del (con=0xb7629a20, id=0) at
sched.c:291
http://bugs.digium.com/view.php?id=1  0xb6f970fd in __sip_reliable_xmit
(p=0x8216c08, seqno=102, resp=0,
    data=0xb6795c48 "INVITE sip:6624658 at 87.255.0.218 SIP/2.0\r\nVia:
SIP/2.0/UDP 87.255.9.250:5060;branch=z9hG4bK1abe39d1;rport\r\nMax-Forwards:
70\r\nFrom: \"4955021766\"
<sip:4955021766 at 87.255.9.250>;tag=as745a2efb\r\nTo: <sip:66"..., len=863,
fatal=1,
    sipmethod=5) at chan_sip.c:2824
http://bugs.digium.com/view.php?id=2  0xb6f9870d in send_request (p=0x8216c08,
req=0xb6795a24,
reliable=XMIT_CRITICAL, seqno=102) at chan_sip.c:3083
http://bugs.digium.com/view.php?id=3  0xb6fb158d in transmit_invite
(p=0x8216c08, sipmethod=5, sdp=1,
init=2) at chan_sip.c:8705
http://bugs.digium.com/view.php?id=4  0xb6f9d492 in sip_call (ast=0x821ad20,
dest=0xb6797a78 "6624658 at voip",
timeout=0) at chan_sip.c:4170
http://bugs.digium.com/view.php?id=5  0x0808e8b9 in ast_call (chan=0x821ad20,
addr=0xb6797a78
"6624658 at voip", timeout=0) at channel.c:3392
http://bugs.digium.com/view.php?id=6  0xb749869c in dial_exec_full
(chan=0x8215678, data=0xb6799eb8,
peerflags=0xb6797d3c, continue_exec=0x0) at app_dial.c:1533
http://bugs.digium.com/view.php?id=7  0xb749b18c in dial_exec (chan=0x8215678,
data=0xb6799eb8) at
app_dial.c:1964
http://bugs.digium.com/view.php?id=8  0x080ddac6 in pbx_exec (c=0x8215678,
app=0x81d2498, data=0xb6799eb8)
at pbx.c:728
http://bugs.digium.com/view.php?id=9  0x080e2dd2 in pbx_extension_helper
(c=0x8215678, con=0x0,
context=0x82157fc "zap-g1-in", exten=0x821584c "6624658",
    priority=1, label=0x0, callerid=0x8211f08 "4955021766",
action=E_SPAWN, found=0xb679c2fc, combined_find_spawn=1)
    at pbx.c:2699
http://bugs.digium.com/view.php?id=10 0x080e415a in ast_spawn_extension
(c=0x8215678, context=0x82157fc
"zap-g1-in", exten=0x821584c "6624658", priority=1,
    callerid=0x8211f08 "4955021766", found=0xb679c2fc,
combined_find_spawn=1) at pbx.c:3190
http://bugs.digium.com/view.php?id=11 0x080e486a in __ast_pbx_run (c=0x8215678)
at pbx.c:3289
http://bugs.digium.com/view.php?id=12 0x080e59f8 in pbx_thread (data=0x8215678)
at pbx.c:3551
http://bugs.digium.com/view.php?id=13 0x0812b002 in dummy_start (data=0x8212088)
at utils.c:870
http://bugs.digium.com/view.php?id=14 0xb7cd918b in start_thread () from
/lib/libpthread.so.0
http://bugs.digium.com/view.php?id=15 0xb7db476e in clone () from /lib/libc.so.6

then i look to code chan_sip.c:2824 and look this macros:
AST_SCHED_REPLACE_VARIABLE(pkt->retransid, sched, siptimer_a, retrans_pkt,
pkt, 1);

look up and see what pkt defined in this function, but pkt->retransid not
defined. 

Its bug?

Tested on last 1.4 SVN and TRUNK svn

Thanks
====================================================================== 

---------------------------------------------------------------------- 
 Corydon76 - 03-05-08 10:23  
---------------------------------------------------------------------- 
No, you only want to retry when deleting a schedule entry FAILS.  If
deleting SUCCEEDS, then the zero response code will cause the while to fail
out and the second if won't succeed.  The only time you want the warning
printed is when you cannot delete the schedule ID after 10 retries.  As
soon as the deletion succeeds, you do not want to proceed any further. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
03-05-08 10:23  Corydon76      Note Added: 0083449                          
======================================================================