[ NemesisRD 1.x ] futex en conectores ldap
2 views
Skip to first unread message
Eduardo Ramos Testillano
Apr 26, 2010, 10:56:20 AM4/26/10
to nemesi...@googlegroups.com
Hola,
Esto debe estar relacionado con el thread dedicado a los ticks, aunque mi proceso es st ¿?
sdpes01@titan-fed1: HTE_CLDAPDIR > strace -p 9062
Process 9062 attached - interrupt to quit
futex(0x3022231640, FUTEX_WAIT, 2, NULL
Lo he reproducido ya un par de veces bajo carga (actualmente estoy enviando unos 60 mensajes a la instancia cada segundo).
que puede colisionar con un proceso st en este sentido ?
-- Esto debe estar relacionado con el thread dedicado a los ticks, aunque mi proceso es st ¿?
sdpes01@titan-fed1: HTE_CLDAPDIR > strace -p 9062
Process 9062 attached - interrupt to quit
futex(0x3022231640, FUTEX_WAIT, 2, NULL
Lo he reproducido ya un par de veces bajo carga (actualmente estoy enviando unos 60 mensajes a la instancia cada segundo).
que puede colisionar con un proceso st en este sentido ?
--
Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.
Cisco
Apr 26, 2010, 12:24:10 PM4/26/10
to NemesisRD 1.x
Pasar un tiempo en el futex es muy normal para cualquier aplicación
que use thread's, como es tu caso.
Pero supongo que pasado "un tiempo" tu proceso saldrá y continuará
trabajando, no?
On Apr 26, 4:56 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
> Hola,
> Esto debe estar relacionado con el thread dedicado a los ticks, aunque mi proceso es st ¿?
> sdpes01@titan-fed1: HTE_CLDAPDIR > strace -p 9062
> Process 9062 attached - interrupt to quit
> futex(0x3022231640, FUTEX_WAIT, 2, NULL
> Lo he reproducido ya un par de veces bajo carga (actualmente estoy enviando unos 60 mensajes a la instancia cada segundo).
> que puede colisionar con un proceso st en este sentido ?--
>
>
>
> 8KViewDownload
que use thread's, como es tu caso.
Pero supongo que pasado "un tiempo" tu proceso saldrá y continuará
trabajando, no?
On Apr 26, 4:56 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:
> Hola,
> Esto debe estar relacionado con el thread dedicado a los ticks, aunque mi proceso es st ¿?
> sdpes01@titan-fed1: HTE_CLDAPDIR > strace -p 9062
> Process 9062 attached - interrupt to quit
> futex(0x3022231640, FUTEX_WAIT, 2, NULL
> Lo he reproducido ya un par de veces bajo carga (actualmente estoy enviando unos 60 mensajes a la instancia cada segundo).
> que puede colisionar con un proceso st en este sentido ?--
>
>
>
> --
> Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.
>
> image_jpeg_part
> Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google.
> Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com.
> Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com
> Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es.
>
> 8KViewDownload
Eduardo Ramos Testillano
Apr 27, 2010, 3:22:25 AM4/27/10
to nemesi...@googlegroups.com
Lo que vi en dos ocasiones es que se quedaba pillado en el futex. A los
pocos minutos el proceso desaparecía sin dejar core, trazas ni nada.
Tampoco registre un evento de terminacion anormal ni nada parecido. Incluso quitando la carga por completo permanecía en ese estado.
Estoy intentando reproducirlo de nuevo para hacerle un gdb y sacar informacion del bloqueo, en cuanto tenga algo te comento.
un saludo
Tampoco registre un evento de terminacion anormal ni nada parecido. Incluso quitando la carga por completo permanecía en ese estado.
Estoy intentando reproducirlo de nuevo para hacerle un gdb y sacar informacion del bloqueo, en cuanto tenga algo te comento.
un saludo
El 26/04/2010 18:24, Cisco escribió:
Pasar un tiempo en el futex es muy normal para cualquier aplicación que use thread's, como es tu caso. Pero supongo que pasado "un tiempo" tu proceso saldrá y continuará trabajando, no? On Apr 26, 4:56 pm, Eduardo Ramos Testillano <era...@tid.es> wrote:Hola, Esto debe estar relacionado con el thread dedicado a los ticks, aunque mi proceso es st ¿? sdpes01@titan-fed1: HTE_CLDAPDIR > strace -p 9062 Process 9062 attached - interrupt to quit futex(0x3022231640, FUTEX_WAIT, 2, NULL Lo he reproducido ya un par de veces bajo carga (actualmente estoy enviando unos 60 mensajes a la instancia cada segundo). que puede colisionar con un proceso st en este sentido ?-- -- Has recibido este mensaje porque estás suscrito al grupo "NemesisRD 1.x" de Grupos de Google. Para publicar una entrada en este grupo, envía un correo electrónico a nemesi...@googlegroups.com. Para anular tu suscripción a este grupo, envía un correo electrónico a nemesisrd-1x...@googlegroups.com Para tener acceso a más opciones, visita el grupo en http://groups.google.com/group/nemesisrd-1x?hl=es. image_jpeg_part 8KViewDownload
--
Eduardo Ramos Testillano
Apr 28, 2010, 11:51:32 AM4/28/10
to nemesi...@googlegroups.com
sdpes01@titan-fed1: HTE_CLDAPDIR > strace -p 7473
Process 7473 attached - interrupt to quit
futex(0x3022231640, FUTEX_WAIT, 2, NULL <unfinished ...>
Process 7473 detached
Esto es lo que he podido ver:
sdpes01@titan-fed1: HTE_CLDAPDIR >
sdpes01@titan-fed1: HTE_CLDAPDIR > gdb cldap_antes_de_ayer 7473
GNU gdb Red Hat Linux (6.3.0.0-1.153.el4rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db library "/lib64/tls/libthread_db.so.1".
Attaching to program: /ext/OCSTE2/Users/eramos/Celulas/HTE.titan-fed1.sdpes01/HTE_CLDAPDIR/cldap_antes_de_ayer, process 7473
Reading symbols from /usr/lib64/libz.so.1...done.
Loaded symbols for /usr/lib64/libz.so.1
Reading symbols from /lib64/libssl.so.4...done.
Loaded symbols for /lib64/libssl.so.4
Reading symbols from /export/oracle/app/oracle/product/10.2.0/lib/libclntsh.so.10.1...done.
Loaded symbols for /export/oracle/app/oracle/product/10.2.0/lib/libclntsh.so.10.1
Reading symbols from /export/oracle/app/oracle/product/10.2.0/lib/libnnz10.so...done.
Loaded symbols for /export/oracle/app/oracle/product/10.2.0/lib/libnnz10.so
Reading symbols from /lib64/libdl.so.2...done.
Loaded symbols for /lib64/libdl.so.2
Reading symbols from /lib64/tls/librt.so.1...done.
Loaded symbols for /lib64/tls/librt.so.1
Reading symbols from /usr/lib64/libstdc++.so.6...done.
Loaded symbols for /usr/lib64/libstdc++.so.6
Reading symbols from /lib64/tls/libm.so.6...done.
Loaded symbols for /lib64/tls/libm.so.6
Reading symbols from /lib64/libgcc_s.so.1...done.
Loaded symbols for /lib64/libgcc_s.so.1
Reading symbols from /lib64/tls/libc.so.6...done.
Loaded symbols for /lib64/tls/libc.so.6
Reading symbols from /usr/lib64/libgssapi_krb5.so.2...done.
Loaded symbols for /usr/lib64/libgssapi_krb5.so.2
Reading symbols from /lib64/libcrypto.so.4...done.
Loaded symbols for /lib64/libcrypto.so.4
Reading symbols from /lib64/tls/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 182919573568 (LWP 7473)]
[New Thread 1084229984 (LWP 7474)]
Loaded symbols for /lib64/tls/libpthread.so.0
Reading symbols from /usr/lib64/libkrb5.so.3...done.
Loaded symbols for /usr/lib64/libkrb5.so.3
Reading symbols from /lib64/libcom_err.so.2...done.
Loaded symbols for /lib64/libcom_err.so.2
Reading symbols from /usr/lib64/libk5crypto.so.3...done.
Loaded symbols for /usr/lib64/libk5crypto.so.3
Reading symbols from /lib64/libresolv.so.2...done.
Loaded symbols for /lib64/libresolv.so.2
Reading symbols from /lib64/libnsl.so.1...done.
Loaded symbols for /lib64/libnsl.so.1
Reading symbols from /lib64/ld-linux-x86-64.so.2...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/libnss_files.so.2...done.
Loaded symbols for /lib64/libnss_files.so.2
0x00000030220d2d1b in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6
(gdb) info thread
2 Thread 1084229984 (LWP 7474) 0x00000030220d2d1b in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6
1 Thread 182919573568 (LWP 7473) 0x00000030220d2d1b in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6
(gdb) thread 1
[Switching to thread 1 (Thread 182919573568 (LWP 7473))]#0 0x00000030220d2d1b in __lll_mutex_lock_wait ()
from /lib64/tls/libc.so.6
(gdb) where
#0 0x00000030220d2d1b in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6
#1 0x00000000018d9790 in ?? ()
#2 0x0000002a99e034dc in ?? ()
#3 0x000000302206dea3 in posix_memalign () from /lib64/tls/libc.so.6
#4 0x0000000000000090 in ?? ()
#5 0x0000007fbfffda70 in ?? ()
#6 0x0000000000000070 in ?? ()
#7 0x00000000004bb9f2 in std::_List_base<nemesis::dbos::StorageArea::Instance*, std::allocator<nemesis::dbos::StorageArea::Instance*> >::_M_put_node (this=0x90d178, __p=0x18d9790)
at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_list.h:315
#8 0x00000000004baf11 in std::list<nemesis::dbos::StorageArea::Instance*, std::allocator<nemesis::dbos::StorageArea::Instance*> >::_M_erase (this=0x90d178, __position={_M_node = 0x18d9790})
at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_list.h:1174
#9 0x00000000004bad9f in std::list<nemesis::dbos::StorageArea::Instance*, std::allocator<nemesis::dbos::StorageArea::Instance*> >::erase (this=0x90d178, __position={_M_node = 0x18d9790})
at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/list.tcc:98
#10 0x00000000004ba3df in nemesis::dbos::StorageArea::Holes::erase (this=0x90d178, instance=0x90d1d0)
at dbos.StorageArea.cc:1133
#11 0x00000000004b46aa in nemesis::dbos::StorageArea::instantiate (this=0x90d100, connection=0x90c670,
loader=@0x90d000) at dbos.StorageArea.cc:169
#12 0x00000000004a0c71 in nemesis::dbos::StorageArea::instantiate (this=0x90d100, connection=@0x90c670,
loader=@0x90d000)
at /home/comun/trabajo/plataforma/NemesisRD/cooking.pj/official.ss/libNemesis.dbos.b/hdrs/nemesis.dbos.StorageArea.h:205
#13 0x00000000004ad585 in nemesis::dbos::ObjectFacade<nemesis::sdp::odb::Service>::instantiate (
connection=@0x90c670, loader=@0x90d000)
at /home/comun/trabajo/plataforma/NemesisRD/cooking.pj/official.ss/libNemesis.dbos.b/hdrs/nemesis.dbos.ObjectFacade.h:188
#14 0x00000000004ad481 in nemesis::dbos::ObjectFacade<nemesis::sdp::odb::Service>::instanciate (
connection=@0x90c670, loader=@0x90d000)
at /home/comun/trabajo/plataforma/NemesisRD/cooking.pj/official.ss/libNemesis.dbos.b/hdrs/nemesis.dbos.ObjectFacade.h:121
#15 0x00000000004acb63 in nemesis::sdp::odb::Service::instanciate (key=12) at odb.db/odb.Service.cc:69
#16 0x000000000048c32c in nemesis::sdp::Application::asXML (this=0x7fbffff140, app=0x2a99e02cd0)
at sdp.Application.cc:572
#17 0x000000000041a2f7 in er::cldap::MyApplication::asXML (this=0x7fbffff140, parent=0x7fbfffdff0)
at cldap.MyApplication.cc:1082
#18 0x000000000051bd70 in nemesis::app::Application::writeContext (this=0x7fbffff140, file=@0x7fbfffe2e0)
at app.Application.cc:377
#19 0x000000000051c153 in nemesis::app::Application::signalUSR1 (this=0x7fbffff140) at app.Application.cc:414
#20 0x000000000051c26a in nemesis::app::Application::handlerSignalUSR1 () at app.Application.cc:432
#21 <signal handler called>
#22 0x0000003022068f0b in _int_free () from /lib64/tls/libc.so.6
#23 0x0000003022069586 in free () from /lib64/tls/libc.so.6
#24 0x00000000005efcba in ldap_free_request_int ()
#25 0x00000000005e78bf in ldap_ld_free ()
#26 0x000000000054cb7e in nemesis::ldap::Session::finalize (this=0x9be6d0) at ldap.Session.cc:310
#27 0x00000000004e7f39 in nemesis::comm::Communicator::detach (this=0x90efa0, handler=0x9be6d0)
at comm.Communicator.cc:457
#28 0x000000000054c7c5 in nemesis::ldap::Session::apply (this=0x9be6d0) at ldap.Session.cc:267
#29 0x00000000004e8619 in nemesis::comm::Communicator::singlethreadedAccept (this=0x90efa0)
at comm.Communicator.cc:568
---Type <return> to continue, or q <return> to quit---
#30 0x00000000004e8373 in nemesis::comm::Communicator::accept (this=0x90efa0) at comm.Communicator.cc:522
#31 0x0000000000419fd4 in er::cldap::MyApplication::run (this=0x7fbffff140) at cldap.MyApplication.cc:1059
#32 0x000000000051a443 in nemesis::app::Application::start (this=0x7fbffff140) at app.Application.cc:153
#33 0x000000000043fff6 in main (argc=28, argv=0x7fbffff448) at cldap.main.cc:26
(gdb) thread 2
[Switching to thread 2 (Thread 1084229984 (LWP 7474))]#0 0x00000030220d2d1b in __lll_mutex_lock_wait ()
from /lib64/tls/libc.so.6
(gdb) where
#0 0x00000030220d2d1b in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6
#1 0x00000000018d9790 in ?? ()
#2 0x0000002a99e0354c in ?? ()
#3 0x000000302206dea3 in posix_memalign () from /lib64/tls/libc.so.6
#4 0x0000000000000090 in ?? ()
#5 0x00000000409ffab0 in ?? ()
#6 0x0000000000000070 in ?? ()
#7 0x00000000004bb9f2 in std::_List_base<nemesis::dbos::StorageArea::Instance*, std::allocator<nemesis::dbos::StorageArea::Instance*> >::_M_put_node (this=0x90d178, __p=0x18d9790)
at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_list.h:315
#8 0x00000000004baf11 in std::list<nemesis::dbos::StorageArea::Instance*, std::allocator<nemesis::dbos::StorageArea::Instance*> >::_M_erase (this=0x90d178, __position={_M_node = 0x18d9790})
at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_list.h:1174
#9 0x00000000004bad9f in std::list<nemesis::dbos::StorageArea::Instance*, std::allocator<nemesis::dbos::StorageArea::Instance*> >::erase (this=0x90d178, __position={_M_node = 0x18d9790})
at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/list.tcc:98
#10 0x00000000004ba3df in nemesis::dbos::StorageArea::Holes::erase (this=0x90d178, instance=0x90d1d0)
at dbos.StorageArea.cc:1133
#11 0x00000000004b46aa in nemesis::dbos::StorageArea::instantiate (this=0x90d100, connection=0x90c670,
loader=@0x90d000) at dbos.StorageArea.cc:169
#12 0x00000000004a0c71 in nemesis::dbos::StorageArea::instantiate (this=0x90d100, connection=@0x90c670,
loader=@0x90d000)
at /home/comun/trabajo/plataforma/NemesisRD/cooking.pj/official.ss/libNemesis.dbos.b/hdrs/nemesis.dbos.StorageArea.h:205
#13 0x00000000004ad585 in nemesis::dbos::ObjectFacade<nemesis::sdp::odb::Service>::instantiate (
connection=@0x90c670, loader=@0x90d000)
at /home/comun/trabajo/plataforma/NemesisRD/cooking.pj/official.ss/libNemesis.dbos.b/hdrs/nemesis.dbos.ObjectFacade.h:188
#14 0x00000000004ad481 in nemesis::dbos::ObjectFacade<nemesis::sdp::odb::Service>::instanciate (
connection=@0x90c670, loader=@0x90d000)
at /home/comun/trabajo/plataforma/NemesisRD/cooking.pj/official.ss/libNemesis.dbos.b/hdrs/nemesis.dbos.ObjectFacade.h:121
#15 0x00000000004acb63 in nemesis::sdp::odb::Service::instanciate (key=12) at odb.db/odb.Service.cc:69
#16 0x000000000048b081 in nemesis::sdp::Application::getBaseDirectory (this=0x7fbffff140) at sdp.Application.cc:365
#17 0x0000000000413dce in er::cldap::MyApplication::writeContextExtension (this=0x7fbffff140,
extension=0x6b29c8 "context.MyApplication::eventAbnormalTermination") at cldap.MyApplication.cc:388
#18 0x000000000041401a in er::cldap::MyApplication::eventAbnormalTermination (this=0x7fbffff140,
className=0x6cb8fa "timex::TickProducer") at cldap.MyApplication.cc:403
#19 0x00000000004dd55b in nemesis::timex::TickProducer::tick (this=0x98f460)
at internal.db/timex.TickProducer.cc:93
#20 0x00000000004dd39b in nemesis::timex::TickProducer::exec (arg=0x98f460) at internal.db/timex.TickProducer.cc:60
#21 0x0000003022706137 in start_thread () from /lib64/tls/libpthread.so.0
#22 0x00000030220c7533 in clone () from /lib64/tls/libc.so.6
(gdb) q
Cisco
Apr 29, 2010, 1:55:00 AM4/29/10
to NemesisRD 1.x
Hola.
Hay dos problemas, primero que la aplicación no está siendo capaz de
tratar toda el tráfico que recibe, y llega un momento en que el
control de temporización llena el pipe y solicita la terminación de la
aplicación.
Y el otro problema es que quizás haya que simplificar el tratamiento
que se está realizando en el tratamiento de la señal. Si puedes
reproducir el problema de forma controlada se podría incluir algún
cambio para intentar solucionar el problema.
Un saludo.
> (gdb)thread 1
> (gdb)thread 2
>
> read more »
>
> image_jpeg_part
> 8KViewDownload
>
> firma.jpg
> 8KViewDownload
Hay dos problemas, primero que la aplicación no está siendo capaz de
tratar toda el tráfico que recibe, y llega un momento en que el
control de temporización llena el pipe y solicita la terminación de la
aplicación.
Y el otro problema es que quizás haya que simplificar el tratamiento
que se está realizando en el tratamiento de la señal. Si puedes
reproducir el problema de forma controlada se podría incluir algún
cambio para intentar solucionar el problema.
Un saludo.
> [Switching to thread 2 (Thread 1084229984 (LWP 7474))]#0 0x00000030220d2d1b in __lll_mutex_lock_wait ()
> from /lib64/tls/libc.so.6
> (gdb) where
> #0 0x00000030220d2d1b in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6
> #1 0x00000000018d9790 in ?? ()
> #2 0x0000002a99e0354c in ?? ()
> #3 0x000000302206dea3 in posix_memalign () from /lib64/tls/libc.so.6
> #4 0x0000000000000090 in ?? ()
> #5 0x00000000409ffab0 in ?? ()
> #6 0x0000000000000070 in ?? ()
> #7 0x00000000004bb9f2 in std::_List_base<nemesis::dbos::StorageArea::Instance*, std::allocator<nemesis::dbos::StorageArea::Instance*> >::_M_put_node (this=0x90d178, __p=0x18d9790)
> at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_list.h:315
> #8 0x00000000004baf11 in std::list<nemesis::dbos::StorageArea::Instance*, std::allocator<nemesis::dbos::StorageArea::Instance*> >::_M_erase (this=0x90d178, ...
> from /lib64/tls/libc.so.6
> (gdb) where
> #0 0x00000030220d2d1b in __lll_mutex_lock_wait () from /lib64/tls/libc.so.6
> #1 0x00000000018d9790 in ?? ()
> #2 0x0000002a99e0354c in ?? ()
> #3 0x000000302206dea3 in posix_memalign () from /lib64/tls/libc.so.6
> #4 0x0000000000000090 in ?? ()
> #5 0x00000000409ffab0 in ?? ()
> #6 0x0000000000000070 in ?? ()
> #7 0x00000000004bb9f2 in std::_List_base<nemesis::dbos::StorageArea::Instance*, std::allocator<nemesis::dbos::StorageArea::Instance*> >::_M_put_node (this=0x90d178, __p=0x18d9790)
> at /usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_list.h:315
>
> read more »
>
> image_jpeg_part
> 8KViewDownload
>
> firma.jpg
> 8KViewDownload
Reply all
Reply to author
Forward
0 new messages