ajudando um cliente com um problema que eles estão tendo. Eu sou mais do tipo sysadmin / DBA, então estou lutando para ajudá-los. Eles estão dizendo que é um bug no kernel / ambiente, estou tentando provar ou refutar isso antes de insistir que está no código deles ou procurar suporte do fornecedor para o sistema operacional.

Acontece na Red Hat e no Oracle Enterprise Linux 5.7 (e 5.8), o aplicativo está escrito em C ++

O problema que eles estão enfrentando é que o thread principal inicia um thread separado para fazer um TCP connect () [cliente conectando ao servidor] potencialmente longo. Se o aspecto "longo prazo" demorar muito, eles cancelam o encadeamento e iniciam outro.

Isso é feito porque não sabemos o estado do programa do servidor:

programa do servidor instalado e funcionando -> conexão aceita imediatamenteo programa do servidor não está em execução, a máquina e a rede OK -> a conexão falhou imediatamente com o erro "conexão recusada"máquina ou rede travada ou inoperante -> conexão leva muito tempo para falhar com erro 'nenhuma rota para hospedar'

O problema é que o cancelamento do thread que tem o mutex bloqueado (com manipuladores de limpeza configurados para desbloquear o mutex) às vezes NÃO desbloqueia o mutex.

Isso deixa o thread principal travado tentando bloquear o mutex.

Informações detalhadas sobre o ambiente:

glibc-2.5-65glibc-2.5-65libcap-1.10-26kernel-debug-2.6.18-274.el5glibc-headers-2.5-65glibc-common-2.5-65libcap-1.10-26kernel-doc-2.6.18-274.el5kernel-2.6.18-274.el5kernel-headers-2.6.18-274.el5glibc-devel-2.5-65

Código foi criado com: c ++ -g3 tst2.C -lpthread -o tst2

Qualquer conselho e orientação é muito apreciado