0

I need to interact with a native third-party library I don't have the source code of. I get a heap corruption from just a simple thing like this:

void MyInterop::DoNastyStuff(String^ foo) {
    ThirdParty::NativeThing x = ThirdParty::NativeThing(msclr::interop::marshal_as<std::wstring>(foo));
    x.doSomething(); // fine
    System::Console::WriteLine("foo"); // fine
} // boom

The heap corruption occurrs as soon as the method is left (this means, I can put as much code after the x.doSomething() as I want and everything runs fine).

When I create the third-party stuff on the heap, I get the heap corruption when using the delete command

void MyInterop::DoNastyStuffOnHeap(String^ foo) {
    ThirdParty::NativeThing* x = new ThirdParty::NativeThing(msclr::interop::marshal_as<std::wstring>(foo));
    x->doSomething(); // fine
    delete x; // boom
    System::Console::WriteLine("foo"); // fine after clicking Ignore in the dialog that pops up from VS
}

I already filed a bug report to the third party that provide me the DLL, but is there any workaround in the meantime for this?

Deduplicator
  • 44,692
  • 7
  • 66
  • 118
rabejens
  • 7,594
  • 11
  • 56
  • 104
  • What is the actual source of the corruption? Use the debugger to find out. Is it the destructor of NativeThing (looks like it from your code)? If so the only thing you can do is have it fixed or not call it, i.e. allocate using new and don't call delete, which is like the worst advice ever and results in memory and/or resource leaks. – stijn Oct 19 '16 at 11:03
  • What error is? What is the exception or the WIN32 error code? – Niall Oct 19 '16 at 11:03
  • Alternatives here could be isolating the buggy code to its own process... It may be pithy, but if the bug is being fixed by the vendor, and you are happy with the temporary memory leak, and assuming the error is isolated to the content of that allocation, consider not deleting the native object... that is a lot of buts... Best is get it fixed faster by the vendor. – Niall Oct 19 '16 at 11:06
  • 1
    I get the Heap Corruption dialog saying `CRT detected that the application wrote to memory after end of heap buffer`. When I click on `Retry`, my debugging session freezes. – rabejens Oct 19 '16 at 11:06
  • I can put the nasty stuff into a separate exe which I can call from my main application with `Process.Start`, and the separate program then does not release the buggy object, since it only does the one task and exits. – rabejens Oct 19 '16 at 11:07
  • The issue may come from a CRT discrepancy - the lib uses a different version than you're using in C++/CLI. You may try to build a native wrapper which doesn't use `std` objects - you can only use a managed-aware version of the CRT in C++/CLI, and you cannot change what the lib uses, so try to work around that. – Lucas Trzesniewski Oct 19 '16 at 12:15
  • @LucasTrzesniewski I actually phoned with someone from where I got the library and he told me something similar - they have different versions of the library. I sent them a small demo program that reproduces the issue and they now determine the correct version I need. – rabejens Oct 19 '16 at 12:26
  • They gave me another dll that should fit, but the problem persists, so I think they have a bug in their destructor. For the time being, I will use the method with the separate application. The native wrapper without `std` objects did not help either. – rabejens Oct 19 '16 at 13:28
  • I investigated some more as my separate exe randomly crashes. I find in my Windows log that this application crashes upon calling the destructor of the native object, so the third party really has a bug there and I have to have it fixed. – rabejens Oct 20 '16 at 08:40

0 Answers0