[Scilab-users] Minimal mono/call_scilab example crashes with optimizations turned on

Bogdan Burlacu froz3nshade at gmail.com
Fri Nov 8 11:24:33 CET 2013


On Fri, 08 Nov 2013 10:51:58 +0100
Sylvestre Ledru <sylvestre.ledru at scilab-enterprises.com> wrote:

> Hello,
> 
> On 08/11/2013 10:28, Bogdan Burlacu wrote:
> > Hello,
> >
> > I am using Scilab-5.4.1 and mono-3.2.3, on 64-bit arch linux.
> >
> > I've attached a minimal example in the file test.cs (also posted on
> > http://pastebin.com/JukugFFs).
> >
> > The code is compiled with 'gmcs /reference:Mono.Posix.dll /unsafe
> > test.cs'
> >
> AFAIK, this feature has never been tested with Mono...
> I am glad to know that it is even starting correctly without the 
> optimisation...
> You should try to make a smaller test case and/or build with the
> debug symbols.
> 
> Sylvestre
> 
> _______________________________________________
> users mailing list
> users at lists.scilab.org
> http://lists.scilab.org/mailman/listinfo/users

Hi,

Building the example with debug symbols adds very little new
information:

Stacktrace:

  at <unknown> <0xffffffff>
  at (wrapper managed-to-native)
  object.__icall_wrapper_mono_marshal_free (intptr) <IL 0x0000d,
  0xffffffff> at (wrapper managed-to-native)
  Test.createNamedMatrixOfBoolean (intptr,string,int,int,int[]) <IL
  0x0003c, 0xffffffff> at Test.createNamedMatrixOfBoolean
  (string,int,int,bool[]) [0x00042]
  in /home/master/scilab/call_scilab_test/test.cs:56 at Test.Main ()
  [0x00099] in /home/master/scilab/call_scilab_test/test.cs:128 at
  (wrapper runtime-invoke) object.runtime_invoke_void
  (object,intptr,intptr,intptr) <IL 0x0004c, 0xffffffff>

Native stacktrace:

        mono() [0x4b5bc1]
        mono() [0x50cc3b]
        mono() [0x423f82]
        /usr/lib/libpthread.so.0(+0xf870) [0x7fdc24a40870]
        /usr/lib/libc.so.6(cfree+0x14) [0x7fdc24702094]
        [0x4071fe4a]

It says that the crash happens when calling the native scilab function
at line 56.

I think the problem is when a wrapper method (for example,
createNamedMatrixOfBoolean) initializes a variable (var matrixInt = new
int[]) and then passes its address to the native call:
api_Err SciErr = createNamedMatrixOfBoolean (IntPtr.Zero, matrixName,
iRows, iCols, matrixInt);

The same error occurs for example in the call to getNamedVarType() from
http://gitweb.scilab.org/?p=scilab.git;a=blob;f=scilab/modules/call_scilab/examples/call_scilab/NET/C%23/dotnetsci/Scilab.cs;h=6b76897a8b5238838627653b6c0a33b043d9201f;hb=HEAD

Passing &iType in the getNamedVarType() native call in the wrapper
causes the program to crash (with optimizations):
public unsafe int getNamedVarType(string matrixName)
{
    int iType = 0;
    System.IntPtr ptrEmpty = new System.IntPtr();
    Scilab_cs_wrapper.api_Err SciErr =
    Scilab_cs_wrapper.getNamedVarType(ptrEmpty, matrixName, &iType); 
    if (SciErr.iErr == 0) 
        return iType; 
    return 0;
}

On the other hand, changing the wrapper method to directly call the
more low level native methods works:
public unsafe int getNamedVarType(string matrixName)
{
    int* iAddr = null;
    Scilab_cs_wrapper.api_Err sciErr;
    int iType = 0;
    sciErr = Scilab_cs_wrapper.getVarAddressFromName (IntPtr.Zero,
    matrixName, &iAddr); 
    if (sciErr.iErr != 0) { 
        Console.WriteLine("Unable to get address of variable " + matrixName); 
        return -1;
    }
    sciErr = Scilab_cs_wrapper.getVarType(IntPtr.Zero, iAddr, &iType); 
    if (sciErr.iErr != 0) {
	Console.WriteLine ("Unable to get type of variable " +
	matrixName); 
        return -1; 
    }
    return iType;
}

So it has something to do with passing pointers from managed to
unmanaged native calls and so on.

All that is needed to reproduce this behaviour is to run the
call_scilab C# example (from the scilab source) with mono and turn on
optimizations.

Maybe you guys have some idea what goes on under the hood. I have
looked at the sources in api_common.cpp and api_boolean.cpp and the
memory allocation mechanisms seem rather complicated.

Best,
Bogdan




More information about the users mailing list