Violação de acesso na inicialização estática
Estou trabalhando em um aplicativo com o Visual Studio 2015 no Windows 7. O aplicativo possui um front end em C #, um wrapper em C ++ CLR e código nativo em C ++.
Meu aplicativo falha com uma violação de acesso ao inicializar uma variável estática no escopo da função com código nativo C ++. Mas apenas no Windows Server 2003 Enterprise SP2 e não no Windows 7 ou Windows Server 2012. Sei que o Windows Server 2003 está sem suporte, mas preciso segmentar essa plataforma por alguns meses adicionais e o Visual Studio 2015 fornece um conjunto de ferramentas da plataforma para segmentar isto.
Eu criei um pequeno exemplo reproduzível que você encontra no final.
A falha ocorre apenas nas três partes envolvidas (C #, C ++ CLR, C ++). Se eu remover alguma, a falha desapareceu.
A falha ocorre apenas com um construtor personalizado definido. Se eu remover o construtor, a falha desapareceu.
Não sou especialista em montagem, mas para mim parece que a falha é causada pelo código que verifica se a inicialização estática é necessária. O construtor nem é chamado.
Minha pergunta é: Por que ele falha no Windows Server 2003? Estou perdendo alguma configuração importante do projeto?
A mensagem de erroUnhandled exception at 0x1000167E (Native.dll) in Managed.exe.dmp: 0xC0000005: Access violation reading location 0x00000000.
// Target framework: .NET Framework 4
// Platform target: x86
using System;
namespace Managed
{
class Program
{
static void Main(string[] args)
{
Console.Write("Press enter to start test...");
Console.ReadLine();
Native.Wrapper wrapper = new Native.Wrapper();
Console.WriteLine("Test was successful");
Console.Write("Press enter to exit...");
Console.ReadLine();
}
}
}
#pragma once
namespace Native
{
public ref class Wrapper
{
public:
Wrapper();
}; // public ref class Wrapper
} // namespace Native
// Platform Toolset: Visual Studio 2015 - Windows XP (v140_xp)
// Common Language Runtime Support: Common Language Runtime Support (/clr)
// .NET Target Framework Version: v4.0
// Warning Level: Level4
// Treat Warnings As Errors: Yes (/WX)
// Precompiled Header: Not Using Precompiled Headers
// SubSystem: Console (/SUBSYSTEM:CONSOLE)
// Optimization: Disabled (/Od)
#pragma once
#include "Wrapper.hpp"
#include "Caller.hpp"
namespace Native
{
Wrapper::Wrapper()
{
Caller* caller = new Caller();
delete caller;
}
} // namespace Native
#pragma once
namespace Native
{
class Caller
{
public:
Caller();
}; // class Caller
} // namespace Native
// Platform Toolset: Visual Studio 2015 - Windows XP (v140_xp)
// Common Language Runtime Support: No Common Language RunTime Support
// Warning Level: Level4
// Treat Warnings As Errors: Yes (/WX)
// Precompiled Header: Not Using Precompiled Headers
// SubSystem: Console (/SUBSYSTEM:CONSOLE)
// Optimization: Disabled (/Od)
#include "Caller.hpp"
#include "Singleton.hpp"
namespace Native
{
Caller::Caller()
{
Singleton::GetInstance()->DoSomething();
}
} // namespace Native
#pragma once
#include <iostream>
namespace Native
{
class Singleton
{
public:
Singleton() // !!! remove constructor to prevent crash !!!
{ }
static Singleton* GetInstance()
{
static Singleton Instance; // !!! crashes here !!!
return &Instance;
}
void DoSomething()
{
std::wcout << L"Doing something...\n";
}
}; // class Singleton
} // namespace Native
static Singleton* GetInstance()
{
10001650 push ebp
10001651 mov ebp,esp
10001653 push 0FFFFFFFFh
10001655 push 10006A8Ch
1000165A mov eax,dword ptr fs:[00000000h]
10001660 push eax
10001661 mov eax,dword ptr ds:[1001B334h]
10001666 xor eax,ebp
10001668 push eax
10001669 lea eax,[ebp-0Ch]
1000166C mov dword ptr fs:[00000000h],eax
static Singleton Instance;
10001672 mov eax,dword ptr ds:[1001B5D0h]
10001677 mov ecx,dword ptr fs:[2Ch]
1000167E mov edx,dword ptr [ecx+eax*4] // !!! access violation here !!!
10001681 mov eax,dword ptr ds:[1001B5A4h]
10001686 cmp eax,dword ptr [edx+4]
1000168C jle Native::Singleton::GetInstance+79h (100016C9h)
EAX = 00000000 EBX = 00000000 ECX = 00000000 EDX = 006A0003 ESI = 001647C8
EDI = 0012F3BC EIP = 1000167E ESP = 0012F394 EBP = 0012F3A4 EFL = 00010282
Ao depurar localmente onde a falha não ocorre, mais alguns símbolos são visíveis no assembly:
static Singleton* GetInstance()
{
0FBD1650 push ebp
0FBD1651 mov ebp,esp
0FBD1653 push 0FFFFFFFFh
0FBD1655 push offset __ehhandler$?GetInstance@Singleton@Native@@SAPAV12@XZ (0FBD86BCh)
0FBD165A mov eax,dword ptr fs:[00000000h]
0FBD1660 push eax
0FBD1661 mov eax,dword ptr [___security_cookie (0FBF03CCh)]
0FBD1666 xor eax,ebp
0FBD1668 push eax
0FBD1669 lea eax,[ebp-0Ch]
0FBD166C mov dword ptr fs:[00000000h],eax
static Singleton Instance;
0FBD1672 mov eax,dword ptr [__tls_index (0FBF0668h)]
0FBD1677 mov ecx,dword ptr fs:[2Ch]
0FBD167E mov edx,dword ptr [ecx+eax*4]
0FBD1681 mov eax,dword ptr [TSS0<`template-parameter-2',Native::Singleton::tInstance,Native::Singleton * * const volatile,void,int, ?? &> (0FBF063Ch)]
0FBD1686 cmp eax,dword ptr [edx+4]
0FBD168C jle Native::Singleton::GetInstance+79h (0FBD16C9h)
O símbolo__tls_index parece pertencer a alguma loja local de threads (adivinhada pelo nome). Isso combina comEstática mágica que usa o armazenamento local de encadeamentos como uma otimização de desempenho na implementação de referência. Ao falhar, o armazenamento local do encadeamento retorna0.
Isso poderia ser um erro no ambiente de tempo de execução no Windows Server 2003 que gerencia e inicializa o armazenamento local do thread?
Editar 2Relatado como bug no Microsoft Connect:Relatório de erro