Package: asterisk Version: 1:1.2.13~dfsg-2etch2 Severity: wishlist Tags: patch
In some occasions ast_mutex_lock(&chan->lock) is used where chan could already have been freed. This is of course not thread-safe. In this case the only thread-safe way to atomically check for and lock a channel would be to use channel_find_locked(). However this method has three disadvantages in the described context: - It is somewhat slow because it needs to do string comparison. - You need some other information (besides the channel pointer) by which to search. - By trying to lock 10 times the semantics of channel_find_lock is something like a compromise between lock and trylock. (This is not what you want because if you can't lock chan->lock you will probably want to release locks on mutexes outside of channel_find_locked(), too before you try again.) See patch for suggested solution. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22.7 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages asterisk depends on: ii adduser 3.102 Add and remove users and groups ii asterisk-bristuff 1:1.2.13~dfsg-2etch2 Open Source Private Branch Exchang asterisk recommends no packages. -- no debconf information
ast_channel_trylock_safe.dpatch
Description: application/shellscript
