boost :: weak_ptr <T> .lock () se bloquea con una falla de segmentación SIGSEGV

(EDITAR) Entorno:

plee@sos-build:/usr/local/include/boost$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 11.10
Release:        11.10
Codename:       oneiric

plee@sos-build:/usr/local/include/boost$ uname -a
Linux sos-build 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux
plee@sos-build:/usr/local/include/boost$

plee@sos-build:/usr/local/include/boost$ cat version.hpp
//  BOOST_LIB_VERSION must be defined to be the same as BOOST_VERSION
#define BOOST_LIB_VERSION "1_47"

He estado trabajando en un proyecto del lado del servidor. Yo uso las bibliotecas de impulso, comoboost::asio, boost::shared_ptr yboost::weak_ptr.

La documentación de Boost http: //www.boost.org/doc/libs/1_47_0/libs/smart_ptr/weak_ptr.htm#loc) dice que laweak_ptr<T>.lock nunca tira:

bloquea

shared_ptr lock () const; Devoluciones: expirado ()? shared_ptr (): shared_ptr (* this).

Throws: nada.

Sin embargo, en mi aplicación, incluso se bloqueó:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffeffff700 (LWP 5102)]
0x000000000066fe08 in boost::detail::atomic_conditional_increment (pw=0x800000000007)
    at /usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:92
92      );
(gdb) 
(gdb) bt
#0  0x000000000066fe08 in boost::detail::atomic_conditional_increment (pw=0x800000000007)
    at /usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:92
#1  0x000000000066fe5c in boost::detail::sp_counted_base::add_ref_lock (this=0x7fffffffffff)
    at /usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:138
#2  0x000000000068009b in boost::detail::shared_count::shared_count (this=0x7fffefffe658, r=...)
    at /usr/local/include/boost/smart_ptr/detail/shared_count.hpp:518
#3  0x0000000000691599 in boost::shared_ptr<RtmpConnection>::shared_ptr<RtmpConnection> (
    this=0x7fffefffe650, r=...) at /usr/local/include/boost/smart_ptr/shared_ptr.hpp:216
#4  0x000000000068db48 in boost::weak_ptr<RtmpConnection>::lock (this=0x7fffe0e87e68)
    at /usr/local/include/boost/smart_ptr/weak_ptr.hpp:157

Verifiqué la línea bloqueada en/usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp

 69 inline int atomic_conditional_increment( int * pw )
 70 {
 71     // int rv = *pw;
 72     // if( rv != 0 ) ++*pw;
 73     // return rv;
 74
 75     int rv, tmp;
 76
 77     __asm__
 78     (
 79         "movl %0, %%eax\n\t"
 80         "0:\n\t"
 81         "test %%eax, %%eax\n\t"
 82         "je 1f\n\t"
 83         "movl %%eax, %2\n\t"
 84         "incl %2\n\t"
 85         "lock\n\t"
 86         "cmpxchgl %2, %0\n\t"
 87         "jne 0b\n\t"
 88         "1:":
 89         "=m"( *pw ), "=&a"( rv ), "=&r"( tmp ): // outputs (%0, %1, %2)
 90         "m"( *pw ): // input (%3)
 91         "cc" // clobbers
 92     );
 93
 94     return rv;
 95 }

La línea 92 es el código de ensamblaje. Realmente no sé lo que eso significa.

Siempre verifico si el @ devuelboost::weakptr<RtmpConnection>.lock() (tipo deboost::shared_ptr<RtmpConnection> está vacío antes de usarlo.

Así que busqué en Google, vi estohttp: //wiki.inkscape.org/wiki/index.php/Boost_shared_pointer

Los punteros débiles no se pueden desreferenciar por razones de seguridad de subprocesos. Si algún otro hilo destruye el objeto después de que verificó el puntero débil para que caduque pero antes de usarlo, obtendría un bloqueo

Entonces, ¿qué debo hacer para lidiar con eso? ¿Por qué se bloqueboost::weakptr<RtmpConnection>.lock() nunca debería bloquearse) Dado que mi programa es multiproceso. Es posible que después de obtener y verificar el valor devuelto deboost::weakptr<RtmpConnection>.lock(), elRtmpConnection podría ser destruido por otro hilo, ¿garantiza la Biblioteca Boost que no será destruido, porque el tipo de retorno esboost::shared_ptr<RtmpConnection>?

Respuestas a la pregunta(2)

Su respuesta a la pregunta