Welcome Guest,Register Now
Log In

ANT Forum

Welcome guest, please Login or Register

   

Managed Library getUnmanagedLibraryVersion bug

Rank

Total Posts: 1

Joined 0

PM

Hello,

I've come across what looks like a subtle bug in the Managed Library function ANT_VersionInfo.getUnmanagedLibraryVersion().

On some machines calling this was crashing the app with the exception 0xc0000374 (STATUS_HEAP_CORRUPTION).

I was only able to reproduce this reliably in our software on a few machines (adding this call to the demo app would work fine on the same machines).

The best explanation I could come up with was that it was a problem with how the unmanaged function was called. I was able to fix it by changing the p/invoke call to:

private static extern IntPtr getUnmanagedVersion(); 


and the managed wrapper to:

public static string getUnmanagedLibraryVersion()
{
    IntPtr pStr 
getUnmanagedVersion();
    return 
Marshal.PtrToStringAnsi(pStr);


PtrToStringAnsi will make a copy of the string, where before the const string as being returned directly. My theory is that the crash was caused after .net tried to free the unmanaged memory. I am not sure why it only appeared in some situations though.

Regards,
Andrew      
RankRankRankRank

Total Posts: 313

Joined 2011-09-12

PM

Hi Andrew,
This does look like a bug, I believe the default marshalling of an unmarked string return parameter attempts to free the returned string from the global pool. In the c++ library this is just a method local string literal, so I am not sure why we haven't seen this crash more often.

Do you by any chance have any code that you would be able to share with us that will consistently trigger this bug? Regardless, we will make a fix for this in the next version of the library. Thanks for reporting this bug.      

Signature

Dynastream Developer

Rank

Total Posts: 1

Joined 0

PM

I have only been able to get it to show up in our main software, and then only on a few machines. I tried building a small demo app but could not even reproduce it on those same machines.

This suggests it is not an compile-time problem, but might come down to a particular combination of the order of instructions in the app and the version of the CLR it is executed on?

At any rate, it is probably not a commonly used function and a solution similar to mine should resolve this. Thank you for the quick response.      
RankRankRankRank

Total Posts: 313

Joined 2011-09-12

PM

Yeah, memory errors can be difficult to reproduce because often times they are only detected under specific circumstances. Without a reliable way to reproduce it, I think I will use your fix because we know it works. So, thanks for your contribution! smile      

Signature

Dynastream Developer