[asterisk-dev] Concurrency threading problem in chan_sip

[Nick Gorham]

Hi,

I am trying to track down a problem I am seeing with asterisk using 
memory after its been free'd, running with valgrind gives me these warnings

==11952== Invalid read of size 8
==11952==    at 0x1D893002: ??? (chan_sip.c:2336)
==11952==    by 0x4EA946: ast_sched_runq (sched.c:365)
==11952==    by 0x1D8DEBF2: ??? (chan_sip.c:17097)
==11952==    by 0x4FEB7D: dummy_start (utils.c:857)
==11952==    by 0x55BE2F6: start_thread (in /lib64/libpthread-2.5.so)
==11952==    by 0x7DE885C: clone (in /lib64/libc-2.5.so)
==11952==  Address 0xb115b60 is 24 bytes inside a block of size 854 free'd
==11952==    at 0x4C1E89E: free (vg_replace_malloc.c:323)
==11952==    by 0x1D894458: ??? (chan_sip.c:2576)
==11952==    by 0x1D89462D: ??? (chan_sip.c:2599)
==11952==    by 0x1D89C359: ??? (chan_sip.c:4207)
==11952==    by 0x44BBF3: ast_hangup (channel.c:1470)
==11952==    by 0xFAF165B: ??? (app_dial.c:687)
==11952==    by 0xFAF6A10: ??? (app_dial.c:1540)
==11952==    by 0xFAF90FE: ??? (app_dial.c:1904)
==11952==    by 0x4A8C54: pbx_exec (pbx.c:722)
==11952==    by 0x4AF214: pbx_extension_helper (pbx.c:2671)
==11952==    by 0x4B0E58: ast_spawn_extension (pbx.c:3162)
==11952==    by 0x4B1659: __ast_pbx_run (pbx.c:3261)
==11952== 


My reading of whats going on is that the scheduler can call

    static int retrans_pkt(const void *data)

And this can run as far as the

    /* Lock channel PVT */
    sip_pvt_lock(pkt->owner);

Then it sits there waiting for the lock to be released. The lock I 
suspect was put on this in

    static void __sip_ack(struct sip_pvt *p, int seqno, int resp, int 
sipmethod)

which runs its course, and eventually calls

    UNLINK(cur, p->packets, prev);
    dialog_unref(cur->owner);
    ast_free(cur);
    break;

The ast_free releases the memory, but its still referenced by the pkt in 
the thread in retransmit_pkt. Then it wakes up the locked thread by caling

    sip_pvt_unlock(p);

But now when the call in retransmit_pkt continues, the memory its using 
has actually been free'd by now, so it leads open the chance of 
corrupting the heap with the expected entertaining problems.

Hopefully there is enough to go on with the above, I am unsure just how 
to fix this (otherwise I would have tried)

-- 
Nick Gorham