[Mono-dev] glibc detected *** mono: double free or corruption

[Stephen A]

On Wed, 17 Oct 2007 00:16:58 +0300, Rolf Bjarne Kvinge <rolflists at ya.com>  
wrote:

>> -----Original Message-----
>> From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-
>> bounces at lists.ximian.com] On Behalf Of Stephen A
>> Sent: martes, 16 de octubre de 2007 21:58
>> To: mono-devel-list at lists.ximian.com
>> Subject: Re: [Mono-dev] glibc detected *** mono: double free or
>> corruption
>>
>> > C-code typically expects the string array to end with a null element,  
>> I
>> > can't see that you're doing that in your code.
>> >
>> > Otherwise you might want to try to create the array manually using the
>> > System.Runtime.Interop.Marshal class (use AllocHGlobal to create the
>> > array memory, then StringTo* to create unmanaged versions of the  
>> string)
> to
>> > see if that works.
>> >
>> > Rolf
>> >
>>
>> I thought that the default marshaller took care of that issue?
>> According to MSDN
> (http://msdn2.microsoft.com/en-us/library/75dwhxf7(VS.71).aspx), a
>> System.String is converted to a null terminated array of chars by  
>> default
>> (I assume this also happens to arrays of strings).
>
> I think I expressed myself in a bad way.
>
> What I wanted to say is that arrays (in general) are normally ended with  
> a
> null element in C (again, I haven't seen the C-code in question, so I  
> don't
> know for this particular case).
>
> Which would give a string array like this:
>
> string arr [] = {"abc", null}
>
> Note that the marshaller will put a \0 at the end of "abc" automatically.
>

Aha, now I see what you mean. Unfortunately this isn't the case here (it  
would be nice if it was so easy!), as the unmanaged function takes the  
string count explicitly through a parameter.

>> In any case, adding a \0 does not take care of the issue and, besides,  
>> the
> same code runs
>> fine under .Net - which leads me to believe that the error lies  
>> somewhere
>> else entirely.
>>
>
> The fact that the code runs on .Net is not a guarantee that your code is
> correct :)
> Pinvokes on MS has a history of being somewhat forgiving (but I'm not  
> saying
> that it isn't a bug with mono either)
>

True :)

>> Now that I took a look again, it seems that my error message is a
>> little different: "*** glibc detected *** mono: corrupted double-linked
> list:
>> 0x0000000001bed250 ***".
>
> Crash messages like these might change, especially if the memory is  
> trashed.
>

The thing is that this error message (apart from the address) never  
changes, which is somewhat strange for heap corruption which tends to be  
random.

 From what I can gather:
a) all data is marshalled correctly (certain, since these strings are  
actually fed to a compiler)
b) program executes correctly (output is as expected)
c) program usually crashes on exit (but not always)

My gut instinct says this crash *is* linked to data marshalling, but it is  
difficult to be certain. I guess the only way to find out for sure is by  
replicating in a test-case - which I'll try to do when I can find some  
free time.

If anyone has any other ideas regarding this problem, please share them!

- Stephen A