acompanhamento de solicitações de alocação de heap
Este tópico se aplica a:
Edição |
Visual Basic |
C# |
C++ |
Desenvolvedores Web |
---|---|---|---|---|
Express |
Somente nativo |
|||
Padrão |
Somente nativo |
|||
PRO e equipe |
Somente nativo |
Legenda de tabela:
Aplica-se |
|
Não é aplicada |
|
Comando ou comandos oculta por padrão. |
Embora indicar com precisão a fonte arquivo nome e do número da linha na qual um serir sistema autônomo ou relatar executa a macro geralmente é muito útil para localizar a causa do problema, o mesmo não é sistema autônomo provavelmente será verdade para funções de alocação de heap.Enquanto as macros podem ser inseridas em muitos pontos adequados na árvore de lógica do aplicativo, uma alocação geralmente é incluída em uma rotina especial que é chamada de muitos locais diferentes em vários momentos diferentes.A pergunta é geralmente não qual linha de código fazer uma alocação incorreta, mas em vez disso, qual deles de milhares de alocações feitas por essa linha de código foi incorreto e por quê.
Os números de solicitação de alocação exclusivo e _crtBreakAlloc
A maneira mais simples para identificar a telefonar de alocação de heap específicos que ficou incorreta é usufruir o número de solicitação de alocação exclusivo associado a cada bloco na pilha de depurar.Quando informações sobre um bloco for reportadas por uma das funções de despejo, esse número de solicitação de alocação é entre chaves (por exemplo, "{36}").
Se você souber o número de solicitação de alocação de um bloco alocado incorretamente, você pode passar esse número para _CrtSetBreakAlloc para criar um ponto de interrupção.Execução interromperá imediatamente antes de alocar o bloco e você pode voltar para determinar qual rotina era responsável pela telefonar inválida.Para evitar a recompilação, você pode chegar ao mesmo resultado no depurador definindo _crtBreakAlloc para o número de solicitação de alocação que você está interessado.
Criação de versões de depurar de suas rotinas de alocação
Uma abordagem um pouco mais complicada é criar versões de depurar de suas próprias rotinas de alocação, comparáveis da _dbg o versõesfunções de alocação de heap.Você pode, em seguida, passar arquivo de fonte e de linha por meio de argumentos de número para as rotinas de alocação de heap subjacente e imediatamente poderá ver onde uma alocação incorreta foi originada.
Por exemplo, suponha que seu aplicativo contém uma rotina usada com freqüência semelhante à seguinte:
int addNewRecord(struct RecStruct * prevRecord,
int recType, int recAccess)
{
// ...code omitted through actual allocation...
if ((newRec = malloc(recSize)) == NULL)
// ... rest of routine omitted too ...
}
Em um arquivo de cabeçalho, você poderia adicionar código sistema autônomo o seguinte:
#ifdef _DEBUG
#define addNewRecord(p, t, a) \
addNewRecord(p, t, a, __FILE__, __LINE__)
#endif
Em seguida, você poderia alterar a alocação em sua rotina de criação de registro da seguinte maneira:
int addNewRecord(struct RecStruct *prevRecord,
int recType, int recAccess
#ifdef _DEBUG
, const char *srcFile, int srcLine
#endif
)
{
/* ... code omitted through actual allocation ... */
if ((newRec = _malloc_dbg(recSize, _NORMAL_BLOCK,
srcFile, scrLine)) == NULL)
/* ... rest of routine omitted too ... */
}
Agora o fonte arquivo nome e o número de linha em que addNewRecord foi chamado serão armazenadas em cada bloco resultante alocado no heap de depurar e será relatado quando esse bloco é examinado.