você pode iniciar e parar boundschecker (DevPartner)?

Question

Eu estou tentando usar boundschecker para analisar um programa bastante complexo. Executar o programa com boundschecker é quase demasiado lento para que possa ser de alguma utilidade, uma vez que me leva quase um dia para executar o programa até o ponto no código onde eu suspeito que o problema existe. Alguém pode me dar algumas idéias de como inspecionar apenas certas partes do meu software utilizando boundschecker (DevPartner) no Visual Studio 2005?

Agradecemos antecipadamente por sua ajuda!

Answer 1

I última usado BoundsChecker há alguns anos, e teve os mesmos problemas. Com grandes projetos, faz tudo correr tão lentamente que é inútil. Acabamos trocando-lo.

Mas, ainda precisava de um pouco de sua funcionalidade, mas como você, não para todo o programa. Então tivemos que fazê-lo nós mesmos.

No nosso caso, foi utilizado principalmente para tentar rastrear vazamentos de memória. Se esse é o seu objetivo, bem como, há outras opções.

1. Visual Studio faz um bom trabalho de contar-lhe sobre vazamentos de memória quando da saída do programa
2. Ele relata vazamentos na ordem em que eles foram criados
3. Vai dizer-lhe exatamente onde a memória vazada foi criado se os arquivos de origem têm isso no topo

#ifdef _DEBUG
#undef THIS_FILE
static char THIS_FILE[]=__FILE__;
#define new DEBUG_NEW
#endif

Aqueles ajuda muito, mas muitas vezes não é suficiente. Acrescentando que trecho em todos os lugares nem sempre é viável. Se você usar classes de fábrica, sabendo onde a memória foi alocada não ajuda em tudo. Então, quando tudo mais falhar, aproveitamos # 2.

Adicionar algo como o seguinte:

#define LEAK(str) {char *s = (char*)malloc(100); strcpy(s, str);}

Então, pimenta seu código com "VAZAMENTO (" leak1 ");" como queiras. Execute o programa e sair dele. Suas novas cordas vazaram será exibido no despejo de vazamento do Visual Studio circundante os vazamentos existentes. Continue adicionando / mover suas declarações de vazamento e re-executar o programa para restringir a pesquisa até que você já identificou o local exato. Em seguida, corrigir o vazamento, remover seus vazamentos de depuração, e está tudo pronto!

Answer 2

BoundsChecker rastreia todas as alocações de memória e liberado no detalhe extremo. Ele sabe, por exemplo, que tal e tal alocação de memória foi feito a partir do heap tempo de execução C, que por sua vez foi tirado de uma pilha Win32, que por sua vez começou a vida como memória alocada por VirtualAlloc. Se o aplicativo foi instrumentado (FinalCheck), também tem informações detalhadas sobre qual ponteiros referência a memória.

Esta é uma razão (de muitos) porque a coisa é lenta.

Se BC foram para conectar a uma aplicação tardia, teria nenhum destes dados acumulados, e teria ou (1) cavar tudo isso de uma vez, ou (2) começar a adivinhar sobre as coisas. Nenhuma solução é muito prático.

Answer 3

Uma maneira de iluminar-se BoundsChecker é de excluir da instrumentação todos, mas os poucos módulos que você está interessado. Eu sei que isso não é grande porque se você soubesse onde o vazamento foi você não precisaria BoundsChecker. O que eu costumo recomendar é que você use o modo de verificação activo do BC primeiro com apenas Rastreamento de memória disponível. Você perca a API validações mas você pode sempre executar novamente que separadamente. Depois de executar o Active Verifique e você tem pistas sobre quais módulos tendem a ser problemático, só então você ativar a instrumentação para o módulo ou módulos de interesse e suas dependências. Sabemos Verificação final é irritantemente lento, mas como Mistiano afirma corretamente, com Verificação Final não só BC manter um gráfico de todos os blocos alocados, mas também todos os ponteiros e contextos para eles. É aí que reside a magia em como Verificação final pode pregar vazamentos e corrupções no ponto de ocorrência, não apenas no encerramento do aplicativo ou falha. Shameless plug: Eu trabalho na equipe DevPartner. Estamos lançando DPS 10,5 em 4 de Fevereiro de 2011, com suporte a aplicativos x64 em BC. Ao contrário do BC64 relativamente antiga e undersold para Itanium que só forneceu o Active Check, DPS 10.5 fornece grande Verifique se o suporte final para x64 aplicações, tanto para puro C ++ e para os módulos nativos em execução em processos .NET. Veja microfocus.com sob MF desenvolvedor para obter mais informações.