Compartilhar via

Problemas e limitações conhecidos do AddressSanitizer

Observação

Envie seus comentários sobre o que gostaria de ver em versões futuras, e relate bugs se você encontrar problemas.

Opções e funcionalidades incompatíveis

As opções e funcionalidades a seguir são incompatíveis /fsanitize=address e devem ser desabilitadas ou evitadas.

Suporte à biblioteca padrão

A biblioteca padrão (STL) do Microsoft Visual C++ (MSVC) faz uso parcial do AddressSanitizer e fornece outras verificações de segurança de código. Para obter mais informações, consulte container-overflow o erro.

Quando as anotações são desabilitadas ou em versões da Biblioteca Standard que não dão suporte a elas, as exceções do AddressSanitizer geradas no código STL ainda identificam bugs reais. No entanto, elas serão mais precisas se as anotações estiverem habilitadas e você usar uma versão da Biblioteca Padrão que dê suporte a elas.

Este exemplo demonstra a falta de precisão e os benefícios de habilitar anotações:

// Compile with: cl /fsanitize=address /Zi
#include <vector>

int main()
{   
    // Create a vector of size 10, but with a capacity of 20.    
    std::vector<int> v(10);
    v.reserve(20);

    // In versions prior to 17.2, MSVC ASan does NOT raise an exception here.
    // While this is an out-of-bounds write to 'v', MSVC ASan
    // ensures the write is within the heap allocation size (20).
    // With 17.2 and later, MSVC ASan will raise a 'container-overflow' exception:
    // ==18364==ERROR: AddressSanitizer: container-overflow on address 0x1263cb8a0048 at pc 0x7ff6466411ab bp 0x005cf81ef7b0 sp 0x005cf81ef7b8
    v[10] = 1;

    // Regardless of version, MSVC ASan DOES raise an exception here, as this write
    // is out of bounds from the heap allocation.
    v[20] = 1;
}

Substituição operator new e delete

AddressSanitizer (ASan) usa uma versão personalizada de e operator new para encontrar erros de operator delete alocação como alloc_dealloc_mismatch. Execute o vinculador para /INFERASANLIBS garantir que a substituição do new/deleteASan tenha precedência inferior, de modo que o vinculador escolha ou operator new substitua em outras operator delete bibliotecas em relação às versões personalizadas do ASan. Quando isso acontece, o ASan pode não detectar alguns erros que dependem de seu personalizado operator new e operator delete.

O MFC inclui substituições personalizadas para operator new e operator delete. Quando as substituições do Microsoft Foundation Classes (MFC) são usadas em vez do ASan fornecido operator new e operator delete, o ASan pode perder erros inteiramente ou classificá-los incorretamente como resultado. Os seguintes erros podem ser perdidos ou classificados incorretamente:

Uso de memória

O runtime do AddressSanitizer não libera a memória de volta para o sistema operacional durante a execução para que a memória não seja alocada antecipadamente. Do ponto de vista do sistema operacional, pode parecer que há um vazamento de memória.

Locais de DLL de runtime do AddressSanitizer

Os arquivos de runtime clang_rt.asan*.dll são instalados ao lado dos compiladores em %VSINSTALLDIR%\VC\Tools\MSVC\<version>\bin\<host-arch>\<target-arch>\. Esses locais estão no caminho em sessões de depuração e em prompts de comando do desenvolvedor do Visual Studio. Esses arquivos nunca são colocados em C:\Windows\System32 ou C:\Windows\SysWOW64.

Suporte à folha de propriedades personalizada

A janela do Gerenciador de Propriedades do Visual Studio permite que você adicione arquivos personalizados .props aos seus projetos. Mesmo que a propriedade Enable AddressSanitizer (<EnableASAN>) seja mostrada, o build não a respeita. O build não o respeita porque os arquivos personalizados .props são incluídos depois Microsoft.cpp.props, o que usa o <EnableASAN> valor para definir outras propriedades.

Como solução alternativa, crie um Directory.Build.props arquivo na raiz do projeto para definir a <EnableASAN> propriedade. Para obter mais informações, consulte Personalizar builds do C++.

Variáveis locais de thread

As variáveis locais de thread (variáveis globais declaradas com __declspec(thread) ou thread_local) não são protegidas pelo AddressSanitizer. Essa limitação não é específica do Windows ou do Microsoft Visual C++, mas é uma limitação geral.

O código personalizado ignora a sequência de retorno de função normal

Não há suporte para o uso de código personalizado ou linguagem de assembly para deixar o quadro de pilha atual sem respeitar os mecanismos de retorno habituais. Por exemplo, deixar o quadro de pilha atual por meio de um salto em distância pode gerar falsos positivos.

Em vez disso, antes de invocar código personalizado semelhante a salto longo, chame __asan_handle_no_return() . Essa função limpa todos os bytes de sombra associados à pilha do thread atual, o que resulta em alguma cobertura perdida e introduz o risco de falsos negativos. Mas seu programa pode descontrair a pilha com segurança sem encontrar falsos positivos devido a bytes de sombra de pilha obsoletos.

Problemas com executáveis parcialmente higienizados

Se todo o código em um processo não for compilado, /fsanitize=addresso ASan poderá não ser capaz de diagnosticar todos os erros de segurança de memória. O exemplo mais comum é quando uma DLL compilada com o ASan é carregada em um processo que contém código não compilado com o ASan. Nesse caso, o ASan tenta categorizar as alocações que ocorreram antes da inicialização do ASan. Depois que essas alocações são realocadas, o ASan tenta possuir e monitorar o tempo de vida da memória.

Se todas as DLLs compiladas com a ASan forem descarregadas do processo antes do término do processo, poderá haver falhas devido a referências pendentes a funções interceptadas, como memcmp, memcpye memmoveassim por diante. Para obter os melhores resultados, compile todos os módulos em teste com /fsanitize=addressou não descarregue módulos compilados com o ASan depois que eles entrarem no processo.

Relate todos os bugs à nossa Comunidade de Desenvolvedores.

Exceções de primeira chance de 64 bits do ASan

No x64, a região de bytes de sombra do MSVC ASan ocupa vários terabytes de espaço de endereço virtual. O ASan não confirma previamente essa memória. Em vez disso, ele usa paginação sob demanda. Quando uma página de sombra é acessada pela primeira vez, ocorre uma exceção de falha de página de primeira chance e é tratada pelo ASan, que confirma a página.

O depurador do Visual Studio lida com isso normalmente e não mostra esses rastreamentos. No entanto, depuradores como o WinDbgX podem quebrar em todas as exceções por padrão. É recomendável desabilitar a quebra em exceções de primeira chance. Por exemplo, no WinDbgX, isso corresponde ao sxd av comando.

Confira também

Visão geral do AddressSanitizer
Referência de linguagem e build do AddressSanitizer
Referência de runtime do AddressSanitizer
Bytes de sombra de AddressSanitizer
Nuvem do AddressSanitizer ou teste distribuído
Integração do depurador do AddressSanitizer
Exemplos de erro do AddressSanitizer

  • Last updated on