Rastreamento de corrupção de memória em um servidor linux produção

Question

Caras, você poderia por favor recomendar uma ferramenta para detectar uma corrupção de memória em um servidor de vários segmentos de produção construída com c ++ e trabalhando no Linux x86_64? Atualmente estou enfrentando o seguinte problema:. A cada várias horas meu servidor falhas com um segfault e os shows núcleo despejo que o erro acontece em malloc / calloc que é definitivamente um sinal de memória estar em algum lugar corrompido

Na verdade, eu já tentei algumas ferramentas sem muita sorte. Aqui é a minha experiência até agora:

• Valgrind é uma grande (eu diria mesmo melhor) ferramenta, mas retarda o servidor muito tornando-se inutilizável na produção. Eu tentei-o em um servidor de estágio e realmente me ajudou a encontrar alguns problemas de memória relacionados, mas mesmo depois de corrigi-los ainda fico acidentes no servidor de produção. Corri meu servidor palco sob Valgrind por várias horas, mas ainda não conseguiu detectar quaisquer erros graves.

• ElectricFence é dito ser um devorador de memória real, mas eu não poderia mesmo fazê-lo funcionar corretamente. Ele segfaults quase imediatamente no servidor de estágio em lugares estranhos aleatórios onde Valgrind não apresentem quaisquer problemas. Talvez ElectricFence não suporta enfiar bem? .. Eu não tenho idéia.

• DUMA - mesma história que ElectricFence mas ainda pior. Enquanto EF produzido descarregar um core com Backtraces legíveis mostra DUMA me apenas "?????" (e sim servidor é construído com bandeira -g com certeza)

• Dmalloc - Eu configurei o servidor para usá-lo em vez de rotinas malloc padrão no entanto ele trava após alguns minutos. Colocar uma gdb para o processo revela que de algum lugar pendurado em Dmalloc: (

Estou gradualmente ficando louco e simplesmente não sabe o que fazer a seguir. Eu tenho as seguintes ferramentas para ser julgado:? Mtrace, mpatrol mas talvez alguém tem uma idéia melhor

Eu apreciaria muito qualquer ajuda sobre esta questão.

Update: Eu consegui encontrar a fonte do erro. No entanto eu achei no servidor de estágio não produção de um usando Helgrind / DRD / tsan - houve uma datarace entre vários tópicos que resultaram em corrupção de memória. A chave era usar supressões valgrind adequadas uma vez que estas ferramentas mostrou muitos falsos positivos. Ainda assim, eu realmente não sei como isso pode ser descoberto no servidor de produção sem lentidão significativa ...

Answer 1

Gente, eu consegui encontrar a fonte do erro. No entanto eu achei no servidor palco usando Helgrind / DRD / tsan - houve uma datarace entre vários tópicos que resultaram em corrupção de memória. A chave era usar apropriadas valgrind supressões desde estas ferramentas mostrou muitos falsos positivos. Ainda assim, eu realmente não sei como isso pode ser descoberto no servidor de produção sem lentidão significativa ...

Answer 2

Sim, problemas de corrupção de memória C / C ++ são difíceis. Eu também usei várias vezes valgrind, às vezes ele revelou o problema e às vezes não.

Ao examinar saída valgrind não tendem a ignorar o seu resultado muito rápido. Às vezes, depois de um tempo considerável gasto, você verá que valgrind lhe deu a pista no primeiro lugar, mas você ignorou.

Outro conselho é comparar as alterações de código de versão estável previamente conhecida. Não é um problema se você usar algum tipo de sistema de fonte controle de versão (por exemplo, svn). Examinar todas as funções de memória relacionada (por exemplo memcpy, memset, sprintf, novo, Apagar / Apagar []).

Answer 3

Compilar seu programa com gcc 4.1 eo -fstack-protector-all switch. Se a corrupção de memória é causada por Stack Smashing este deve ser capaz de detectá-lo. Você pode precisar de jogar com alguns dos parâmetros adicionais de SSP.

Answer 4

Você já tentou -fmudflap ? (Role-se algumas linhas para ver as opções disponíveis).

Answer 5

Você pode tentar IBM purificar, mas eu tenho medo que não é opensource ..

Answer 6

Os Google perftools --- que é Open Source --- pode ser de ajuda, consulte o pilha verificador documentação.

Answer 7

Tente esta: http://www.hexco.de/rmdebug/ Usei-o extensivamente, a sua tem um baixo impacto no desempenho (na maior parte impactos quantidade de RAM), mas o algoritmo de alocação é a mesma. Sua bastante sempre comprovada para encontrar quaisquer erros de alocação. Seu programa irá falhar assim que ocorre o erro, e terá um registro detalhado.

Answer 8

Eu não tenho certeza se ele teria pego o bug particular, mas a variável de ambiente MALLOC_CHECK_ ( malloc homem página ) Liga a verificação adicional na implementação malloc Linux padrão e, normalmente, não tem um custo de tempo de execução significativo.