[Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Torello Querci
Hi al,

trying to handle more that 1024 handle file I got an exception even if
I increase the max number of file limit using setrlimit. The example
source code below.
Of course mono have the right pcap permission.

Using strace on both this code and no setrlimit version code I have
some differences.
On the no setrlimit version I have this syscall:

open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1
EMFILE (Too many open files)

and this seems to be correct.
On the setrlimit version code I have this syscalls:

open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024
close(1024) = 0

so seems that mono close the file because open  return value is 1024.

Is this a bug, a feature, or something else?

==
using System;
using System.IO;
using System.Text;
using System.Runtime.InteropServices;

namespace TestFiles
{

struct rlimit {
public IntPtr rlimit_cur;
public IntPtr rlimit_max;
}

class MainClass
{   
public static unsafe void Main (string[] args)
{
FileStream[] streams;
string path;
if (args.Length == 0) {
Console.WriteLine (You need to specify the 
number of files that
needs to be created.);
return;
}

int nFiles = Int32.Parse (args[0]);

streams = new FileStream[nFiles];

rlimit data = new rlimit ();
data.rlimit_cur = (IntPtr) 2;
data.rlimit_max = (IntPtr) 2;

int result = setrlimit (RLIMIT_NOFILE, data);
if (result != 0) {
throw new Exception (Cannot change limit on 
open files);
}

for (int i=0; inFiles; ++i) {
path = string.Format (file{0}.out, i);
try {
streams[i] = File.Open(path, 
FileMode.Create, FileAccess.Write,
FileShare.None);
} catch (Exception ex) {
Console.WriteLine (Unable to write 
file {0}, path);
Console.WriteLine (ex.Message);
Console.WriteLine (ex.StackTrace);  

return;
}
}
}

const int RLIMIT_NOFILE = 7;

[DllImport (libc, SetLastError = true)]
unsafe extern static int setrlimit(int resource, rlimit* rlim);

}
}
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Alan
Hi,

Mono itself has no trouble opening 1000's of files. Would you be able to
create an equivalent C program and see if that works as expected? My guess
would be that the equivalent C program will fail in the same way. If it
does not, then it's likely to be a mono bug.

Alan

On 4 November 2011 07:19, Torello Querci tque...@gmail.com wrote:

 Hi al,

 trying to handle more that 1024 handle file I got an exception even if
 I increase the max number of file limit using setrlimit. The example
 source code below.
 Of course mono have the right pcap permission.

 Using strace on both this code and no setrlimit version code I have
 some differences.
 On the no setrlimit version I have this syscall:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1
 EMFILE (Too many open files)

 and this seems to be correct.
 On the setrlimit version code I have this syscalls:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024
 close(1024) = 0

 so seems that mono close the file because open  return value is 1024.

 Is this a bug, a feature, or something else?


 ==
 using System;
 using System.IO;
 using System.Text;
 using System.Runtime.InteropServices;

 namespace TestFiles
 {

struct rlimit {
public IntPtr rlimit_cur;
public IntPtr rlimit_max;
}

class MainClass
{
public static unsafe void Main (string[] args)
{
FileStream[] streams;
string path;
if (args.Length == 0) {
Console.WriteLine (You need to specify the
 number of files that
 needs to be created.);
return;
}

int nFiles = Int32.Parse (args[0]);

streams = new FileStream[nFiles];

rlimit data = new rlimit ();
data.rlimit_cur = (IntPtr) 2;
data.rlimit_max = (IntPtr) 2;

int result = setrlimit (RLIMIT_NOFILE, data);
if (result != 0) {
throw new Exception (Cannot change limit
 on open files);
}

for (int i=0; inFiles; ++i) {
path = string.Format (file{0}.out, i);
try {
streams[i] = File.Open(path,
 FileMode.Create, FileAccess.Write,
 FileShare.None);
} catch (Exception ex) {
Console.WriteLine (Unable to write
 file {0}, path);
Console.WriteLine (ex.Message);
Console.WriteLine (ex.StackTrace);
return;
}
}
}

const int RLIMIT_NOFILE = 7;

[DllImport (libc, SetLastError = true)]
unsafe extern static int setrlimit(int resource, rlimit*
 rlim);

}
 }
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Torello Querci
This is the first test that I realized.
On the same machine, same kernel  same calls 

Below the source code:

=
#include linux/resource.h

//#include stdlib.h
#include stdio.h


int main(int argc, char* argv[]) {

FILE** fp;
int nFiles = atoi(argv[1]);
int i;
char filename[1024];

if (argc!=2) {
printf(Error. You need to specify the number of file that
need to create.\n);
return -1;
}

struct rlimit data;

data.rlim_cur = 2;
data.rlim_max = 2;

i = setrlimit (RLIMIT_NOFILE, data);
if (i != 0) {
printf (Error during changine files limits.\n);
return 1;
}

fp = calloc (nFiles, sizeof(FILE*));

for (i=0; inFiles; ++i) {
sprintf (filename, file%i.out, i);

fp[i] = fopen (filename, w+);
if (fp [i] == NULL) {
printf (Error in %s file creation.\n, filename);
return -1;
}
}

}

=

2011/11/4 Alan alan.mcgov...@gmail.com:
 Hi,
 Mono itself has no trouble opening 1000's of files. Would you be able to
 create an equivalent C program and see if that works as expected? My guess
 would be that the equivalent C program will fail in the same way. If it does
 not, then it's likely to be a mono bug.
 Alan

 On 4 November 2011 07:19, Torello Querci tque...@gmail.com wrote:

 Hi al,

 trying to handle more that 1024 handle file I got an exception even if
 I increase the max number of file limit using setrlimit. The example
 source code below.
 Of course mono have the right pcap permission.

 Using strace on both this code and no setrlimit version code I have
 some differences.
 On the no setrlimit version I have this syscall:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1
 EMFILE (Too many open files)

 and this seems to be correct.
 On the setrlimit version code I have this syscalls:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024
 close(1024)                             = 0

 so seems that mono close the file because open  return value is 1024.

 Is this a bug, a feature, or something else?


 ==
 using System;
 using System.IO;
 using System.Text;
 using System.Runtime.InteropServices;

 namespace TestFiles
 {

        struct rlimit {
                public IntPtr rlimit_cur;
                public IntPtr rlimit_max;
        }

        class MainClass
        {
                public static unsafe void Main (string[] args)
                {
                        FileStream[] streams;
                        string path;
                        if (args.Length == 0) {
                                Console.WriteLine (You need to specify the
 number of files that
 needs to be created.);
                                return;
                        }

                        int nFiles = Int32.Parse (args[0]);

                        streams = new FileStream[nFiles];

                        rlimit data = new rlimit ();
                        data.rlimit_cur = (IntPtr) 2;
                        data.rlimit_max = (IntPtr) 2;

                        int result = setrlimit (RLIMIT_NOFILE, data);
                        if (result != 0) {
                                throw new Exception (Cannot change limit
 on open files);
                        }

                        for (int i=0; inFiles; ++i) {
                                path = string.Format (file{0}.out, i);
                                try {
                                        streams[i] = File.Open(path,
 FileMode.Create, FileAccess.Write,
 FileShare.None);
                                } catch (Exception ex) {
                                        Console.WriteLine (Unable to write
 file {0}, path);
                                        Console.WriteLine (ex.Message);
                                        Console.WriteLine (ex.StackTrace);
                                        return;
                                }
                        }
                }

                const int RLIMIT_NOFILE = 7;

                [DllImport (libc, SetLastError = true)]
                unsafe extern static int setrlimit(int resource, rlimit*
 rlim);

        }
 }
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Robert Jordan
On 04.11.2011 10:17, Torello Querci wrote:
 This is the first test that I realized.
 On the same machine, same kernel  same calls 

You don't say which Mono arch you're using. On 32 bit,
the following might not be correct:

struct rlimit {
public IntPtr rlimit_cur;
public IntPtr rlimit_max;
}

because rlim_t is 8 byte long whereas IntPtr is 4 bytes.
This is because Mono is compiled with LARGEFILE64 support.

Robert



 Below the source code:

 =
 #includelinux/resource.h

 //#includestdlib.h
 #includestdio.h


 int main(int argc, char* argv[]) {

  FILE** fp;
  int nFiles = atoi(argv[1]);
  int i;
  char filename[1024];

  if (argc!=2) {
  printf(Error. You need to specify the number of file that
 need to create.\n);
  return -1;
  }

  struct rlimit data;

  data.rlim_cur = 2;
  data.rlim_max = 2;

  i = setrlimit (RLIMIT_NOFILE,data);
  if (i != 0) {
  printf (Error during changine files limits.\n);
  return 1;
  }

  fp = calloc (nFiles, sizeof(FILE*));

  for (i=0; inFiles; ++i) {
  sprintf (filename, file%i.out, i);

  fp[i] = fopen (filename, w+);
  if (fp [i] == NULL) {
  printf (Error in %s file creation.\n, filename);
  return -1;
  }
  }

 }

 =

 2011/11/4 Alanalan.mcgov...@gmail.com:
 Hi,
 Mono itself has no trouble opening 1000's of files. Would you be able to
 create an equivalent C program and see if that works as expected? My guess
 would be that the equivalent C program will fail in the same way. If it does
 not, then it's likely to be a mono bug.
 Alan

 On 4 November 2011 07:19, Torello Quercitque...@gmail.com  wrote:

 Hi al,

 trying to handle more that 1024 handle file I got an exception even if
 I increase the max number of file limit using setrlimit. The example
 source code below.
 Of course mono have the right pcap permission.

 Using strace on both this code and no setrlimit version code I have
 some differences.
 On the no setrlimit version I have this syscall:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1
 EMFILE (Too many open files)

 and this seems to be correct.
 On the setrlimit version code I have this syscalls:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024
 close(1024) = 0

 so seems that mono close the file because open  return value is 1024.

 Is this a bug, a feature, or something else?


 ==
 using System;
 using System.IO;
 using System.Text;
 using System.Runtime.InteropServices;

 namespace TestFiles
 {

 struct rlimit {
 public IntPtr rlimit_cur;
 public IntPtr rlimit_max;
 }

 class MainClass
 {
 public static unsafe void Main (string[] args)
 {
 FileStream[] streams;
 string path;
 if (args.Length == 0) {
 Console.WriteLine (You need to specify the
 number of files that
 needs to be created.);
 return;
 }

 int nFiles = Int32.Parse (args[0]);

 streams = new FileStream[nFiles];

 rlimit data = new rlimit ();
 data.rlimit_cur = (IntPtr) 2;
 data.rlimit_max = (IntPtr) 2;

 int result = setrlimit (RLIMIT_NOFILE,data);
 if (result != 0) {
 throw new Exception (Cannot change limit
 on open files);
 }

 for (int i=0; inFiles; ++i) {
 path = string.Format (file{0}.out, i);
 try {
 streams[i] = File.Open(path,
 FileMode.Create, FileAccess.Write,
 FileShare.None);
 } catch (Exception ex) {
 Console.WriteLine (Unable to write
 file {0}, path);
 Console.WriteLine (ex.Message);
 Console.WriteLine (ex.StackTrace);
 return;
 }
 }
 }

 const int RLIMIT_NOFILE = 7;

 [DllImport (libc, SetLastError = true)]
 unsafe extern static int setrlimit(int resource, rlimit*
 rlim);

 }
 }
 ___
 

Re: [Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Torello Querci
Sorry, You are right  I'm on 32bit arch

2011/11/4 Robert Jordan robe...@gmx.net:
 On 04.11.2011 10:17, Torello Querci wrote:
 This is the first test that I realized.
 On the same machine, same kernel  same calls 

 You don't say which Mono arch you're using. On 32 bit,
 the following might not be correct:

        struct rlimit {
                public IntPtr rlimit_cur;
                public IntPtr rlimit_max;
        }

 because rlim_t is 8 byte long whereas IntPtr is 4 bytes.
 This is because Mono is compiled with LARGEFILE64 support.

 Robert



 Below the source code:

 =
 #includelinux/resource.h

 //#includestdlib.h
 #includestdio.h


 int main(int argc, char* argv[]) {

      FILE** fp;
      int nFiles = atoi(argv[1]);
      int i;
      char filename[1024];

      if (argc!=2) {
          printf(Error. You need to specify the number of file that
 need to create.\n);
          return -1;
      }

      struct rlimit data;

      data.rlim_cur = 2;
      data.rlim_max = 2;

      i = setrlimit (RLIMIT_NOFILE,data);
      if (i != 0) {
          printf (Error during changine files limits.\n);
          return 1;
      }

      fp = calloc (nFiles, sizeof(FILE*));

      for (i=0; inFiles; ++i) {
          sprintf (filename, file%i.out, i);

          fp[i] = fopen (filename, w+);
          if (fp [i] == NULL) {
              printf (Error in %s file creation.\n, filename);
              return -1;
          }
      }

 }

 =

 2011/11/4 Alanalan.mcgov...@gmail.com:
 Hi,
 Mono itself has no trouble opening 1000's of files. Would you be able to
 create an equivalent C program and see if that works as expected? My guess
 would be that the equivalent C program will fail in the same way. If it does
 not, then it's likely to be a mono bug.
 Alan

 On 4 November 2011 07:19, Torello Quercitque...@gmail.com  wrote:

 Hi al,

 trying to handle more that 1024 handle file I got an exception even if
 I increase the max number of file limit using setrlimit. The example
 source code below.
 Of course mono have the right pcap permission.

 Using strace on both this code and no setrlimit version code I have
 some differences.
 On the no setrlimit version I have this syscall:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1
 EMFILE (Too many open files)

 and this seems to be correct.
 On the setrlimit version code I have this syscalls:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024
 close(1024)                             = 0

 so seems that mono close the file because open  return value is 1024.

 Is this a bug, a feature, or something else?


 ==
 using System;
 using System.IO;
 using System.Text;
 using System.Runtime.InteropServices;

 namespace TestFiles
 {

         struct rlimit {
                 public IntPtr rlimit_cur;
                 public IntPtr rlimit_max;
         }

         class MainClass
         {
                 public static unsafe void Main (string[] args)
                 {
                         FileStream[] streams;
                         string path;
                         if (args.Length == 0) {
                                 Console.WriteLine (You need to specify the
 number of files that
 needs to be created.);
                                 return;
                         }

                         int nFiles = Int32.Parse (args[0]);

                         streams = new FileStream[nFiles];

                         rlimit data = new rlimit ();
                         data.rlimit_cur = (IntPtr) 2;
                         data.rlimit_max = (IntPtr) 2;

                         int result = setrlimit (RLIMIT_NOFILE,data);
                         if (result != 0) {
                                 throw new Exception (Cannot change limit
 on open files);
                         }

                         for (int i=0; inFiles; ++i) {
                                 path = string.Format (file{0}.out, i);
                                 try {
                                         streams[i] = File.Open(path,
 FileMode.Create, FileAccess.Write,
 FileShare.None);
                                 } catch (Exception ex) {
                                         Console.WriteLine (Unable to write
 file {0}, path);
                                         Console.WriteLine (ex.Message);
                                         Console.WriteLine (ex.StackTrace);
                                         return;
                                 }
                         }
                 }

                 const int RLIMIT_NOFILE = 7;

                 [DllImport (libc, SetLastError = true)]
                 unsafe extern static int setrlimit(int resource, 

Re: [Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Torello Querci
Looking in the strace output file this is the setrlimit call:

setrlimit(RLIMIT_NOFILE, {rlim_cur=2, rlim_max=2}) = 0

so seems to be correct 


2011/11/4 Torello Querci tque...@gmail.com:
 Sorry, You are right  I'm on 32bit arch

 2011/11/4 Robert Jordan robe...@gmx.net:
 On 04.11.2011 10:17, Torello Querci wrote:
 This is the first test that I realized.
 On the same machine, same kernel  same calls 

 You don't say which Mono arch you're using. On 32 bit,
 the following might not be correct:

        struct rlimit {
                public IntPtr rlimit_cur;
                public IntPtr rlimit_max;
        }

 because rlim_t is 8 byte long whereas IntPtr is 4 bytes.
 This is because Mono is compiled with LARGEFILE64 support.

 Robert



 Below the source code:

 =
 #includelinux/resource.h

 //#includestdlib.h
 #includestdio.h


 int main(int argc, char* argv[]) {

      FILE** fp;
      int nFiles = atoi(argv[1]);
      int i;
      char filename[1024];

      if (argc!=2) {
          printf(Error. You need to specify the number of file that
 need to create.\n);
          return -1;
      }

      struct rlimit data;

      data.rlim_cur = 2;
      data.rlim_max = 2;

      i = setrlimit (RLIMIT_NOFILE,data);
      if (i != 0) {
          printf (Error during changine files limits.\n);
          return 1;
      }

      fp = calloc (nFiles, sizeof(FILE*));

      for (i=0; inFiles; ++i) {
          sprintf (filename, file%i.out, i);

          fp[i] = fopen (filename, w+);
          if (fp [i] == NULL) {
              printf (Error in %s file creation.\n, filename);
              return -1;
          }
      }

 }

 =

 2011/11/4 Alanalan.mcgov...@gmail.com:
 Hi,
 Mono itself has no trouble opening 1000's of files. Would you be able to
 create an equivalent C program and see if that works as expected? My guess
 would be that the equivalent C program will fail in the same way. If it 
 does
 not, then it's likely to be a mono bug.
 Alan

 On 4 November 2011 07:19, Torello Quercitque...@gmail.com  wrote:

 Hi al,

 trying to handle more that 1024 handle file I got an exception even if
 I increase the max number of file limit using setrlimit. The example
 source code below.
 Of course mono have the right pcap permission.

 Using strace on both this code and no setrlimit version code I have
 some differences.
 On the no setrlimit version I have this syscall:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = -1
 EMFILE (Too many open files)

 and this seems to be correct.
 On the setrlimit version code I have this syscalls:

 open(file1021.out, O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 1024
 close(1024)                             = 0

 so seems that mono close the file because open  return value is 1024.

 Is this a bug, a feature, or something else?


 ==
 using System;
 using System.IO;
 using System.Text;
 using System.Runtime.InteropServices;

 namespace TestFiles
 {

         struct rlimit {
                 public IntPtr rlimit_cur;
                 public IntPtr rlimit_max;
         }

         class MainClass
         {
                 public static unsafe void Main (string[] args)
                 {
                         FileStream[] streams;
                         string path;
                         if (args.Length == 0) {
                                 Console.WriteLine (You need to specify 
 the
 number of files that
 needs to be created.);
                                 return;
                         }

                         int nFiles = Int32.Parse (args[0]);

                         streams = new FileStream[nFiles];

                         rlimit data = new rlimit ();
                         data.rlimit_cur = (IntPtr) 2;
                         data.rlimit_max = (IntPtr) 2;

                         int result = setrlimit (RLIMIT_NOFILE,data);
                         if (result != 0) {
                                 throw new Exception (Cannot change limit
 on open files);
                         }

                         for (int i=0; inFiles; ++i) {
                                 path = string.Format (file{0}.out, i);
                                 try {
                                         streams[i] = File.Open(path,
 FileMode.Create, FileAccess.Write,
 FileShare.None);
                                 } catch (Exception ex) {
                                         Console.WriteLine (Unable to 
 write
 file {0}, path);
                                         Console.WriteLine (ex.Message);
                                         Console.WriteLine (ex.StackTrace);
                                         return;
                                 }
         

Re: [Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Robert Jordan
On 04.11.2011 10:49, Torello Querci wrote:
 Sorry, You are right  I'm on 32bit arch

Then you need this:

  struct rlimit {
 public long rlimit_cur;
 public long rlimit_max;
  }

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Robert Jordan
On 04.11.2011 11:18, Torello Querci wrote:
 Hy Robert,

 On 32bit arch IntPtr is 32bit, on 64 bit arch, IntPrt is 64 bit.

Yes, this is not the issue here.


 However I try your suggestion but the setrlimit no more work. Looking
 inside the strace output this is the setrlimit syscall:

 setrlimit(RLIMIT_NOFILE, {rlim_cur=2, rlim_max=0}) = -1 EINVAL
 (Invalid argument)

Indeed, the p/invoked symbol setrlimit is always the 32 bit variant
on 32 bit systems.

C programs can change this with -D_FILE_OFFSET_BITS=64,
as Mono does, but this does not affect p/invoke.


Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Robert Jordan
On 04.11.2011 08:19, Torello Querci wrote:
 Hi al,

 trying to handle more that 1024 handle file I got an exception even if
 I increase the max number of file limit using setrlimit. The example
 source code below.
 Of course mono have the right pcap permission.

This is a bug in Mono's io-layer:

https://github.com/mono/mono/blob/master/mono/io-layer/handles.c#L251

getdtablesize() is returning the max count of possible open
file descriptors *at start-up*, so any later setrlimit has
no effect.

Please file a bug at bugzilla.xamarin.com.

Meanwhile, you could just increase the open files limit
with ulimit -S -H 2, so don't mark the bug as super critical ;)

Robert


___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Robert Jordan
On 04.11.2011 13:26, Robert Jordan wrote:
 Meanwhile, you could just increase the open files limit
 with ulimit -S -H 2, so don't mark the bug as super critical ;)

I've fat-fingered ulimit's arguments:

ulimit -S -H -n 2

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]

2011-11-04 Thread Jonathan Shore
Hi,

I ran across a perplexing error when calling a C# method in one of my 
assemblies from C++: 

System.MissingMethodException: Method not found:
'System.Type.op_Equality'.

Searching google, it seems that the MonoTouch folks encounter this as well and 
the explanation is that MT is not yet fully .NET 4.0 compliant 
[http://comments.gmane.org/gmane.comp.gnome.mono.monotouch/1538].  I am using 
the 2.10.6 mono SDK on OS X and not using mono touch, however.

Is it the case that I cannot yet call into .NET 4.0 assemblies from C++ (i 
doubt)?  
Do I need to somehow tell the CLR to use the .NET 4.0 mscorlib when I call 
mono_domain_assembly_open()?

Note that I am not initializing mono_domain_assembly_open() with an exe, rather 
with a dll.  Perhaps there is some setup I need to do?

Also I am able to evaluate into the function until it needs to reference type 
equality.  The function I am evaluating is performing reflection.

Thanks

Jonathan___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]

2011-11-04 Thread Zoltan Varga
Hi,


 Note that I am not initializing mono_domain_assembly_open() with an exe,
 rather with a dll.  Perhaps there is some setup I need to do?


The dll is probably compiled against an older net version, causing the
runtime to load
an older mscorlib.

Zoltan
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]

2011-11-04 Thread Robert Jordan
On 04.11.2011 19:32, Jonathan Shore wrote:
 Note that I am not initializing mono_domain_assembly_open() with an exe, 
 rather with a dll.  Perhaps there is some setup I need to do?

How are you initializing the runtime exactly (code)?

You probably need mono_jit_init_version() or alternatively
pass a .NET 4.0 assembly to mono_jit_init().

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]

2011-11-04 Thread Jonathan Shore
My assembly is definitely 4.0 and monodis --assemblyref indicates dependency 
on .NET 4 assemblies.   I'll look into mono_jit_init_version() and see whether 
this helps.

AssemblyRef Table
1: Version=4.0.0.0
Name=System
Flags=0x
Public Key:
0x: B7 7A 5C 56 19 34 E0 89 
2: Version=4.0.0.0
Name=mscorlib
Flags=0x
Public Key:
0x: B7 7A 5C 56 19 34 E0 89 
3: Version=4.0.0.0
Name=System.Core
Flags=0x
Public Key:
0x: B7 7A 5C 56 19 34 E0 89 

The initialization part of the C++ code looks like:

// create AppDomain
_domain = mono_jit_init (api);
 
// load bootstrap assembly
string dir (assemblydir);
string path = dir + /com.gf.core.dll;
_core = mono_domain_assembly_open (_domain, path.c_str());

Where com.gf.core.dll is compiled to .NET 4.0.  Thanks___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]

2011-11-04 Thread Robert Jordan
On 04.11.2011 20:05, Jonathan Shore wrote:
 My assembly is definitely 4.0 and monodis --assemblyref indicates 
 dependency on .NET 4 assemblies.   I'll look into mono_jit_init_version() and 
 see whether this helps.

Yes, but you're not using it for initialization.


   // create AppDomain

This won't initialize a v4 runtime. The default is 2.0:

   _domain = mono_jit_init (api);
   
   // load bootstrap assembly
   string dir (assemblydir);
   string path = dir + /com.gf.core.dll;

That's too late:

   _core = mono_domain_assembly_open (_domain, path.c_str());

 Where com.gf.core.dll is compiled to .NET 4.0.  Thanks

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]

2011-11-04 Thread Jonathan Shore
I'm working off of http://www.mono-project.com/Embedding_Mono with regard to 
initialization.   I tried a number of possible version #s for the 
mono_jit_init_version(), but indicated:

WARNING: The runtime version supported by this application is unavailable.
Using default runtime: v2.0.50727

what is the version # one should use to correspond to .NET 4?   The version #s 
like v2.0.50727 are peculiar (but I think a MS thing).   Or is there a way to 
initialize the domain using the assembly?  Is the argument to the domain 
optionally either its name or the path to the main assembly?   I note that in 
the header have the signature:

mono_jit_init (const char *file);

Whereas the documentation in the link above indicates that mono_jit_init () is 
provided with the name for the domain.

I guess the docs are not very clear here.  Just need one approach that works.  
Thanks for your help.


On Nov 4, 2011, at 3:13 PM, Robert Jordan wrote:

 On 04.11.2011 20:05, Jonathan Shore wrote:
 My assembly is definitely 4.0 and monodis --assemblyref indicates 
 dependency on .NET 4 assemblies.   I'll look into mono_jit_init_version() 
 and see whether this helps.
 
 Yes, but you're not using it for initialization.
 
 
  // create AppDomain
 
 This won't initialize a v4 runtime. The default is 2.0:
 
  _domain = mono_jit_init (api);
  
  // load bootstrap assembly
  string dir (assemblydir);
  string path = dir + /com.gf.core.dll;
 
 That's too late:
 
  _core = mono_domain_assembly_open (_domain, path.c_str());
 
 Where com.gf.core.dll is compiled to .NET 4.0.  Thanks
 
 Robert
 
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]

2011-11-04 Thread Jonathan Shore
Thanks all.  I solved it by passing the bootstrap assembly into mono_jit_init 
().  Did not realize this call could take a path to an assembly.

On Nov 4, 2011, at 3:13 PM, Robert Jordan wrote:

 On 04.11.2011 20:05, Jonathan Shore wrote:
 My assembly is definitely 4.0 and monodis --assemblyref indicates 
 dependency on .NET 4 assemblies.   I'll look into mono_jit_init_version() 
 and see whether this helps.
 
 Yes, but you're not using it for initialization.
 
 
  // create AppDomain
 
 This won't initialize a v4 runtime. The default is 2.0:
 
  _domain = mono_jit_init (api);
  
  // load bootstrap assembly
  string dir (assemblydir);
  string path = dir + /com.gf.core.dll;
 
 That's too late:
 
  _core = mono_domain_assembly_open (_domain, path.c_str());
 
 Where com.gf.core.dll is compiled to .NET 4.0.  Thanks
 
 Robert
 
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]

2011-11-04 Thread Robert Jordan
On 04.11.2011 20:22, Jonathan Shore wrote:
 I'm working off of http://www.mono-project.com/Embedding_Mono with
 regard to initialization.   I tried a number of possible version #s
 for the mono_jit_init_version(), but indicated:

 WARNING: The runtime version supported by this application is
 unavailable. Using default runtime: v2.0.50727

 what is the version # one should use to correspond to .NET 4?   The
 version #s like v2.0.50727 are peculiar (but I think a MS thing).

The version number for mono_jit_init_version() can be one
of the the strings that start with v:

https://github.com/mono/mono/blob/master/mono/metadata/domain.c#L121

Robert

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] embedded mono and .NET 4.0 assemblies [peculiar error]

2011-11-04 Thread Jonathan Shore
I'm working on a mapping between R (the statistical language) and C#, so that R 
can reference and call methods in C# assemblies.  R has an implementation for 
Java and C, but lacks one for C#.

On Nov 4, 2011, at 3:44 PM, Slide wrote:

 Might I ask what you are using embedding for? I've been interested in 
 embedding mono but haven't found any project to use it on. How is it working 
 for you?
 

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-dev] Problem handling more the 1024 file handle

2011-11-04 Thread Torello Querci
Bug filled: http://bugzilla.xamarin.com/show_bug.cgi?id=1888

Sorry for the delay.


2011/11/4 Robert Jordan robe...@gmx.net:
 On 04.11.2011 13:26, Robert Jordan wrote:
 Meanwhile, you could just increase the open files limit
 with ulimit -S -H 2, so don't mark the bug as super critical ;)

 I've fat-fingered ulimit's arguments:

 ulimit -S -H -n 2

 Robert

 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


[Mono-dev] linking with lib mono-2.0 on osx (64 bit vs 32 bit)

2011-11-04 Thread Jonathan Shore
Hi,  

I am a bit fuzzy as to whether a 64 bit version of mono exists for osx.  
According to this page http://www.mono-project.com/Supported_Platforms, it 
does, or at least the JIT can generate 64 bit code.   In this regard, all of 
the mono libraries in the prebuilt 2.10.6 package are 32 bit.   Do I need to do 
a custom build to get 64 bit or is the 64 bit port not yet completely there?

I am wondering whether will get into trouble linking a 64 bit application with 
32 bit libs.  To be honest don't have experience with this on osx.  

Thanks
Jonathan ___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list


Re: [Mono-list] moon light plugin

2011-11-04 Thread Ian Norton
On Fri, Nov 04, 2011 at 08:37:38AM +, Stifu wrote:
 The Mono team no longer works on Moonlight. So until community members pick
 it up, it's dead.

Oh, crap!

I did get a short burst of work before the attachmate thing. I based moonbase
ontop of moonlight from github earlier this year.  Quite alot of the sl4 stuff
worked well. Though I must admit I was more looking at the xaml/control side of
things than in a plugin state.
 
 
 blueridge wrote:
 
  When will the moonlight plug-in be up date to support more modern sites
 
  I tried to use www.ritzpix.com the plugin does not work
 
  Chip
 
 
  ___
  Mono-list maillist  -  Mono-list@.ximian
  http://lists.ximian.com/mailman/listinfo/mono-list
 
 
 
 --
 View this message in context: 
 http://mono.1490590.n4.nabble.com/Where-does-Mono-store-user-config-setterings-tp3983422p3989331.html
 Sent from the Mono - General mailing list archive at Nabble.com.
 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] Ubuntu 11.10 configuration problem

2011-11-04 Thread Ian Norton
It could be that your program is compiled for .net 4.0 but your mono doesnt
support it.

On Fri, Nov 04, 2011 at 12:29:58AM +, Matthew Fleming wrote:
 Hi,
 
 I'm entirely new to mono so I'd really appreciate help with the following.
 I am trying to run OpenVista CIS, which is supposed to run with mono under
 Linux, on Ubuntu 11.10. I get the following errors:
 
 mfleming@mgf-desktop:~/openvista/openvistacis-0.9.96-client$
 ./OpenVistaCIS.exe
 Missing method System.Reflection.Assembly::op_Equality(Assembly,Assembly)
 in assembly /usr/lib/mono/2.0/mscorlib.dll, referenced in assembly
 /usr/lib/mono/gac/gdk-sharp/2.12.0.0__35e10195dab3c99f/gdk-sharp.dll
 ---Initial Exception---
 Method not found: 'System.Reflection.Assembly.op_Equality'.
   at Medsphere.OpenVista.CIS.OVMain.Run (System.String[] args) [0x0]
 in filename unknown:0
   at Medsphere.OpenVista.CIS.OVMain.Main (System.String[] args) [0x0]
 in filename unknown:0
 
 ---Second Exception---
 An exception was thrown by the type initializer for Nest
   at Medsphere.OpenVista.CIS.OVMain.ShowUnhandledException
 (System.Exception ex) [0x0] in filename unknown:0
 [ERROR] FATAL UNHANDLED EXCEPTION: System.MissingMethodException: Method
 not found: 'System.Reflection.Assembly.op_Equality'.
   at Medsphere.OpenVista.CIS.OVMain.Run (System.String[] args) [0x0]
 in filename unknown:0
   at Medsphere.OpenVista.CIS.OVMain.Main (System.String[] args) [0x0]
 in filename unknown:0
 
 It appears to me that this is probably a problem with the way mono is
 configured in this Ubuntu distro, but I have no idea how to fix it. Any
 assistance would be greatly appreciated.
 
 Matthew Fleming

 ___
 Mono-list maillist  -  Mono-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-list

___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


[Mono-list] Mono not catching this, VS does

2011-11-04 Thread Matt Calder
I don't know whether to call this a bug, but this code can result in an
access of the List list, without assigning to it (in the case b is false):

public static void Foo(bool b)
{
int i;
Listint list;
if (b  !dict.TryGetValue(foo, out list)) {
dict[foo] = new Listint();
} else {
i = list[0];
}

}

Visual studio flags this as a compiler error. I am using:

$ mono --version
Mono JIT compiler version 2.11 ((no/7917753 Wed Mar 30 15:47:09 EDT 2011)
Copyright (C) 2002-2011 Novell, Inc and Contributors. www.mono-project.com
TLS:   __thread
SIGSEGV:   altstack
Notifications: epoll
Architecture:  amd64
Disabled:  none
Misc:  softdebug
LLVM:  yes(2.8svn-mono)
GC:Included Boehm (with typed GC and Parallel Mark)
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list


Re: [Mono-list] Mono not catching this, VS does

2011-11-04 Thread Andres G. Aragoneses

Please file a bug report in http://bugzilla.xamarin.com/

On 11/04/2011 02:02 PM, Matt Calder wrote:
 I don't know whether to call this a bug, but this code can result in an
 access of the List list, without assigning to it (in the case b is false):

  public static void Foo(bool b)
  {
  int i;
  Listint list;
  if (b  !dict.TryGetValue(foo, out list)) {
  dict[foo] = new Listint();
  } else {
  i = list[0];
  }

  }

 Visual studio flags this as a compiler error. I am using:

 $ mono --version
 Mono JIT compiler version 2.11 ((no/7917753 Wed Mar 30 15:47:09 EDT 2011)
 Copyright (C) 2002-2011 Novell, Inc and Contributors.
 www.mono-project.com http://www.mono-project.com
  TLS:   __thread
  SIGSEGV:   altstack
  Notifications: epoll
  Architecture:  amd64
  Disabled:  none
  Misc:  softdebug
  LLVM:  yes(2.8svn-mono)
  GC:Included Boehm (with typed GC and Parallel Mark)




___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list