Problemas conhecidos e limitações do AddressSanitizer

Opções e funcionalidades incompatíveis

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

• As opções de /RTC são incompatíveis com o AddressSanitizer e devem ser desativadas.
• de vinculação incremental não é suportada e deve ser desabilitada.
• Editar e Continuar não é suportado e deve ser desativado.
• Co-rotinas são incompatíveis com o AddressSanitizer, e as funções retomáveis estão isentas de instrumentação.
• OpenMP não é suportado e deve ser desativado.
• C++ Gerenciado não é suportado e deve ser desabilitado.
• AMP C++ não é suportado e deve ser desativado.
• aplicativos da Plataforma Universal do Windows(UWP) não são suportados.
• Lista de casos especiais arquivos não são suportados.
• Cabeçalhos pré-compilados construídos sem /fsanitize=address não são suportados.

Suporte de 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 erro.

Quando as anotações são desativadas ou em versões da Biblioteca Padrão que não as suportam, as exceções do AddressSanitizer geradas no código STL ainda identificam bugs reais. No entanto, eles são mais precisos se as anotações estiverem habilitadas e você usar uma versão da Biblioteca Padrão que ofereça 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;
}

Sobreposição operator new e delete

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

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 completamente ou classificá-los incorretamente como resultado. Os seguintes erros podem ser perdidos ou classificados incorretamente:

• alloc_dealloc_mismatch
• double-free
• heap-use-after-free
• heap-buffer-overflow
• new-delete-type-mismatch

Utilização da memória

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

Locais de DLL de tempo de execução do AddressSanitizer

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

Suporte a folhas de propriedades personalizadas

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

Como solução alternativa, crie um Directory.Build.props arquivo na raiz do seu projeto para definir a <EnableASAN> propriedade. Para obter mais informações, consulte Personalizar compilações 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 assembly para deixar o quadro de pilha atual sem respeitar os mecanismos de retorno usuais. Por exemplo, deixar o quadro da pilha atual através de um salto em distância pode gerar falsos positivos.

Em vez disso, antes de invocar um código personalizado semelhante a um salto em distância, chame __asan_handle_no_return() . Esta 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 então desenrolar com segurança a pilha sem encontrar falsos positivos devido a bytes de sombra de pilha obsoletos.

Problemas com executáveis parcialmente limpos

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

Se todas as DLLs compiladas com ASan são descarregadas do processo antes que o processo termine, pode haver falhas devido a referências pendentes para funções intercetadas, como memcmp, memcpy, memmovee assim por diante. Para obter os melhores resultados, compile todos os módulos em teste com /fsanitize=addresso , ou não descarregue os módulos compilados com ASan depois que eles entrarem no processo.

Por favor, reporte quaisquer bugs à nossa Comunidade de Programadores.

Exceções ASan de primeira oportunidade de 64 bits

No x64, a região de bytes sombra do MSVC ASan ocupa vários terabytes de espaço de endereçamento virtual. ASan não faz pre-commit desta memória. Em vez disso, utiliza paginação sob demanda. Quando uma página sombra é acedida pela primeira vez, ocorre uma exceção de falha de primeira oportunidade e é tratada pelo ASan, que faz commit da página.

O depurador do Visual Studio gere isto de forma elegante e não mostra estes rastos. No entanto, depuradores como o WinDbgX podem falhar em todas as exceções por defeito. É recomendado desativar a quebra nas exceções de primeira oportunidade. Por exemplo, no WinDbgX, isto corresponde ao sxd av comando.

Ver também

Visão geral do AddressSanitizer
de compilação e referência de linguagem AddressSanitizer
de referência de tempo de execução AddressSanitizer
Bytes sombra do AddressSanitizer
AddressSanitizer na nuvem ou de testes distribuídos
de integração do depurador AddressSanitizer
Exemplos de erro AddressSanitizer