CSharp bindings fail smoketest with "free(): invalid pointer"

[Richard Boulton]

The CSharp bindings from SVN HEAD fail to pass the smoketest on my machine, reporting an error in free:

$ make check make check-recursive Making check in docs make[2]: Nothing to be done for `check'. make check-TESTS

/usr/bin/mcs -unsafe -target:exe -out:SmokeTest.exe `test -f SmokeTest.cs

echo

'/home/richard/private/Working/xapian/xapian-bindings/csharp/'`SmokeTest.cs -r:XapianSharp.dll * glibc detected * /usr/bin/cli: free(): invalid pointer: 0x0002be14 * make[3]: * [check-TESTS] Interrupt make[2]: * [check-am] Interrupt make[1]: * [check-recursive] Interrupt make: * [check] Interrupt

$ mcs --version Mono C# compiler version 1.2.3.1

This is running on Ubuntu feisty on an Intel Core-Duo.

This may be a problem with my version of mcs, since it worked in the past with earlier versions. Alternatively, it may be that the newer mcs notices an error in the generated code which earlier versions missed.

Success or failure reports with other versions of mcs would be useful.

[Richard Boulton]

I should note that in the output above, the process hangs indefinitely after printing:

* glibc detected * /usr/bin/cli: free(): invalid pointer: 0x0002be14 *

I pressed CTRL-C after about 10 seconds to generate the above output.

[Olly Betts]

Works for me:

$ mcs --version Mono C# compiler version 1.1.17.1

Ubuntu edgy, AMD x86_64.

But unless I'm confused, this error is happening while trying to *compile* SmokeTest.exe, not while trying to run it. Sounds like a buggy compiler to me - you shouldn't really be able to crash a compiler with any input...

[Richard Boulton]

You are confused, yes, because the automake rule for running tests doesn't display anything to say that it's starting to run the test.

Here's some clearer output (immediately after running "make clean" and then "make"):

csharp $ make SmokeTest.exe

/usr/bin/mcs -unsafe -target:exe -out:SmokeTest.exe `test -f SmokeTest.cs

echo

'/home/richard/private/Working/xapian/xapian-bindings/csharp/'`SmokeTest.cs -r:XapianSharp.dll csharp $ ./SmokeTest.exe * glibc detected * /usr/bin/cli: free(): invalid pointer: 0x0002be14 *

[Richard Boulton]

I've prodded this a bit further, but have come to the limits of my ability/knowledge for now.

I managed to get valgrind to run SmokeTest.exe, which resulted in the output which I'll attach shortly: the interesting lines, I think, are:

==22086== Invalid read of size 1 ==22086== at 0x4022493: strlen (mc_replace_strmem.c:246) ==22086== by 0x4FE6A1A: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/libstdc++.so.6.0.8) ==22086== by 0x4DC7EB6: CSharp_Document_SetData (xapian_wrap.cc:1845)

which I believe indicates a problem with the marshalling of managed strings to C++ strings. I don't understand the PINVOKE mechanism enough to know what the generated code should be, though: it looks to me as if the PINVOKE mechanism is expecting the native function called to take a "char *" argument, when actually it takes a std::string argument, but I may be misunderstanding it.

Since I'm not going to be able to fix this, I'll orphan it to make it clear that it needs someone to pick it up.

[Richard Boulton]

Output of valgrind

[Richard Boulton]

This appears to have been a problem due to using "mcs" instead of "gmcs". gmcs is required to compile things to run with the "mono 2" runtime - ie, mono versions from 1.2 onwards.

We've changed configure.ac to prefer "gmcs" to "mcs" if both are available, which has fixed the problem for me, and should work in most cases. If this doesn't work for you, you can specify which of "mcs" and "gmcs" to use explicitly by setting "./configure CSC=mcs", where the value of CSC is the compiler you want to use.

If this doesn't work for significant numbers of users, we could implement a check in configure.ac (if "mcs" or "gmcs" is found) of the version of "mono" installed, and use the appropriate compiler based on that.

[Olly Betts]

Scarily, it sounds like this only used to work by chance:

​http://thread.gmane.org/gmane.comp.gnome.mono.general/30081/focus=30084

But that the runtime support is now properly implemented and so this will all sort itself out in Mono 1.2.4:

​http://bugzilla.ximian.com/show_bug.cgi?id=80786

[Olly Betts]

Fixed in 1.0.0 release.