Re: mISDN_send: error -12 strikes again

On Fri, Apr 13, 2012 at 01:30:55PM +0200, Ralf Schlatterbeck wrote:
> OK, I now see the following deadlock situation (the first lock for each
> thread is the lock obtained successfully, the second one is the blocking one)
> 
> thread               lockname   lock       file        function              line
> 0xb4cbfb70           c          0x88835b0  astobj2.c   internal_ao2_callback  657
> 0xb4cbfb70           chan       0xee93418  channel.c   ast_channel_cmp_cb    1691
> 
> Waiting for:                               channel.c   ast_call              5536
> 
> 
> 0xb3287b70           chan       0xee93418  channel.c   ast_call              5536
> 0xb3287b70           &chan_lock 0xb5c37c00 chan_lcr.c  lcr_call              2420
> 
> Waiting for:                               chan_lcr.c  lcr_request           2067
> 
> 
> 0xb4ac3b70           &chan_lock 0xb5c37c00 chan_lcr.c  lcr_request           2067
> 0xb4ac3b70           c          0x88835b0  astobj2.c   internal_ao2_link      493
> 
> Waiting for:                               astobj2.c   internal_ao2_callback  657
> 
> 
> lotsofthreads        channels   0x88835b0
> lotsofthreads        &chan_lock 0xb5c37c00
> 
> a classical three-way deadlock.

Yes this is the usually case with asterisk.

> If someone is interested I can provide the output of "core show locks".
> This contains the backtraces of all threads when obtaining the locks.
> I can think of two ways to fix this:
> - if lcr_call is always called with the chan lock held, we could
>   do deadlock avoidance, try to get the &chan_lock and if that fails
>   give up the chan lock for some time. But I don't think that's the
>   right way (looking into other channel drivers for comparison).
> - maybe in lcr_request we should give up the lock before calling into

Yes, if you call into asterisk you should not held any lock, this is a bad
idea.
...
> 
> Any ideas?
> 

In my work on a chan_misdnv2, I never call asterisks directely from
any mISDN thread, except when creating a new channel.
And from the asterisk callbacks I do not call into asterisk when I held a
private lock.
I did add a pipe file descriptor to the channel fd array and write events to it
The channel read function than does the handling, so I never need
to take a channel lock when holding other locks and the hierachy of the
locks is always the same.

Karsten