-1

I've implemented this APIs some time ago and everything was working quite well until some weeks ago when I noticed it, The intermittent crash, the famous Marshaling related in .NET "Attempted to read or write protected memory. This is often an indication that other memory is corrupt". I noticed that there was also a certain pattern related to the number of opened applications that I have, so I assume its something related to the memory. But checking the available memory, it still pointing to a healthy state when it's crashing. Please see bellow the functions:

C++  
__declspec(dllexport) char* xReadData(char *p_buffer, int offset, int size)
{
    // do nothing
    return p_buffer; 
}

C#
[DllImport(PathToDll, CharSet = CharSet.Ansi, CallingConvention = CallingConvention.Cdecl)]
public static extern IntPtr xReadData([Out] IntPtr buffer, int offset, int size);

// SIZE = amount of bytes to read (2^13)
IntPtr pnt = Marshal.AllocHGlobal(SIZE);
...
try
{                                
    xReadData(pnt, 0, SIZE); >> crashing on [Managed to Native Transition]  

}
catch
{
}
...
Marshal.FreeHGlobal(pnt);

According to my analysis it crashes in between the completion of the native function and the returning to the managed code again.

Thanks in advance.

Allegro07
  • 1
  • 1
  • Welcome to Stack Overflow! Recommend reviewing guidelines for asking this type of question: http://stackoverflow.com/help/mcve – Philip Pittle Nov 18 '14 at 12:12
  • 1
    Completely ignoring the *size* argument in the native code is of course pretty much guaranteed to cause trouble. Yes, AccessViolations are normal when you do this. – Hans Passant Nov 18 '14 at 12:20
  • It was a typo in the edit section. Corrected now. – Allegro07 Nov 18 '14 at 12:31
  • The question is still opened. I hope that I included all parts needed to point out where the problem is. – Allegro07 Nov 18 '14 at 12:58

1 Answers1

0
if ((offset>-1) && (offset + size<= MAX_BYTES))
{
    memcpy(p_buffer, &(input_list[offset]), size);
}

That condition will definitely throw exception when offset is equal to MAX_BYTES and size is equal to zero.

input_list[MAX_BYTES] is out of bounds.

Also, I hope you deallocate the buffer :-')

Erti-Chris Eelmaa
  • 25,338
  • 6
  • 61
  • 78
  • Thanks for the response. This is true, one potential error, only that in this case the offset param is always passed by value and is 0. I am pretty sure that the crash is not in the native code because I did analyse it. – Allegro07 Nov 18 '14 at 13:21
  • I free the buffer, true. At the time it's crashing it doesn't even gets that far to free the buffer. It just crashes in between the completion of the native function and the returning to the managed code again. – Allegro07 Nov 18 '14 at 13:31
  • @Allegro07; use the divide&conquer when debugging. Start getting rid of the stuff, one by one. Get rid of the `memcpy` and see if the crash is still there, if it is? Then that part is not relevant to the question. Why does your method return the same `IntPtr` as the one you passed in? – Erti-Chris Eelmaa Nov 18 '14 at 13:33
  • Currently this is the design of the c++ function that is not my artwork, it's stupid i agree but this is not the point. I avoid the memcpy action and the crash is still there somewhere, but this is a good feedback in order to improve the question input data and exclude the memcpy. – Allegro07 Nov 18 '14 at 13:52
  • @Allegro07, there's really not much I can tell you. Create a new test project and see if you can reproduce the issue you're having. See if not returning anything from function makes it better. Also, set the calling convention on C++ side explictly. Don't rely on compiler defaults. `__declspec(dllexport) __cdecl` or whatever. Which parameters change? Are you always calling (0, CONSTANT_SIZE)? Are you accessing it from different threads? What is this "certain pattern" you're talking about in the post. – Erti-Chris Eelmaa Nov 18 '14 at 22:45