Re: [Mono-list] Anyone having SqlDataAdapter problems with 4.2.1?

[Rodrigo Kumpera]

Hi Sarah,

I believe you're experiencing this bug:
https://bugzilla.xamarin.com/show_bug.cgi?id=35857

We're aware of it.

--
Rodrigo


On Wed, Nov 18, 2015 at 6:13 PM, Sarah Weissman  wrote:

> I just recently downloaded 4.2.1 and I’m having problems with multiple
> .net projects that make DB queries. This all came up when I got the Xamarin
> 5.10 upgrade, which wouldn’t run on my OS, so I’m not sure what else could
> be contributing to this issue, but all of this code runs fine under 4.0.5.
> Just looking for some anecdotal evidence of issues right now.
>
> Here is the kind of errors I am seeing. This is just a call to an sql
> stored procedure and the code is pretty simple:
>
> DataSet ds = new DataSet ();
>
>
> // Issue Query
>
> using (SqlCommand sqlcmd = new
> SqlCommand(sSqlCommand, dbConn))
>
> {
>
> SqlDataAdapter sqlda = new
> SqlDataAdapter(sqlcmd);
>
>
> // Set Query Timeout
>
> sqlcmd.CommandTimeout = 900;
>
>
> // Fill the dataset
>
> sqlda.Fill(ds);
>
> }
>
>
> System.NullReferenceException: Object reference not set to an instance of
> an object
>   at System.Data.SqlClient.SqlDataReader.GetValues (System.Object[]
> values) [0x00021] in
> /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.1/mcs/class/System.Data/System.Data.SqlClient/SqlDataReader.cs:1266
>   at
> System.Data.ProviderBase.DataReaderContainer+CommonLanguageSubsetDataReader.GetValues
> (System.Object[] values) [0x0] in
> /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.1/external/referencesource/System.Data/System/Data/ProviderBase/DataReaderContainer.cs:129
>   at System.Data.ProviderBase.SchemaMapping.LoadDataRow () [0x0] in
> /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.1/external/referencesource/System.Data/System/Data/ProviderBase/SchemaMapping.cs:342
>   at System.Data.Common.DataAdapter.FillLoadDataRow
> (System.Data.ProviderBase.SchemaMapping mapping) [0x00069] in
> /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.1/external/referencesource/System.Data/System/Data/Common/DataAdapter.cs:645
>   at System.Data.Common.DataAdapter.FillFromReader (System.Data.DataSet
> dataset, System.Data.DataTable datatable, System.String srcTable,
> System.Data.ProviderBase.DataReaderContainer dataReader, Int32 startRecord,
> Int32 maxRecords, System.Data.DataColumn parentChapterColumn, System.Object
> parentChapterValue) [0x00089] in
> /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.1/external/referencesource/System.Data/System/Data/Common/DataAdapter.cs:561
>   at System.Data.Common.DataAdapter.Fill (System.Data.DataSet dataSet,
> System.String srcTable, IDataReader dataReader, Int32 startRecord, Int32
> maxRecords) [0x00093] in
> /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.1/external/referencesource/System.Data/System/Data/Common/DataAdapter.cs:442
>   at System.Data.Common.DbDataAdapter.FillInternal (System.Data.DataSet
> dataset, System.Data.DataTable[] datatables, Int32 startRecord, Int32
> maxRecords, System.String srcTable, IDbCommand command, CommandBehavior
> behavior) [0x00064] in
> /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.1/external/referencesource/System.Data/System/Data/Common/DbDataAdapter.cs:539
>   at System.Data.Common.DbDataAdapter.Fill (System.Data.DataSet dataSet,
> Int32 startRecord, Int32 maxRecords, System.String srcTable, IDbCommand
> command, CommandBehavior behavior) [0x00074] in
> /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.1/external/referencesource/System.Data/System/Data/Common/DbDataAdapter.cs:436
>   at System.Data.Common.DbDataAdapter.Fill (System.Data.DataSet dataSet)
> [0x00025] in
> /private/tmp/source-mono-mac-4.2.0-branch/bockbuild-mono-4.2.0-branch/profiles/mono-mac-xamarin/build-root/mono-4.2.1/external/referencesource/System.Data/System/Data/Common/DbDataAdapter.cs:382
>
> ___
> 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] Running profiler with mono-service

[Rodrigo Kumpera]

You say it's crashing, how exactly? Any logs, stacktraces?

On Tue, Nov 17, 2015 at 3:41 AM, john jacob  wrote:

> Hi,
> I have a mono-service which is taking a lot of CPU cycles (almost 100%)
> when ran under load. I am trying to run the mono log profiler to corner the
> issue, but couldn't do that successfully. What should be the exact command
> I should use?
>
> i tried setting the MONO_OPTIONS=--profile=log:sample in the environment
> settings , but didn't take effect and no output.mlpd file is created.
>
> My service is started with a shell script and if I export
> MONO_OPTIONS=--profile=log:sample from the shell script , then the file
> output.mlpd is created but the mono-service is crashing.
>
> mono-service -l:lock MyService.exe 1> /dev/null
>
> Mono Version : 4.0.5
> OS: CentOS 7, 64 bit
>
> Any help is appreciated.
>
> Thanks in Advance,
> John
>
> ___
> 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] [embedding] "moving from mono_runtime_invoke() to mono_method_get_unmanaged_thunk()" or "how to call class method that takes and returns a string via thunks"

[Rodrigo Kumpera]

How does it crash? Did you try debugging it?

The invocation looks ok.

On Wed, Nov 11, 2015 at 3:03 PM, Core_Code  wrote:

> hello,
>
> we are currently embedding Mono to use a C# DLL, which works fine.
>
> we are using mono_runtime_invoke() to invoke a class method and are
> obtaining the resulting object just fine.
>
> however, for performance reasons we'd like to switch to using the
> 'unmanaged
> thunks', which we did not get to work. our call differes from the example
> in
> the 'embedding mono' docs by the parameters and the fact that we are
> calling
> a class method. however we try, just different crashes.
>
>
> the function we have to call has this prototype:
> public static string ParseToJSON(string input)
>
> which seems to translate to a mono method description of
> XLParser.ExcelFormulaParser:ParseToJSON (string)
>
> we have no problem using mono_runtime_invoke() to call it exactly like
> this:
>
>
> MonoAssembly *assembly = mono_domain_assembly_open(domain,
> "/path/to/XLParser.dll");
> MonoImage *image = mono_assembly_get_image(assembly);
> MonoClass *classHandle = mono_class_from_name(image, "XLParser",
> "ExcelFormulaParser");
> const char *descAsString = "XLParser.ExcelFormulaParser:ParseToJSON
> (string)";
> MonoMethodDesc *description = mono_method_desc_new(descAsString, 0);
> method = mono_method_desc_search_in_class(description, classHandle);
> void *args[1] = {mono_string_new (domain, "A+B")};
> MonoObject *resultObject = mono_runtime_invoke(method, NULL, args, NULL);
> MonoString *resultString = mono_object_to_string(resultObject, NULL);
> char *resultCString = mono_string_to_utf8(resultString);
>
>
> now we are trying the thunk method:
>
> typedef MonoObject* (*ParseToJSON) (MonoString *obj1,MonoString *obj2);
> ParseToJSON func = mono_method_get_unmanaged_thunk(method);
> MonoString *s = mono_string_new (domain, "A+B");
> MonoObject *result = func(s,NULL);
> MonoString *resultstring = mono_object_to_string(result, NULL);
> char *str = mono_string_to_utf8(resultstring);
>
> but it crashes - any idea how to call a class method via thunks?
>
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/embedding-moving-from-mono-runtime-invoke-to-mono-method-get-unmanaged-thunk-or-how-to-call-class-me-tp4666935.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] Owin authentication: Method GetBufferlessInputStream not found

[Rodrigo Kumpera]

This method was added to master after 4.2.0 was branches.

Would you mind trying with master or 4.3.0?

--
Rodrigo

On Sun, Oct 4, 2015 at 5:18 AM, Olli Heiskanen <
ohjelmistoarkkite...@gmail.com> wrote:

>
> Hello experts,
>
> I was wondering if someone here could help me out with an Asp.Net Web API
> with owin authentication on a CentOS server with the latest mono release.
>
> I'm trying to get such a service working on mono on CentOS server, with
> apache and mod_mono. I'm using mono compiled from source, from git repo
> release mono-4.2.1.36.
>
> I've verified a working Asp.Net website without authentication in my
> CentOS environment, and on my Windows development environment I have a
> working example of an API with owin authentication using bearer tokens to
> authenticate.
>
> Problem is, when deployed to apache, when I send a http POST to the /token
> endpoint, the server returns a 200 OK, but without any response payload
> (which would include the bearer token the client needs to authenticate
> subsequent requests). Also, I get an exception (below) in the apache error
> log (note it originates from Microsoft.Owin.Host.SystemWeb). My server is
> CentOS, but I posted a question about this on stackoverflow and someone
> commented they have observed the same on Ubuntu as well. Nobody was able to
> answer my question there so perhaps here I'll find better expertise on this.
>
>
> System.MissingMethodException: Method
> 'HttpRequestBase.GetBufferlessInputStream' not found.
>   at Microsoft.Owin.Host.SystemWeb.CallStreams.InputStream.get_Stream ()
> <0xb0e339b8 + 0x00013> in :0
>   at
> Microsoft.Owin.Host.SystemWeb.CallStreams.DelegatingStream.get_CanRead ()
> <0xb0e45eb0 + 0x00013> in :0
>   at System.IO.StreamReader..ctor (System.IO.Stream stream,
> System.Text.Encoding encoding, Boolean detectEncodingFromByteOrderMarks,
> Int32 bufferSize, Boolean leaveOpen) <0xb0e5d790 + 0x0005f> in  unknown>:0
>   at (wrapper remoting-invoke-with-check) System.IO.StreamReader:.ctor
> (System.IO.Stream,System.Text.Encoding,bool,int,bool)
>   at Microsoft.Owin.OwinRequest+d__0.MoveNext ()
> <0xb0e33510 + 0x000f3> in :0
> --- End of stack trace from previous location where exception was thrown
> ---
>   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw ()
> <0xb0e34a68 + 0x0002b> in :0
>   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Threading.Tasks.Task task) <0xb0e346d0 + 0x000bb> in  unknown>:0
>   at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification
> (System.Threading.Tasks.Task task) <0xb0e34588 + 0x0007f> in  unknown>:0
>   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd
> (System.Threading.Tasks.Task task) <0xb270df98 + 0x00033> in  unknown>:0
>   at System.Runtime.CompilerServices.TaskAwaiter`1[TResult].GetResult ()
> <0xb270e1d0 + 0x00017> in :0
>   at
> Microsoft.Owin.Security.OAuth.OAuthAuthorizationServerHandler+d__22.MoveNext
> () <0xb0e2f118 + 0x00463> in :0
> --- End of stack trace from previous location where exception was thrown
> ---
>   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw ()
> <0xb0e34a68 + 0x0002b> in :0
>   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Threading.Tasks.Task task) <0xb0e346d0 + 0x000bb> in  unknown>:0
>   at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification
> (System.Threading.Tasks.Task task) <0xb0e34588 + 0x0007f> in  unknown>:0
>   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd
> (System.Threading.Tasks.Task task) <0xb270df98 + 0x00033> in  unknown>:0
>   at System.Runtime.CompilerServices.TaskAwaiter.GetResult () <0xb270df70
> + 0x00013> in :0
>   at
> Microsoft.Owin.Security.OAuth.OAuthAuthorizationServerHandler+d__0.MoveNext
> () <0xb270e790 + 0x007a7> in :0
> --- End of stack trace from previous location where exception was thrown
> ---
>   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw ()
> <0xb0e34a68 + 0x0002b> in :0
>   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Threading.Tasks.Task task) <0xb0e346d0 + 0x000bb> in  unknown>:0
>   at
> System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification
> (System.Threading.Tasks.Task task) <0xb0e34588 + 0x0007f> in  unknown>:0
>   at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd
> (System.Threading.Tasks.Task task) <0xb270df98 + 0x00033> in  unknown>:0
>   at System.Runtime.CompilerServices.TaskAwaiter`1[TResult].GetResult ()
> <0xb270f5b0 + 0x00013> in :0
>   at
> Microsoft.Owin.Security.Infrastructure.AuthenticationMiddleware`1+d__0[TOptions].MoveNext
> () <0xb270b2a0 + 0x0030f> in :0
> --- End of stack trace from previous location where exception was thrown
> ---
>   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw ()
> <0xb0e34a68 + 0x0002b> in :0
>   at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess
> (System.Threading

Re: [Mono-list] f# script got DllNotFoundException

[Rodrigo Kumpera]

It works on mono 4.0.1, just upgrade.

On Wed, May 20, 2015 at 5:56 PM, fatboy <1599023...@qq.com> wrote:

> Mono JIT compiler version 4.0.0
> OSX 10.9
>
> I wrote a F# script to grab html page
>
>
> /
>  #r "mscorlib.dll"
> #r "System.dll"
> #r "System.Core.dll"
>
> open System
> open System.IO
> open System.Net
>
> let down (uri : Uri) =
> async {
> let req = WebRequest.Create(uri)
> let! resp = req.AsyncGetResponse()
> let stream = resp.GetResponseStream()
> stream.CopyTo(Console.OpenStandardOutput())
> }
>
> let page = new Uri("http://www.fsharp.org";)
>
> down page |> Async.RunSynchronously
>
> ///
> I run it with
>
> fsharpi test.fsx
>
> ///
> and I got
>
> System.DllNotFoundException: libc.dylib
>   at (wrapper managed-to-native) System.Platform:uname (intptr)
>   at System.Platform.CheckOS () [0x0] in :0
>   at System.Platform.get_IsMacOS () [0x0] in :0
>   at System.Net.WebRequest.GetSystemWebProxy () [0x0] in  unknown>:0
>   at System.Net.WebRequest.GetDefaultWebProxy () [0x0] in  unknown>:0
>   at System.Net.WebRequest.get_DefaultWebProxy () [0x0] in  unknown>:0
>   at System.Net.GlobalProxySelection.get_Select () [0x0] in  unknown>:0
>   at System.Net.HttpWebRequest..ctor (System.Uri uri) [0x0] in
> :0
>   at (wrapper remoting-invoke-with-check) System.Net.HttpWebRequest:.ctor
> (System.Uri)
>   at System.Net.HttpRequestCreator.Create (System.Uri uri) [0x0] in
> :0
>   at System.Net.WebRequest.Create (System.Uri requestUri) [0x0] in
> :0
>   at FSI_0001+down@11.Invoke (Microsoft.FSharp.Core.Unit unitVar)
> [0x0] in :0
>   at 
> Microsoft.FSharp.Control.AsyncBuilderImpl+callA@805[Microsoft.FSharp.Core.Unit,Microsoft.FSharp.Core.Unit].Invoke
> (Microsoft.FSharp.Control.AsyncParams`1 args) [0x0] in  unknown>:0
>
>
> /
> If I create new solution change code to compile version, everything works.
> But I only want to write a script.
> Need your help ...
>
> ___
> 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] Mono GUI toolkits

[Rodrigo Kumpera]

On Mon, May 11, 2015 at 9:45 AM, Edward Ned Harvey (mono) <
edward.harvey.m...@clevertrove.com> wrote:

> > From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> > boun...@lists.ximian.com] On Behalf Of Elmar Haneke
> >
> > Gtk is an multi-platform-toolkit, you can use it on all important
> > Desktop systems: Windows, MacOS and Linux.
> >
> > The only problem is
>
> ... Let me stop you right there. Because to me, the only problem is the
> fact that GTK is not natively included with either windows, mac, or mobile
> OSes, and due to LGPL, it's very unclear if you can legally bundle it with
> your application.
>
> GTK is LGPL, not GPL. But you need a lawyer to understand if that's ok for
> you, because the GPL itself is one long-ass license, and the "Lesser" part
> almost doubles its length. It's not an attractive license, like MIT.
>

Those small details have not stopped xamarin to ship Xamarin Studio on
Windows and Mac use gtk+. And the open source counter-part, MonoDevelop,
runs fine on all 3.

The problem of cross platform toolkits is that they either look like ass
everywhere or they look great on one target and crazy horrible on others.
See Java and Swing for evidence of this.

At Xamarin, in order to make Xamarin Studio great, we had to drop parts of
gtk+ and replace with the native toolkit.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Problems with mono log pofiler

[Rodrigo Kumpera]

Try disabling counters too, they can produce quite a lot data

On Thu, Mar 5, 2015 at 5:08 AM, Grzegorz Sobański  wrote:

> Hi,
>
> We are looking for a source of memory leak in our app. Unfortunately we
> have problems with stability when using mono profiler.
> After running the app for about 5 minutes with the profiler enabled, it
> stops answering requests, don't crash, but just stops working. (Without
> profiling it will run for hours).
>
> So I have few questions:
> 1. Is this some known problem with stability while profiling?
> 2. Even when launched as:
>   mono --gc=sgen --profile=log:heapshot,heapshot=ondemand program.exe
> profiler still generates around 50MB/min output (specifying
> noalloc,nocalls does not change it).
> Is it possible to launch profiler in mode heapshot=ondemand with
> everything else disabled? I would in effect like to minimize profiler
> impact, preferably to zero in normal run, and only do two heap snapshots
> (at start and after an hour).
>
> Running on mono 3.12, Ubuntu 14.04.
>
> Best regards
>
> --
> Grzegorz
> ___
> 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] [Mono-dev] Mono release headsup

[Rodrigo Kumpera]

Miguel merged a fix for that. I just cherry picked it to 4.0.



On Tue, Feb 24, 2015 at 12:26 PM, Ariel Rocholl 
wrote:

> Great – hopefully he is still around and can answer. Otherwise which
> option B can work? Can I do a minor modification and re-submit as myself
> fix?
>
> Or alternatively, at least add 25 and 50 which are IoT common
> baudrates not currently included?
>
>
>
> Best Regards,
> 
> Ariel Rocholl
>
>
>
> *From:* Rodrigo Kumpera [mailto:kump...@gmail.com]
> *Sent:* Tuesday, February 24, 2015 16:30
> *To:* Ariel Rocholl
> *Cc:* mono-devel-l...@lists.ximian.com; Mono List
> *Subject:* Re: [Mono-dev] Mono release headsup
>
>
>
> The patch looks ok, but for it to be merge it must be released under the
> MIT license, so the author will have to do it.
>
>
>
>
>
>
>
> On Tue, Feb 24, 2015 at 4:52 AM, Ariel Rocholl 
> wrote:
>
> Hi there,
>
>
>
> Could the fix proposed for bug #8207 be considered for the release? This
> was proposed long ago but didn't progress, and recent renewed interest on
> high speed custom baud serial communication is required by all IoT gadgets
> and sort. We are not being able to propose Mono for IoT just because of
> this, and fix seems really easy to propagate.
>
>
> Best Regards,
> 
> Ariel Rocholl
>
>
>
> On Tue, Feb 24, 2015 at 1:08 AM, Rodrigo Kumpera 
> wrote:
>
> Hello everyone,
>
>
>
> We're branching mono for next release as we speak.
>
>
>
> We'll be able to easily merge community PR until March 6. After that it
> will have to go through our
>
> internal QA process, which raises the bar a lot and only release blockers
> can get in.
>
>
>
> I'll be handling the intake of community changes for the release so make
> sure I'm aware of any PR targeting it to increase their likelihood of been
> included.
>
>
>
> --
>
> Rodrigo
>
>
>
> ___
> Mono-devel-list mailing list
> mono-devel-l...@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] [Mono-dev] Mono release headsup

[Rodrigo Kumpera]

There's a PR that fixes the same issue using different ioctl. I can't make
a call on which approach is the appropriate one
since I'm not familiar with serial comm.


On Tue, Feb 24, 2015 at 12:26 PM, Ariel Rocholl 
wrote:

> Great – hopefully he is still around and can answer. Otherwise which
> option B can work? Can I do a minor modification and re-submit as myself
> fix?
>
> Or alternatively, at least add 25 and 50 which are IoT common
> baudrates not currently included?
>
>
>
> Best Regards,
> 
> Ariel Rocholl
>
>
>
> *From:* Rodrigo Kumpera [mailto:kump...@gmail.com]
> *Sent:* Tuesday, February 24, 2015 16:30
> *To:* Ariel Rocholl
> *Cc:* mono-devel-l...@lists.ximian.com; Mono List
> *Subject:* Re: [Mono-dev] Mono release headsup
>
>
>
> The patch looks ok, but for it to be merge it must be released under the
> MIT license, so the author will have to do it.
>
>
>
>
>
>
>
> On Tue, Feb 24, 2015 at 4:52 AM, Ariel Rocholl 
> wrote:
>
> Hi there,
>
>
>
> Could the fix proposed for bug #8207 be considered for the release? This
> was proposed long ago but didn't progress, and recent renewed interest on
> high speed custom baud serial communication is required by all IoT gadgets
> and sort. We are not being able to propose Mono for IoT just because of
> this, and fix seems really easy to propagate.
>
>
> Best Regards,
> 
> Ariel Rocholl
>
>
>
> On Tue, Feb 24, 2015 at 1:08 AM, Rodrigo Kumpera 
> wrote:
>
> Hello everyone,
>
>
>
> We're branching mono for next release as we speak.
>
>
>
> We'll be able to easily merge community PR until March 6. After that it
> will have to go through our
>
> internal QA process, which raises the bar a lot and only release blockers
> can get in.
>
>
>
> I'll be handling the intake of community changes for the release so make
> sure I'm aware of any PR targeting it to increase their likelihood of been
> included.
>
>
>
> --
>
> Rodrigo
>
>
>
> ___
> Mono-devel-list mailing list
> mono-devel-l...@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
>
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] [Mono-dev] Mono release headsup

[Rodrigo Kumpera]

The patch looks ok, but for it to be merge it must be released under the
MIT license, so the author will have to do it.



On Tue, Feb 24, 2015 at 4:52 AM, Ariel Rocholl  wrote:

> Hi there,
>
> Could the fix proposed for bug #8207 be considered for the release? This
> was proposed long ago but didn't progress, and recent renewed interest on
> high speed custom baud serial communication is required by all IoT gadgets
> and sort. We are not being able to propose Mono for IoT just because of
> this, and fix seems really easy to propagate.
>
> Best Regards,
> 
> Ariel Rocholl
>
>
>
> On Tue, Feb 24, 2015 at 1:08 AM, Rodrigo Kumpera 
> wrote:
>
>> Hello everyone,
>>
>> We're branching mono for next release as we speak.
>>
>> We'll be able to easily merge community PR until March 6. After that it
>> will have to go through our
>> internal QA process, which raises the bar a lot and only release blockers
>> can get in.
>>
>> I'll be handling the intake of community changes for the release so make
>> sure I'm aware of any PR targeting it to increase their likelihood of been
>> included.
>>
>> --
>> Rodrigo
>>
>> ___
>> Mono-devel-list mailing list
>> mono-devel-l...@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
>>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

[Mono-list] Mono release headsup

[Rodrigo Kumpera]

Hello everyone,

We're branching mono for next release as we speak.

We'll be able to easily merge community PR until March 6. After that it
will have to go through our
internal QA process, which raises the bar a lot and only release blockers
can get in.

I'll be handling the intake of community changes for the release so make
sure I'm aware of any PR targeting it to increase their likelihood of been
included.

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

Re: [Mono-list] Fasycopy in Mono

[Rodrigo Kumpera]

Mono 2.4 is incredibly old, you should update to 3.14 first.

On Sat, Feb 21, 2015 at 10:23 PM, AniTa Wang 
wrote:

> Hi,
>
> I am doing an experiment to measure the performance improvement of
> Fasycopy function in Mono. The version I am testing is Mono 2.4. However, I
> have some difficulties in finding applications that use the Fastcopy
> function. Can anyone give me some guidance on how to trigger this function,
> or send me some programs that uses Fastcopy? Thanks in advance.
>
> Best,
> Cindy
>
> ___
> 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] Building from latest master failing

[Rodrigo Kumpera]

Run your build with V=1 this should produce enough debug spew to
troubleshoot it.

What is your build host?

On Sat, Dec 6, 2014 at 10:43 AM, Edward Ned Harvey (mono) <
edward.harvey.m...@clevertrove.com> wrote:

> > From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> > boun...@lists.ximian.com] On Behalf Of Matt Calder
> >
> > I regularly build mono from github. Today, the build is hanging (30
> minutes +)
> > on:
> >
> > MCS [net_4_0] System.Runtime.Serialization.Formatters.Soap.dll
> > Can someone suggest a way to either disable this part of the build or
> figure
> > out what may be the problem? Thank you,
>
> If you don't get a successful answer here, try the dev list.
>
> Also, if you haven't already, do a "make clean" and try again.
> ___
> 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] Problem with sgen

[Rodrigo Kumpera]

On Fri, Nov 21, 2014 at 9:22 PM, terender  wrote:

>
> But why there will be an invalid read/write right after that and crash the
> process?
>

That's how GCs work.


I'm using a native library (libuv) that directly read and write into the
> memory of the pinned object, when run under valgrind, any r/w opration
> fails
> and cause an error.
>


Maybe you're not pinning correctly. It would help if you posted a program
that shows the issue.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Problem with sgen

[Rodrigo Kumpera]

That's a false positive. sgen conservatively scans the stack and this does
trip valgrind.

On Fri, Nov 21, 2014 at 10:29 AM, terender  wrote:

> There is a memory problem with mono-sgen on linux. I'm using some pinned
> byte[] buffers in my project, and there's a randomly crash with signal
> SIGSEGV, it could happen anywhere at anytime.
>
> I guess there's some write oprations out of bound in memory, so I use
> valgrind to check the program.
>
> Then I found that a while after the program start within some alloc
> oprations, valgrind report a problem in sgen that is:
>
> ==6504== Thread 1:
> ==6504== Conditional jump or move depends on uninitialised value(s)
> ==6504==at 0x5C4D46: conservatively_pin_objects_from (sgen-gc.c:1200)
> ==6504==by 0x5C5322: scan_thread_data (sgen-gc.c:3778)
> ==6504==by 0x5CA7BA: collect_nursery (sgen-gc.c:2298)
> ==6504==by 0x5CB877: sgen_perform_collection (sgen-gc.c:3196)
> ==6504==by 0x5E8CCF: mono_gc_alloc_obj_nolock (sgen-alloc.c:315)
> ==6504==by 0x5E90E3: mono_gc_alloc_obj (sgen-alloc.c:491)
> ==6504==by 0x40C09E2: ???
> ==6504==by 0x4198331: ???
> ==6504==by 0x40BBF42: ???
> ==6504==by 0x41DE33: mono_jit_runtime_invoke (mini.c:6738)
> ==6504==by 0x5A252A: mono_runtime_invoke (object.c:2831)
> ==6504==by 0x5A5DCF: mono_runtime_exec_main (object.c:4096)
> ==6504==  Uninitialised value was created by a stack allocation
> ==6504==at 0x57D2E0: start_wrapper (threads.c:701)
>
>
> Any read or write oprations right after that would trigger an Invalid
> write/read error in valgrind and then process got killed.
>
> Is that a bug in sgen collect_nursery with pinned objects in nursery heap?
>
> I have checked on both mono 3.2.3 and 3.10.0,  and I'm using tarball to
> compile them myself.
> The enviroment is CentOS 6.6  Kernal 2.6.32-358.6.2.el6.x86_64, GCC version
> 4.4.7
>
> I could upload the whole log of valgrind for both mono 3.2.3 and 3.10.0 if
> needed.
>
>
> Btw: the problem does not happen if I use boehm
>
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Problem-with-sgen-tp4664753.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] Mono x OSGI.NET

[Rodrigo Kumpera]

This looks like either a compiler or runtime bug, please file a bug report
for it.

On Tue, Nov 11, 2014 at 1:54 PM, Christian Dorner <
christian.dor...@gmail.com> wrote:

> I getting the fallowing exception when I try to instantiate BundleRuntime.
> I alread run the same on windows and works fine.
>
>
> System.InvalidProgramException: Invalid IL code in
> UIShell.OSGi.BundleRuntime:.ctor (): IL_0005: pop
>   at OSGi.NET.HelloWorld.Program.Main (System.String[] args) [0x1] in
> /home/cdorner/workspace/OSGi.NET.HelloWorld/Program.cs:14
>
>
> 2014-11-11 16:03 GMT-02:00 Rodrigo Kumpera :
>
> Hi Christian,
>>
>> When you say it doesn't work, what do you mean by that?
>>
>>
>> --
>> Rodrigo
>>
>>
>>
>>
>> On Tue, Nov 11, 2014 at 12:34 PM, Christian Dorner <
>> christian.dor...@gmail.com> wrote:
>>
>>> Hi is Mono compatible with OSGI.NET (http://osgi.codeplex.com/) ?
>>>
>>> I try run this simple example and doesn't work --
>>> http://osgi.codeplex.com/wikipage?title=Hello%20World%21
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://mono.1490590.n4.nabble.com/Mono-x-OSGI-NET-tp4664547.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] Mono x OSGI.NET

[Rodrigo Kumpera]

Hi Christian,

When you say it doesn't work, what do you mean by that?


--
Rodrigo




On Tue, Nov 11, 2014 at 12:34 PM, Christian Dorner <
christian.dor...@gmail.com> wrote:

> Hi is Mono compatible with OSGI.NET (http://osgi.codeplex.com/) ?
>
> I try run this simple example and doesn't work --
> http://osgi.codeplex.com/wikipage?title=Hello%20World%21
>
>
> Thanks
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Mono-x-OSGI-NET-tp4664547.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] DataContractSerializer dictionaries element names

[Rodrigo Kumpera]

Could you file a bug report with a test case?

On Thu, Sep 18, 2014 at 5:28 AM, gbenrais  wrote:

> Hello,
> I have an issue when datacontractserializing dictionaries with mono. The
> serializer names differently the elements corresponding to dictionaries.
> Serialization program
>
> /Dictionary persons = new Dictionary();
> persons[1] = new Person("John");
> persons[2] = new Person("Bob");
> string xml = GetXmlFromData(persons);
> persons = GetModelFromXml(xml);
> static string GetXmlFromData (object data)
> {
>   StringWriter sw = new StringWriter ();
>   XmlTextWriter xw = new XmlTextWriter (sw);
>   DataContractSerializer serializer = new
> DataContractSerializer(typeof(Dictionary));
>   serializer.WriteObject (xw, data);
>   xw.Close ();
>   sw.Close ();
>   return sw.ToString();
> }/
> .Net xml
>
> / xmlns:i="http://www.w3.org/2001/XMLSchema-instance";
> xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays
> "><*KeyValueOfintPerson7l_PWQ7_Pn*>1 xmlns:d3p1="http://schemas.datacontract.org/2004/07/Serialization
> ">John2 xmlns:d3p1="http://schemas.datacontract.org/2004/07/Serialization
> ">Bob/
> Mono xml
>
> / xmlns:i="http://www.w3.org/2001/XMLSchema-instance";
> xmlns="http://schemas.microsoft.com/2003/10/Serialization/Arrays
> "><*KeyValueOfintPerson*>1<_name
> xmlns="http://schemas.datacontract.org/2004/07/Serialization
> ">John2<_name
> xmlns="http://schemas.datacontract.org/2004/07/Serialization
> ">Bob/
>
> As we can see, we get different names (KeyValueOfintPerson7l_PWQ7_Pn vs
> KeyValueOfintPerson). And the program run with mono fails when it reads the
> xml from a file output by a program run with .Net.
>
> Thank you for your help,
> Ghislain
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/DataContractSerializer-dictionaries-element-names-tp4663929.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] Xamarin homepage - is that a juicer?

[Rodrigo Kumpera]

That's a picture of the Xamarin San Francisco office and maybe they like
their lemonade freshly squeezed.




On Mon, Sep 15, 2014 at 5:00 AM, Peter Robinson  wrote:

> On the picture on the Xamarin homepage, there appears to be a large silver
> lemon juicer. Why?
>
> ___
> 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] Is Task available in Mono 3.8.1?

[Rodrigo Kumpera]

Sounds like a bug. Task has been available for 4 years now.

Could you file a bug report with a test case?

--
Rodrigo


On Wed, Sep 3, 2014 at 11:38 AM, Wayne Douglas  wrote:

> I am getting the following when trying to compile my sln against 3.8.1:
>
>  The type or namespace name `Task' could not be found. Are you missing an
> assembly reference?
>
> Is this expected?
>
> --
> **
>
> *w://*
>
> *t: 07508 215 459*
>
> **
>
>
> ___
> 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] Embedded API: monoObject keying

[Rodrigo Kumpera]

You can implement use a hashtable keyed on MonoObject with mono_object_hash
and direct equality.



On Tue, Aug 26, 2014 at 6:58 AM, Jonathan Mitchell 
wrote:

>
> I wrap monoObject instances in a corresponding Objective-C instance.
> In general I want to maintain a a 1 to 1 relationship between any given
> managed object and its unmanaged Obj-C representation.
>
> I use mono_gchandle_new() and mono_gchandle_get_target() to access the
> unpinned managed objects.
>
> When a receive a monoObject in my unmanaged code, as the sender say of an
> event, I iterate over a global collection of all my obj-C representations
> calling mono_gchandle_get_target for each in order to check for monoObject
> equality.
>
> Is this the best I can do?
>
> I could use gchandle as a hash key but as far as I can tell there is no
> function that associates a given monoObject * with one or more gchandles.
>
> Thanks
>
> Jonathan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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] Thread Crashes

[Rodrigo Kumpera]

You can by installing gdb on the machine.


On Mon, Aug 18, 2014 at 1:15 PM, Stefan Bühlmann 
wrote:

> I do not have a native backtrace but:
>
>
> * Assertion at wait.c:230, condition `thr_ret == 0' not met
>
> Stacktrace:
>
>   at  <0x>
>   at (wrapper managed-to-native) System.Threading.Thread.Thread_internal
> (System.Threading.Thread,System.MulticastDelegate) <0x>
>   at System.Threading.Thread.Start () <0x001a7>
>   at test.MainClass.Main (string[]) <0x00199>
>   at (wrapper runtime-invoke) .runtime_invoke_void_object
> (object,intptr,intptr,intptr) <0x>
>
> =
> Got a SIGABRT while executing native code. This usually indicates
> a fatal error in the mono runtime or one of the native libraries
> used by your application.
> =
>
> Code to reproduce:
>
> http://pastebin.com/ie7ZcXkT
>
> Mono Version:
>
> Mono JIT compiler version 3.4.0 (tarball Thu Jun 12 20:16:37 CEST 2014)
> Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
> www.mono-project.com
> TLS:   __thread
> SIGSEGV:   altstack
> Notification:  kqueue
> Architecture:  amd64
> Disabled:  none
> Misc:      softdebug
> LLVM:  supported, not enabled.
> GC:sgen
>
> -- Stefan
>
> On 18.08.2014 18:12, Rodrigo Kumpera wrote:
> > Can you produce the native backtrace by installing gdb.
> >
> >
> > On Thu, Aug 14, 2014 at 8:20 AM, Stefan Bühlmann
> > mailto:stefan.buehlm...@gmx.net>> wrote:
> >
> > Hello,
> >
> > we have a large batch processing application we run on Ubuntu and
> > FreeBSD. On FreeBSD we get the following crashes very often (~1x per
> > day) on Ubuntu nearly never (1x per month):
> >
> >   at  <0x>
> >   at (wrapper managed-to-native)
> > System.Threading.Thread.Thread_internal
> > (System.Threading.Thread,System.MulticastDelegate) <0x>
> >   |
> >   at System.Threading.Thread.Start () <0x001a7>
> >
> >|
> >   at ourcode <0x001ba>
> >
> > I already tested a lot however I found nothing which helped so far.
> >
> > Kind Regards
> >
> > Stefan
> > ___
> > Mono-list maillist  -  Mono-list@lists.ximian.com
> > <mailto: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] Thread Crashes

[Rodrigo Kumpera]

Can you produce the native backtrace by installing gdb.


On Thu, Aug 14, 2014 at 8:20 AM, Stefan Bühlmann 
wrote:

> Hello,
>
> we have a large batch processing application we run on Ubuntu and
> FreeBSD. On FreeBSD we get the following crashes very often (~1x per
> day) on Ubuntu nearly never (1x per month):
>
>   at  <0x>
>   at (wrapper managed-to-native) System.Threading.Thread.Thread_internal
> (System.Threading.Thread,System.MulticastDelegate) <0x>
> |
>   at System.Threading.Thread.Start () <0x001a7>
>
>  |
>   at ourcode <0x001ba>
>
> I already tested a lot however I found nothing which helped so far.
>
> Kind Regards
>
> Stefan
> ___
> 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] MemoryMappedFile not supported?

[Rodrigo Kumpera]

Our MemoryMappedFile implementation has quite a few bugs on 3.4.0 that were
addressed on 3.6.0.

The one thing left that we have no plans to support at this time are
cross-process named mappings.

--
Rodrigo


On Fri, Jul 18, 2014 at 4:01 PM, Michael McGlothlin <
mike.mcgloth...@gmail.com> wrote:

> I'm experimenting with writing a local service that I need to be
> reasonably fast. I'd like it to work on Windows, Mac OS, and Linux at
> least. I've never written a service in C# but the first thing I tried for
> IPC was using memory mapped files. Immediately I got a complaint that what
> I was doing wasn't supported under Mono because it didn't jive with Unix..
> so I switched to creating from a file (as the previous error message told
> me to do) but it seems if the file exists it dies with an error about the
> file already existing and if the file doesn't already exist it dies with an
> error that the file doesn't exist.
>
> Is this just plain not the right way to make a fast local service in C#?
> I'd be ok with using pipes or IPC sockets if it is a better idea but in
> Googling it seemed that C# had made these rely on networking for some
> reason.
>
>
> 📱 Michael McGlothlin
>
> ___
> 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] Mono no longer supported on SPARC?

[Rodrigo Kumpera]

SPARC is not dead, it just lacks a maintainer. Would you volunteer to do so?

--
Rodrigo


On Sun, Jun 29, 2014 at 3:33 PM, cocowalla 
wrote:

> Is SPARC not supported by Mono any more?
>
> I finally got the 3.4.0 runtime to build (many thanks to Steve Hall!), but
> when I try to run anything with it, I get:
>
> Assertion: should not be reached at method-to-ir.c:2566
>
> Now, that is in this method:
>
> static void
> set_rgctx_arg (MonoCompile *cfg, MonoCallInst *call, int rgctx_reg, MonoInst 
> *rgctx_arg)
> {
> #ifdef MONO_ARCH_RGCTX_REG
>   mono_call_inst_add_outarg_reg (cfg, call, rgctx_reg, 
> MONO_ARCH_RGCTX_REG, FALSE);
>   cfg->uses_rgctx_reg = TRUE;
>   call->rgctx_reg = TRUE;
> #ifdef ENABLE_LLVM
>   call->rgctx_arg_reg = rgctx_reg;
> #endif
> #else
>   NOT_IMPLEMENTED;
> #endif
> } 
>
> mono/mini/mini-sparc.h does not define *MONO_ARCH_RGCTX_REG*... so we
> can't use JIT. But it also doesn't define *MONO_ARCH_LLVM_SUPPORTED*...
> so we can't use LLVM either!
>
> Am I missing something obvious here, or is support for SPARC dead?
>
> --
> View this message in context: Mono no longer supported on SPARC?
> 
> 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] Null task exception when doing ContinueWith

[Rodrigo Kumpera]

Can you provide with a test case that shows this behavior? If so, please
file a bug report.


On Fri, May 2, 2014 at 7:17 AM, Giuliano Barberi wrote:

> Hey guys I'm seeing something strange. It could totally be user error but
> I can't seem to figure it out.
>
> I am doing this on some tasks that I never await in order to get the
> exception:
> public static Task CatchUnhandledException(this Task task)
> {
> return task.ContinueWith(continuation =>
>
> Engine.UnhandledExceptionHandler(continuation.Exception),
>   TaskContinuationOptions.ExecuteSynchronously
> | TaskContinuationOptions.OnlyOnFaulted);
> }
>
> and the Engine.UnhandledExceptionHandler just logs the exception.
>
> What's strange is that the exception is null and also doing
> an Environment.StackTrace in the handler also yields nothing. I do have
> --debug with the mdb files so I would suspect to get the full stacktrace. I
> never saw this issue when I was running on .NET runtime but I also have
> added more async code since so I'm not sure if it's something with Mono or
> my app. I just can't find anything online and the documentation for Tasks
> says that if it's faulted state there will be an exception.
>
> Regards
> --
> Giuliano Barberi
>
> ___
> 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] Embedded API: MonoObject equality

[Rodrigo Kumpera]

On Thu, Mar 20, 2014 at 6:46 PM, jonat...@mugginsoft.com <
jonat...@mugginsoft.com> wrote:

>
> On 20 Mar 2014, at 22:43, Jonathan Lima  wrote:
>
> > AFAIK MonoObject is the pointer to the object in the heap, so you just
> have to compare the pointers.
> >
> > Jonathan
> >
> I think that if the MonoObject instance isn't pinned then there is no
> guarantee that successive unmanaged pointers to a managed object will have
> the same value.
>

MonoObject pointers are what we call a raw/naked pointer. They must be
transient and never escape the C stack. You can compare them by value.

If you need a persistent pointer, use gchandled and to compare them, fetch
their values and compare those.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Embedded API. Numeric Boxing and GC

[Rodrigo Kumpera]

On Wed, Feb 26, 2014 at 12:58 PM, jonat...@mugginsoft.com <
jonat...@mugginsoft.com> wrote:

> On 26 Feb 2014, at 16:15, Rodrigo Kumpera  wrote:
>
> > This code is wrong, it will fail when the object is moved since the
> gchandle is not pinning the target.
> >
> > Avoid pinning as much as possible since it does hurt performance a lot.
> >
> > The solution is to remove the monoObject field and use
> mono_gchandle_get_target against the GC handle.
> >
> Presumably objects are pinned by default when they appear in the stack.
> Yes?
>

Only in the C stack, but as soon as your (void)box:(long long)value method
finishes executing, no stack references
will be left.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Embedded API. Numeric Boxing and GC

[Rodrigo Kumpera]

This code is wrong, it will fail when the object is moved since the
gchandle is not pinning the target.

Avoid pinning as much as possible since it does hurt performance a lot.

The solution is to remove the monoObject field and
use mono_gchandle_get_target against the GC handle.


On Tue, Feb 25, 2014 at 5:20 AM, jonat...@mugginsoft.com <
jonat...@mugginsoft.com> wrote:

> I box my numeric primitives using a macro:
>
> #define DB_BOX_INT64( x ) ( mono_value_box(mono_domain_get(),
> mono_get_int64_class(), &x) )
>
>
> And use it like so:
>
> 1.
>
> - (void)box
> {
> MonoObject *monoObject = DB_BOX_INT64(value);
> }
>
> I save the MonoObject * into a local variable. The collector will see the
> object on the stack and collect it only when the enclosing function
> completes.
>
> 2.
> - (void)box:(long long)value
> {
> self.monoObject = DB_BOX_INT64(value);
> self.gcHandle = mono_gchandle_new(self.monoObject, FALSE);
> }
>
> - (void)dealloc
> {
> mono_gchandle_free(self.gcHandle);
> }
>
> I save the MonoObject * into an instance variable. The collector will free
> the MonoObject after the call to mono_gchandle_free().
>
> Is the above correct?
>
> Regards
>
> Jonathan
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> 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] Mono crashes with Stacktrace

[Rodrigo Kumpera]

Please install gdb and get a complete crash dump.
Filling a bug with a test case would be even better.


On Wed, Feb 5, 2014 at 5:24 AM, bar  wrote:

> Also, I can confirm this happens also on git version.
>
> Stack:
> Stacktrace:
>
>
> Native stacktrace:
>
> mono() [0x4ad1e6]
> mono() [0x504d3f]
> mono() [0x420807]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f7ce53bccb0]
> mono(mono_array_length+0) [0x5b03c0]
> mono() [0x579372]
> mono() [0x58aef0]
> mono() [0x586093]
> mono() [0x6299c6]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f7ce53b4e9a]
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f7ce50e13fd]
>
> Debug info from gdb:
>
>
> =
> Got a SIGSEGV while executing native code. This usually indicates
> a fatal error in the mono runtime or one of the native libraries
> used by your application.
> =
>
> Mono -V:
>
> mono -V
> Mono JIT compiler version 3.2.7 (master/1dd3e5b Wed Feb  5 05:14:53 EST
> 2014)
> Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
> www.mono-project.com
> TLS:   __thread
> SIGSEGV:   altstack
> Notifications: epoll
> Architecture:  amd64
> Disabled:  none
> Misc:  softdebug
> LLVM:  supported, not enabled.
> GC:sgen
>
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Mono-crashes-with-Stacktrace-tp4661853p4661854.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] minimum requirements to compile mono

[Rodrigo Kumpera]

Mono doesn't support old versions linux. You should try to use a mono from
around 2008-2009.


On Thu, Jan 16, 2014 at 1:35 PM, Rafael Mueller wrote:

> Hi,
>
> I'm trying to compile mono 2.10 on a old linux (RedHat 9.0 from 2003) and
> I'm getting some compile errors, like G_MAXINT32 undeclared or undefined
> reference to g_strv_length.
>
> I can't install mono 3 either, since this linux version lacks of support
> for recursive mutexes - PTHREAD_MUTEX_RECURSIVE (the error is thrown on
> ./configure)
>
> So my question is what's the minimum version of glib and glibc required to
> build mono?
>
> Theres' also a minimum required kernel version?
>
> Best regards,
> Rafael
>
> ___
> 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] Large object heap size threshold

[Rodrigo Kumpera]

On Wed, Jan 15, 2014 at 7:00 AM, Matt Calder  wrote:

> Rodrigo,
>
> Thanks for the quick response. Following your suggestion, in sgen-conf.h I
> see:
>
> /*
>  * Objects bigger then this go into the large object space.  This size
>  * has a few constraints.  It must fit into the major heap, which in
>  * the case of the copying collector means that it must fit into a
>  * pinned chunk.  It must also play well with the GC descriptors, some
>  * of which (DESC_TYPE_RUN_LENGTH, DESC_TYPE_SMALL_BITMAP) encode the
>  * object size.
>  */
> #define SGEN_MAX_SMALL_OBJ_SIZE 8000
>
> I am wondering what is the size of a pinned chunk? Also what does "play
> well" entail? Perhaps more to the point, if I set that number to say:
>

Ignore that, the copying collection is gone and we did not update it.


> #define SGEN_MAX_SMALL_OBJ_SIZE 64000
>
> do I run afoul of any constraints? Thanks for answering this,
>

Yes, you'd have to adjust the major collector to support objects that big.
In that case it's the block size that must be extended to
be bigger than that. See MS_BLOCK_SIZE/MS_BLOCK_SIZE_SHIFT in
sgen-marksweep.c.


By "play well" we mean that it does produce empirically good results.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Large object heap size threshold

[Rodrigo Kumpera]

For sgen it's 8000 and it's configurable at the source level. See
sgen-conf.h


On Tue, Jan 14, 2014 at 5:11 PM, Matt Calder  wrote:

> It is my understanding that the large object heap is where allocations are
> made for objects larger than 4K. Is that correct and is it possible to
> configure that threshold to be larger? Thanks,
>
> Matt
>
> ___
> 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] Why doesn't Mono include full stack trace information into exception?

[Rodrigo Kumpera]

This is due to inlining. Run your program with -O=-inline and you'll get
what you want.


On Sun, Dec 29, 2013 at 11:16 PM, Andrei Faber wrote:

> Why doesn't Mono include full stack trace information into exception?
> For example, this code:
>
> class Program
> {
> static void Main(string[] args)
> {
> try
> {
> Foo();
> }
> catch (Exception exc)
> {
> Console.WriteLine(exc);
> }
> }
>
> static void Foo()
> {
> Bar();
> }
>
> static void Bar()
> {
> throw new ApplicationException();
> }
> }
>
> In MS .NET, it produces this output:
>
> System.ApplicationException: Error in the application.
>at ConsoleApplication2.Program.Bar()
>at ConsoleApplication2.Program.Foo()
>at ConsoleApplication2.Program.Main(String[] args)
>
> While in Mono:
>
> System.ApplicationException: An application exception has occurred.
>   at ConsoleApplication2.Program.Main (System.String[] args) [0x0] in
> :0
>
> --
> Best wishes,
> Andrei Faber
>
> ___
> 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] Size of thread in Mono (65MB per thread ?)

[Rodrigo Kumpera]

This sounds like a problem in your environment.

Mono, by default, creates threads with the default size of its environment.
If your setup uses 64mb stacks, that's on you.

What mono does in addition to pthread_create is to mprotect the last few
pages of the stack to implement a soft guard against stack overflow.

How much memory each pthread_create adds in your setup?



On Thu, Dec 19, 2013 at 5:09 AM, Nicolas Antoniazzi <
nicolas.antonia...@gmail.com> wrote:

> Hi,
>
> I am using Mono in a virtualized environment with 512MB of RAM.
> I made a very simple program which starts 10 threads in a loop and
> apparently, every time that I start a new thread, approximately 65MB of
> memory is used.
>
> In my case, I can run 5 threads, but for the 6th, the program crashes
> (without any exception). 150MB are already consumed without the use of any
> thread.
>
> Is it a normal behavior?
>
> Thanks!
>
> --
> Nicolas Antoniazzi
>
> ___
> 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] Mono with llvm and profiler

[Rodrigo Kumpera]

Hard to tell, maybe llvm is not been used at all, make mono dump the
compile method and check if they are the same.


On Fri, Dec 13, 2013 at 3:42 PM, xplicit  wrote:

> I filled the bug for profiling.
> https://bugzilla.xamarin.com/show_bug.cgi?id=16785
>
> About benchmarking:
> I did exactly the same test, but with smaller string (14 chars length).
> I've
> got your snippet and run it. Results are same with --llvm and without. What
> am I missing?
>
> //copied your code to test2.cs
> dmcs -optimize+ test2.cs
>
> //then run it
> $ /usr/bin/mono-sgen ./test2.exe
> It took 3259ms
> $ /usr/bin/mono-sgen ./test2.exe
> It took 3237ms
> $ /usr/bin/mono-sgen --llvm ./test2.exe
> It took 3236ms
> $ /usr/bin/mono-sgen --llvm ./test2.exe
> It took 3248ms
>
>
> Mono Runtime Engine version 3.2.7 (master/01b7a50 Sat Dec 14 01:48:49 NOVT
> 2013)
> Copyright (C) 2002-2013 Novell, Inc, Xamarin Inc and Contributors.
> www.mono-project.com
> TLS:   __thread
> SIGSEGV:   altstack
> Notifications: epoll
> Architecture:  x86
> Disabled:  none
> Misc:  softdebug
> LLVM:  yes(3.4svn-mono-mono/e656cac)
> GC:sgen
>
> OS: Ubuntu linux 32 bit.
>
> llvm configured with these options:
> ./configure --prefix=/usr --enable-optimized --enable-targets="x86"
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Mono-with-llvm-and-profiler-tp4661504p4661539.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] "Too many root sets" ?

[Rodrigo Kumpera]

Thread.Abort is a sure path to data corruption and crashes. The vast
majority of code out here is not ready to handle async exceptions.
It's fine to use Thread.Abort on an AppDomain you intend to unload right
away, but that's pretty much it.


On Mon, Dec 16, 2013 at 9:40 PM, Edward Ned Harvey (mono) <
edward.harvey.m...@clevertrove.com> wrote:

> > From: mono-list-boun...@lists.ximian.com [mailto:mono-list-
> > boun...@lists.ximian.com] On Behalf Of mickeyf
> >
> > Thread.Abort is now considered a no-no. What is the best practice to
> > correctly dispose of threads that have outlived their usefulness?
>
> For most purposes, I would say you should be using ThreadPool.  Are you?
>  Or do you have a good reason not to?
> ___
> 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] Mono with llvm and profiler

[Rodrigo Kumpera]

I believe you're not measuring it correctly. A trivial String::GetHashCode
benchmark[1] shows llvm been 22% faster. This is with a recent mono.


[1]https://gist.github.com/kumpera/7947579


On Fri, Dec 13, 2013 at 11:52 AM, Rodrigo Kumpera  wrote:

> Can you file a bug on profiling with llvm enabled? It's supposed to work.
>
>
> On Wed, Dec 11, 2013 at 8:47 AM, xplicit  wrote:
>
>> Is there a way to run mono profiler when mono compiled with llvm support?
>> When I run
>> mono --profile=log
>> mono says that it can't find mono-profiler-log in libraries (because there
>> is no libmono-profiler-log.* in /usr/lib) nor in executable. If I compile
>> mono without llvm support profiler starts as expected. My platform is
>> linux
>> 32 bit, mono from master branch.
>>
>> Also where can I look into code samples, which definitely execute faster
>> on
>> mono with --llvm option? I tried two tests - web server (runs 30% slower
>> with llvm), String.GetHashCode() and String.GetCaseInsensitiveHashCode() -
>> same speed with llvm and without llvm. Would like to know what types of
>> code
>> I can use with llvm to increase performance.
>>
>
> Are you comparing wallclock time of the whole execution or only after
> warmup? LLVM is
> an order of magnitude slower at compiling code than the default JIT, so
> you must
> account for that.
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono with llvm and profiler

[Rodrigo Kumpera]

Can you file a bug on profiling with llvm enabled? It's supposed to work.


On Wed, Dec 11, 2013 at 8:47 AM, xplicit  wrote:

> Is there a way to run mono profiler when mono compiled with llvm support?
> When I run
> mono --profile=log
> mono says that it can't find mono-profiler-log in libraries (because there
> is no libmono-profiler-log.* in /usr/lib) nor in executable. If I compile
> mono without llvm support profiler starts as expected. My platform is linux
> 32 bit, mono from master branch.
>
> Also where can I look into code samples, which definitely execute faster on
> mono with --llvm option? I tried two tests - web server (runs 30% slower
> with llvm), String.GetHashCode() and String.GetCaseInsensitiveHashCode() -
> same speed with llvm and without llvm. Would like to know what types of
> code
> I can use with llvm to increase performance.
>

Are you comparing wallclock time of the whole execution or only after
warmup? LLVM is
an order of magnitude slower at compiling code than the default JIT, so you
must
account for that.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] OS X framework queries

[Rodrigo Kumpera]

On Mon, Nov 18, 2013 at 10:06 AM, jonat...@mugginsoft.com <
jonat...@mugginsoft.com> wrote:

> A few queries regarding the Mono OS X framework:
>
> 1. The Mono 3.2.4 Mono.framework/Mono soft link still defaults to
> libmonoboehm-2.0.1.dylib rather than libmonosgen-2.0.1.dylib. Is this just
> an oversight?
>

Oversight.


> 2. Does the Mono repo contain a script that packages the result of a Mono
> build into the downloadable Mono framework?
>

It's in a separate repo, called bockbuild: github.com/mono/bockbuild


> 3. Is a future 64 bit Mono framework likely to ship as a 32/64 bit
> universal binary (assembled using lipo) or will we see separate 32 and 64
> bit releases?
>

We'll provide lipo'd libraries, we haven't made our minds with executables.
No timeline on releases with 64bits on OSX.

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

Re: [Mono-list] Crash in mono_monitor_exit

[Rodrigo Kumpera]

You can start by producing a test case, then filling a bug.


On Mon, Nov 18, 2013 at 4:36 AM, Carlo Kok  wrote:

> Hi,
>
> I've got a user that using latest mono on Mavericks which app crashes on
> what seems to be mono_monitor_exit. Where can I start looking for what
> could possibly cause this?
>
>
> Crashed Thread:  16
>
> Exception Type:  EXC_CRASH (SIGABRT)
> Exception Codes: 0x, 0x
>
> Application Specific Information:
> abort() called
>
>
> ..
> Thread 16 Crashed:
> 0   libsystem_kernel.dylib  0x9b486952 __pthread_kill + 10
> 1   libsystem_pthread.dylib 0x9000a167 pthread_kill + 101
> 2   libsystem_c.dylib   0x9026f40c __abort + 187
> 3   libsystem_c.dylib   0x9026f351 abort + 172
> 4   crossbox0x0028f9cc monoeg_g_logv + 188
> 5   crossbox0x0028f9fb
> monoeg_assertion_message + 43
> 6   crossbox0x002718a4
> _wapi_handle_set_signal_state + 596
> 7   crossbox0x00271bb5 sem_release + 261
> 8   crossbox0x00201b35 mono_monitor_exit + 117
> 9   crossbox0x000e92c1
> mono_monitor_exit_trampoline
> + 17
> 10  ??? 0x00479b4c 0 + 4692812
> 11  ??? 0x02e0ebd4 0 + 48294868
> 12  ??? 0x02e0eac8 0 + 48294600
> 13  ??? 0x02e0e714 0 + 48293652
> 14  ??? 0x02e0d8fc 0 + 48290044
> 15  ??? 0x02e0d614 0 + 48289300
> 16  ??? 0x02e0d5f8 0 + 48289272
> 17  ??? 0x02769d6b 0 + 41327979
> 18  ??? 0x00554d9d 0 + 5590429
> 19  crossbox0x0004b4ee mono_jit_runtime_invoke
> + 798
> 20  crossbox0x0020504e mono_runtime_invoke +
> 126
> 21  crossbox0x002051bc
> mono_runtime_delegate_invoke
> + 140
> 22  crossbox0x001dc7f5 async_invoke_thread +
> 2165
> 23  crossbox0x001d5474 start_wrapper + 468
> 24  crossbox0x0027aeca thread_start_routine +
> 154
> 25  crossbox0x0028b411 inner_start_thread + 65
> 26  libsystem_pthread.dylib 0x900095fb _pthread_body + 144
> 27  libsystem_pthread.dylib 0x90009485 _pthread_start + 130
> 28  libsystem_pthread.dylib 0x9000ecf2 thread_start + 34
>
>
> (full log at
> http://talk.remobjects.com/uploads/default/45/1a31a25a21082b12.txt)
>
> --
> Carlo Kok
> RemObjects Software
> ___
> 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] "Too many root sets" ?

[Rodrigo Kumpera]

It usually means you're using too much memory on a 32bits system. Boehm
can't reliably handle more than 500-800mb of heap without running into this.


On Wed, Nov 13, 2013 at 8:51 AM, mickeyf  wrote:

> Thanks - I fixed the bug in my own code that was getting me into this
> situation in the first place.
>
> But I was actually just hoping for some insight into what "Too many root
> sets" actually meant, in practical terms.
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Too-many-root-sets-tp4661307p4661313.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] "Too many root sets" ?

[Rodrigo Kumpera]

Switch to sgen, that's the long term fix,


On Tue, Nov 12, 2013 at 4:32 PM, mickeyf  wrote:

> I'm getting this error - apparently when I have threads that are not being
> garbage collected. It looks like there is a hard-coded maximum in the
> garbage collector, that is being exceeded.
>
> Can someone educate me about how this works - what it's all about?
>
> Thread.Abort is now considered a no-no. What is the best practice to
> correctly dispose of threads that have outlived their usefulness?
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Too-many-root-sets-tp4661307.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] Memory Mapped Files Support in Mono??

[Rodrigo Kumpera]

Memory mapped files is not implemented on windows.


On Thu, Nov 7, 2013 at 2:36 AM, Sambasivareddy
wrote:

> Hello i did quick(not really) check with mono on open suse 12.3 for the
> support of Memory Mapped Files.
> With few glitches(file creation in advance) i was able to run the
> appliation.
>
> But same code when run with windows compatible mono(v 3.2.3) on windows
> environemnt, it throws exception saying feature is not implemented
>
> Any idea what is the cause for this discrepancy?
>
> Thanks
> Samba
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Memory-Mapped-Files-Support-in-Mono-tp4661256p4661261.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] Invalid IL code exception

[Rodrigo Kumpera]

Run mono with --security=verifiable and it will run with the proper code
verifier.

It does look like those assemblies have been using obfuscation tools that
produce assemblies that are too broken for mono to handle.


On Tue, Sep 24, 2013 at 5:49 PM, Dilshod Tadjibaev wrote:

> Hello everyone,
>
> I am trying to make Foxit.PDF and PDFTron to work in mono linux but I am
> getting this errors when initializing the library.
>
>
> This is what I get when I run with Foxit.PDF:
>
>
> Instance {System.InvalidProgramException: Invalid IL code in
> Foxit.PDF.Merger.PdfDocument:e (): IL_001f: popat
> Foxit.PDF.Merger.PdfDocument..ctor (zz93.i4 A_0, System.String A_1)
> [0x0] in :0at Foxit.PDF.Merger.PdfDocument..ctor
> (System.String filePath) [0x0] in :0at
> foxit.MainClass.Main (System.String[] args) [0x00011] in
> /home/dilshod/source-code/Foxit-demo/Foxit_PDF_SDK_For_NET_v1_0_0_21154/solution/foxit/foxit/Program.cs:14
> } System.InvalidProgramException
>
>
> This is what I get when I run with PDFTron:
>
> Unhandled Exception:
> System.InvalidProgramException: Invalid IL code in
> pdftron.PDFNet:Initialize (): IL_000a: call  0x0600094e
>
>
>   at PDFATestCS.Class1.Main (System.String[] args) [0x1] in
> /home/dilshod/source-code/PDFNet64DotNet4/Samples/PDFATest/CS/PDFATest.cs:28
> [ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidProgramException: Invalid
> IL code in pdftron.PDFNet:Initialize (): IL_000a: call  0x0600094e
>
>
>   at PDFATestCS.Class1.Main (System.String[] args) [0x1] in
> /home/dilshod/source-code/PDFNet64DotNet4/Samples/PDFATest/CS/PDFATest.cs:28
> The application was terminated by a signal: SIGHUP
>
>
>
> I am suspecting there is some sort of unmanaged code in both of them.
>
> Here is the head of monodis Foxit.PDF.40.dll output:
>
> .assembly extern mscorlib
> {
>   .ver 4:0:0:0
>   .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4..
> }
> .assembly extern System.Drawing
> {
>   .ver 4:0:0:0
>   .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A ) // .?_:
> }
> .assembly extern System
> {
>   .ver 4:0:0:0
>   .publickeytoken = (B7 7A 5C 56 19 34 E0 89 ) // .z\V.4..
> }
> .assembly extern System.Web
> {
>   .ver 4:0:0:0
>   .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A ) // .?_:
> }
> .assembly extern System.Configuration
> {
>   .ver 4:0:0:0
>   .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A ) // .?_:
> }
> .assembly extern System.Security
> {
>   .ver 4:0:0:0
>   .publickeytoken = (B0 3F 5F 7F 11 D5 0A 3A ) // .?_:
> }
> .assembly 'Foxit.PDF.40'
> {
>   .custom instance void class
> [mscorlib]System.Reflection.AssemblyTrademarkAttribute::'.ctor'(string) =
>  (01 00 00 00 00 ) // .
>
>   .custom instance void class
> [mscorlib]System.Reflection.AssemblyTitleAttribute::'.ctor'(string) =  (
>  01 00 26 46 6F 78 69 74 20 50 44 46 20 66 6F 72   // ..&Foxit PDF for
> 20 2E 4E 45 54 20 53 44 4B 20 28 46 72 61 6D 65   //  .NET SDK (Frame
>  77 6F 72 6B 20 34 2E 30 29 00 00) // work 4.0)..
>
>   .custom instance void class
> [mscorlib]System.Reflection.AssemblyCompanyAttribute::'.ctor'(string) =  (
> 01 00 11 46 6F 78 69 74 20 43 6F 72 70 6F 72 61   // ...Foxit Corpora
>  74 69 6F 6E 00 00   ) // tion..
>
>   .custom instance void class
> [mscorlib]System.Runtime.CompilerServices.RuntimeCompatibilityAttribute::'.ctor'()
> =  (
> 01 00 01 00 54 02 16 57 72 61 70 4E 6F 6E 45 78   // T..WrapNonEx
>  63 65 70 74 69 6F 6E 54 68 72 6F 77 73 01   ) // ceptionThrows.
>
>   .custom instance void class
> [mscorlib]System.Runtime.CompilerServices.CompilationRelaxationsAttribute::'.ctor'(int32)
> =  (01 00 08 00 00 00 00 00 ) // 
>
>   .custom instance void class
> [mscorlib]System.Security.AllowPartiallyTrustedCallersAttribute::'.ctor'()
> =  (01 00 00 00 ) // 
>
>   .custom instance void class
> [mscorlib]System.Reflection.AssemblyCopyrightAttribute::'.ctor'(string) =  (
>  01 00 3F 43 6F 70 79 72 69 67 68 74 20 28 63 29   // ..?Copyright (c)
> 20 32 30 31 32 20 46 6F 78 69 74 20 43 6F 72 70   //  2012 Foxit Corp
>  6F 72 61 74 69 6F 6E 2C 20 32 30 30 31 20 2D 20   // oration, 2001 -
> 32 30 31 32 20 63 65 54 65 20 53 6F 66 74 77 61   // 2012 ceTe Softwa
>  72 65 00 00 ) // re..
>
>   .custom instance void class DotfuscatorAttribute::'.ctor'(string, int32)
> =  (
> 01 00 18 33 36 35 38 38 3A 31 3A 30 3A 34 2E 39   // ...36588:1:0:4.9
>  2E 37 30 30 30 2E 33 32 30 37 32 00 00 00 00 00   // .7000.32072.
> 00  ) // .
>
>   .custom instance void class
> [mscorlib]System.CLSCompliantAttribute::'.ctor'(bool) =  (01 00 01 00 00 )
> // .
>
>   .custom instance void class
> [mscorlib]System.Reflection.AssemblyProductAttribute::'.ctor'(string) =  (
>  01 00 16 46 6F 78 69 74 20 50 44 46 20 66 6F 72   // ...Foxit PDF for
> 20 2E 4E 45 54 20 53 44 4B 00 00) //  .NET SDK..
>
>   .custom instance void class

Re: [Mono-list] Getting list of all currently created appdomains with soft debugger

[Rodrigo Kumpera]

sdb current doesn't support it. If you need such functionality, feel free
to make a pull request with such a feature.


On Thu, Sep 26, 2013 at 2:26 PM, acrilige  wrote:

> Hi!
>
> I'm writting the library using mono soft debugger wire protocol
>
> In this library, I want to keep track of all currently loaded app domains
> in
> a target process
>
> I get root domain id during VM_START event
> I get new app domains with help of APPDOMAIN_CREATE event
>
> But what if I would attach to a process when two or more appdomains were
> already created?
> How can I get a second one, for example, immediately after attaching to a
> process? Is there any way?
>
> For now I know that I have more than one appdomain only when new assembly
> is
> being loaded in another app domain (not the root one).
>
> Thanx for help!
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Getting-list-of-all-currently-created-appdomains-with-soft-debugger-tp4660980.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] sgen error when using large SOAP proxy

[Rodrigo Kumpera]

My first suggestion is to avoid trying options that are not marked as
stable. concurrent mark and the split nursery are not. Said that, please
file a bugreport with a test
case and we'll get it fixes.


On Thu, Sep 26, 2013 at 2:07 PM, David Curylo  wrote:

> I have an application that must load a very large SOAP proxy with hundreds
> of classes.  Under boehm GC, I'm able to load the application, but when
> running under sgen my application crashes immediately with a SIGABRT.  I'm
> able to get a stack trace under sgen to this effect:
>
> * Assertion: should not be reached at sgen-scan-object.h:111
>
> Stacktrace:
>
>   at  <0x>
>   at (wrapper managed-to-native)
> System.MonoCustomAttrs.GetCustomAttributesInternal
> (System.Reflection.ICustomAttributeProvider,System.Type,bool)  0x>
>   at System.MonoCustomAttrs.GetCustomAttributesBase
> (System.Reflection.ICustomAttributeProvider,System.Type,bool) [0x00019] in
> /home/abuild/rpmbuild/BUILD/mono-3.2.1/mcs/class/corlib/System/MonoCustomAttrs.cs:101
>   at System.MonoCustomAttrs.GetCustomAttributes
> (System.Reflection.ICustomAttributeProvider,bool) [0x00017] in
> /home/abuild/rpmbuild/BUILD/mono-3.2.1/mcs/class/corlib/System/MonoCustomAttrs.cs:274
>   at System.MonoType.GetCustomAttributes (bool) [0x0] in
> /home/abuild/rpmbuild/BUILD/mono-3.2.1/mcs/class/corlib/System/MonoType.cs:573
>   at System.Xml.Serialization.XmlAttributes..ctor
> (System.Reflection.ICustomAttributeProvider) [0x00032] in
> /home/abuild/rpmbuild/BUILD/mono-3.2.1/mcs/class/System.XML/System.Xml.Serialization/XmlAttributes.cs:64
> …more of stack trace is available if you want.
>
> The cause seems to be that the sgen GC is having to do too much collection
> while processing the large type library.  Trying these options:
>
> export
> MONO_GC_PARAMS="major=marksweep-conc,minor=split,alloc-ratio=100,nursery-size=128m,max-heap-size=2048m,evacuation-threshold=0"
>
> seems like it would make the nursery much larger so it can handle the
> large type library.  However, doing so leads me to this error:
>
> Assertion at sgen-nursery-allocator.c:293, condition
> `fragment->fragment_end > fragment->fragment_start' not met
>
> I'm stuck at this point.  Any suggestions?
> ___
> 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] Invalid IL code exception

[Rodrigo Kumpera]

On Tue, Sep 24, 2013 at 5:49 PM, Dilshod Tadjibaev wrote:

> Hello everyone,
>
> I am trying to make Foxit.PDF and PDFTron to work in mono linux but I am
> getting this errors when initializing the library.
>
>
Run mono with --security=verifiable and it will run with the proper code
verifier.

It does look like those assemblies have been using obfuscation tools that
produce assemblies that are too broken for mono to handle.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] NetTcpBinding supported in C++/CLI?

[Rodrigo Kumpera]

Mono doesn't support C++/CLI.


On Tue, Sep 24, 2013 at 4:10 PM, Yifeng  wrote:

> I'm using WCF in C++/CLI. I'm wondering if MONO supports NetTcpBinding in
> C++/CLI.
> Before I start to get into MONO, I just need some confirmation if it is
> supported by MONO.
> Any comment would be appreciated. Thanks.
>
> some sample code, would these kind of WCF code supported using MONO?
> Service:
> host->AddServiceEndpoint(IService1::typeid, gcnew NetTcpBinding(),
> L"net.tcp://localhost:6000/service");
> host->Open();
> NetTcpBinding^ binding = gcnew NetTcpBinding();
> EndpointAddress^ address = gcnew
> EndpointAddress(String::Format(L"net.tcp://localhost:6000/service",
> Environment::MachineName));
> ChannelFactory^ factory = gcnew
> ChannelFactory(binding, address);
> proxy = factory->CreateChannel();
>
> Client:
> NetTcpBinding^ binding = gcnew NetTcpBinding();
> EndpointAddress^ address = gcnew
> EndpointAddress(String::Format(L"net.tcp://localhost:6000/service",
> Environment::MachineName));
> ChannelFactory^ factory = gcnew
> ChannelFactory(binding, address);
> IService1^ proxy = factory->CreateChannel();
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/NetTcpBinding-supported-in-C-CLI-tp4660958.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] OS X 64bit support

[Rodrigo Kumpera]

Mono itself works fine on 64bits OSX and so does Xamarin.Studio with some
modifications.

We've been working towards that for quite some time now.


On Fri, Sep 20, 2013 at 9:06 AM, jonat...@mugginsoft.com <
jonat...@mugginsoft.com> wrote:

>
> Now that the iPhone sports 64 bits will we see the standard OS X Mono
> framework download supporting 64 bits anytime soon?
> This does seem to have been on the cards for a while.
>
> Jonathan
>
>
>
>
>
>
>
>
>
> ___
> 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] Mono.Simd - Flow Control (?)

[Rodrigo Kumpera]

You use a wide compare followed by an extract mask step.


On Tue, Sep 10, 2013 at 7:08 PM, Nigel Delaney wrote:

> Hi All,
>
> ** **
>
> Does anyone how to do control flow with the Mono.Simd namespace.  For
> example, break if all elements in a vector match some condition relative to
> another vector.  e.g.
>
> ** **
>
> var x= Vector2d(1,2);
>
> var y=Vector2d(3,4):
>
> if(y
> Do something…
>
> ** **
>
> I gather SSE has a movmskps instruction that is useful, but am not sure
> if this is an available operation from mono.
>
> ** **
>
> -Nigel
>
> ** **
>
> PS For context I am working on this toy problem for the language shootout (
> http://evolvedmicrobe.com/blogs/?p=112), but generally need to know if
> this is possible.
>
> ** **
>
> ___
> 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] Mono.Simd - Flow Control (?)

[Rodrigo Kumpera]

You can cast between vector types for free.


On Mon, Sep 16, 2013 at 3:21 PM, Nigel Delaney wrote:

> Hi,
>
> ** **
>
> Thanks for the response, it’s always great to hear from the person who
> wrote the code in question (and this really does look like a great
> namespace to, thanks).  Unfortunately, I am still not sure how to implement
> your idea.  I gather I can do the wide compare with this method:
>
> ** **
>
> public unsafe static Vector2d CompareLessThan (this Vector2d v1, Vector2d
> v2)
>
> ** **
>
> However, I am still not sure how I can extract the byte mask.  I gather
> from the source code:  
>
> ** **
>
>
> https://github.com/mono/mono/blob/0f2995e95e98e082c7c7039e17175cf2c6a00034/mcs/class/Mono.Simd/Mono.Simd/VectorOperations.cs
> 
>
> That the ExtractByteMask method is only available for Vector16sb and
> Vector16b and not any of the other vector types.  Does this mean I would
> have to cast to one of these types in order to run this method?  I am not
> sure what the consequences of this would be.  I think (?) that from the
> machines perspective these SSE vector objects are all just 16 bytes that
> get loaded into the XMM registers, so I don’t know if this cast would have
> any overhead, put am worried it wouldn’t be any more efficient than just
> unpacking the values and comparing them separately.  Any thoughts on
> whether I could extract a byte mask directly from the vector2d, or if the
> cast would be expected to be faster than just unpacking the Vector2d values
> and comparing them separately?
>
> ** **
>
> Thanks again for the help,
>
> Nigel
>
> ** **
>
> ** **
>
> ___
> 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] Rx | TPL Dataflow | Solver Foundations

[Rodrigo Kumpera]

Mono 3.2 ships with RX and TPL Dataflow.
I have no idea what Solver Foundations is.


On Fri, Aug 23, 2013 at 11:29 AM, sirinath  wrote:

> Hi,
>
> Support for the above is missing from the Mono distribution. Is it possible
> to add support for them.
>
> Suminda
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Rx-TPL-Dataflow-Solver-Foundations-tp4660625.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] Mono 3.2.0 for windows

[Rodrigo Kumpera]

We're working hard to get mono building on windows after a month of
breakage.

Our plans is to skip windows for the next release 3.2.2 and have it for
3.2.3 which will follow right after.


On Thu, Aug 15, 2013 at 10:05 AM, tehnari  wrote:

> It'll be good if someone tell something about this, but no answers in IRC
> and
> at the main site too. That's strange. And a build for version 3.0.10 for
> windows exists but no link at the site...
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Mono-3-2-0-for-windows-tp4660355p4660564.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] embeded mono segfaults without calling managed code

[Rodrigo Kumpera]

For Java, try this:
http://docs.oracle.com/javase/6/docs/technotes/guides/vm/signal-chaining.html


On Mon, Aug 5, 2013 at 1:49 AM, Chris Ochs  wrote:

> It appears that java and mono both use some of the same signals for GC and
> pthreads, and step on each other.  If you embed mono in a java app it works
> fine until you start spinning up other java threads, then it eventually
> segfaults.  This happens even if you do nothing but call mono_jit_init in
> the main thread.
>
>
> On Fri, Aug 2, 2013 at 10:50 PM, snacktime  wrote:
>
>> I'm embedding mono using C, which I'm calling from java.   I'm loading the
>> mono runtime in the main thread.  That all works fine, until I load the
>> rest
>> of my app, at which point it segfaults.  It does this even when the only
>> thing I do is call mono_jit_init().  My c method that calls that returns
>> void, there are no references to anything from the mono side that I'm
>> carrying around.
>>
>> I'd debug it with gdb but it's a jruby app, and I haven't figured out how
>> to
>> debug that under gdb.
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://mono.1490590.n4.nabble.com/embeded-mono-segfaults-without-calling-managed-code-tp4660386.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
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono 3.1.2 on OSX, "Degraded allocations"

[Rodrigo Kumpera]

Your program is causing too many objects to be pinned, you probably have
too many threads with too big stacks.

If not the case, it's a bug.


On Tue, Jul 23, 2013 at 5:11 AM, Nicklas Overgaard wrote:

> Hi!
>
> I'm currently testing out the newest mono on OSX. I'm running a simple
> ServiceStack API in a console runner, and while benchmarking a handler with
> AB, the console suddenly contained:
>
> """
> *Warning: Degraded allocation.  Consider increasing nursery-size if the
> warning persists.*
> """
>
> What is this exactly?
> Can I do anything in my code to not run in to such a situation?
>
> Any pointers are appreciated :)
>
> Best regards
> ---
> Nicklas Overgaard
>
> Founder & Lead Developer
> iSharp Solutions ApS
>
> ___
> 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] Sockets severe non-linear performance degradation

[Rodrigo Kumpera]

Please file a bug with a test case if you think it's a bug on mono's stack.


On Mon, Jun 24, 2013 at 10:58 AM, Ian Gardner wrote:

> Platform: linux ubuntu 12.04 AMD64
> Mono version 2.10.8.1
>
> I have just started with C# and have a simple client-server test app
> that measures throughput and latency from the client for a typical
> send+recieve message scenario. As I increase the message size to more
> than the socket send+recieve buffer size performance falls off a cliff,
> whereas I would expect latency (round trip time) to increase approx
> linearly with the ratio round_up((message size) / (socket buf size))
> and throughput (bytes/sec) to stay approx constant.
>
> I set socket buffer send and receive sizes = N
>
> When message size < N:
> Roundtrip Latency: 1-3 milliseconds
> Throughput: ~2 Mbyte/sec
>
> This compares well with my equivalent java/C code on the same machine,
> about equalling java as I would expect and being a bit slower than
> native C sockets (I can comfortably get sub-millisecond round trips
> with C, throughput around 5Mbyte/sec)
>
> When N < message size < 2 * N:
> Roundtrip Latency: 400-1000 milliseconds
> Throughput: 50-100 Kbyte/sec
>
> Machine shows very low CPU usage so it appears that the IO subsystem is
> not rescheduling a thread blocked on IO in a timely manner. This
> puzzles me since a direct mapping of the Socket methods onto the C
> library counterparts should achieve what is required. So have I missed
> some critical option, or does mono do something with IO/thread mapping
> onto the OS that is causing this?
>
> Some more detail on my test app:
> The basic loop I am timing is.
> 1. Client writes random sized buffer to socket
> 2. Server reads data
> 3. Server writes random sized buffer to socket
> 4. Client reads data and stops timer
>
> A message consists of a small fixed header indicating the size of
> following data.
> Thus:
>   write requires one system call since I coalesce header+data
>   read requires two system calls, one for fixed header and one for
> variable data
>
> Both client and server sockets are given the same options:
>   socket.ReceiveBufferSize = 16000;
>   socket.SendBufferSize = 16000;
>   socket.NoDelay = true;
>   socket.SetSocketOption(**SocketOptionLevel.Socket,
>  SocketOptionName.DontLinger, false);
>
> I have tried three basic approaches to the read/write loop.
> A. socket.Blocking = true and use socket.Receive()/socket.Send()
> B. socket.Blocking = true/false and use the async versions of
>socket.Receive()/socket.Send()**. I.e. socket.BeginReceive() followed
>immediately by socket.EndReceive()
> C. socket.Blocking = false and use socket.Receive()/socket.Send() and
>socket.Poll(SelectMode.**SelectRead or SelectWrite)
>to wait for data where appropriate.
>
> All three approaches show the same problem.
> Both A and C map to the same approach I have used in native sockets
> programming, and B may map to C internally so I did not really expect
> it to be any better.
>
> A few more points:
> 1. The code is operating correctly in the sense that it reliably
>transfers data (which I CRC32 check), it is solely performance which
>is the problem.
> 2. I use the high resolution System.Diagnostics.Stopwatch.**GetTimestamp()
> 3. I call an explicit System.GC.Collect() before starting each timed
>test to reduce chances of GC skewing the timings.
> 4. I have tested over a standard TCP socket on main machine address and
>also on local loopback address, no change.
> 5. I have not tested on windows since I purged microsoft from my life
>several years ago and currently have no windows machine.
> 6. It is not possible from test code to know if delay is in read, write
>or both read+write blocking.
>
> Any help would be appreciated.
>
> __**_
> 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] cannot install 2.10 on centos 6

[Rodrigo Kumpera]

You need to get mono 3.0 from your distro packager or build it yourself.





On Fri, Jun 21, 2013 at 4:59 PM, eztarg3t  wrote:

> And further, it only shows for Mac?
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/cannot-install-2-10-on-centos-6-tp4659993p4659996.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] cannot install 2.10 on centos 6

[Rodrigo Kumpera]

Please migrate to mono 3.0 as 2.10 is not longer been maintained.


On Fri, Jun 21, 2013 at 4:25 PM, eztarg3t  wrote:

> Followed the instructions in the readme and here:
> http://mono-project.com/Compiling_Mono_From_Git .
>
> Running make fails with mcs error that it needs some things.  Tried running
> the make with: make get-monolite-latest and the website times out.
>
> --2013-06-20 13:15:33--  (try:17)
> http://mono.ximian.com/daily/monolite-108
> Connecting to mono.ximian.com|130.57.21.44|:80... failed: Connection timed
> out.
>
> Found another link in the documentation to a tarball, but again the ximian
> site times out.  Cannot find any other location on the web for this file.
> Is the site down temporarily or permanently?  Where else can I find the
> needed files in order to compile?
>
> I appreciate any assistance.
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/cannot-install-2-10-on-centos-6-tp4659993.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] WCF Not Working Type is not unique

[Rodrigo Kumpera]

Please migrate to mono 3.0 and test again. Mono 2.10 is not longer been
actively maintained.


On Tue, Jun 18, 2013 at 11:25 AM, jdd49  wrote:

> I am using Mono 2.10.8.1 with Debian and I cannot get WCF to function
> correctly.  I am getting error 500 Type is not unique.  The solution loads
> and works fine when using Visual Studio and all of the web services work.
> It is only in Mono that it doesn't work.  Does anyone know what this error
> means, or have you successfully got your WCF services to work with Mono.
>  If
> so, can you post your config.
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/WCF-Not-Working-Type-is-not-unique-tp4659965.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] Why isn't sgen the default?

[Rodrigo Kumpera]

It's stable enough that Xamarin uses it exclusively on its Android product.

We haven't switched mostly because it can potentially cause regressions to
existing apps that rely on broken extensions that only work with boehm.

Besides that, there are no other reasons but been lazy on changing the
build system.




On Fri, May 24, 2013 at 1:14 PM, Nigel Delaney wrote:

> Out of curiosity, does anyone know why the sgen garbage collector isn’t
> the default option in mono?  Is it still considered too beta?
>
> ** **
>
> I ask because I recently looked at some “language”” shootout (
> http://benchmarksgame.alioth.debian.org/u32/csharp.php) and was very
> surprised to see that mono/C# was often much slower than Java.  I examined
> the test with the biggest difference (Binary trees, which creates/destroys
> a lot of objects), and noticed that the large difference between Java/C#
> basically disappears when sgen is used as an option.  In my limited
> experience I always have found this option to be a performance win, so
> would be interested to know why it isn’t the default.
>
> ___
> 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] SocketAsyncEventArgs

[Rodrigo Kumpera]

Looks like a missing feature. Could you file a bug report on this?
On May 6, 2013 3:21 PM, "Dave Thomas"  wrote:

> Hi, I was porting my .Net library to Mono and I have stumbled upon an area
> where there appears to be an unimplemented feature.
>
> I can't find the *ConnectedSocket* property for the *SocketAsyncEventArgs* 
> type:
>
>
>
> http://msdn.microsoft.com/en-us/library/system.net.sockets.socketasynceventargs.connectsocket.aspx
>
> There appears to be an #ifdef for this property for Mono2_1 but I don't
> have it in my Mono release.
>
> Im using Mono 3.0.10 currently.   Any ideas?
>
> Cheers
> Dave.
>
> ___
> 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] Mono 3.0.10 download link for windows not working

[Rodrigo Kumpera]

We did not ship 3.0.10 for windows, I'm sorry.


On Wed, May 1, 2013 at 9:17 AM, samkrao  wrote:

> Unable to download mono 3.0.10 beta
> below is the message
>
> Not Found
>
> The requested URL
> /archive/3.0.10/windows-installer/mono-3.0.10-gtksharp-2.12.11-win32-0.exe
> was not found on this server.
>
> Apache/2.2.22 (Ubuntu) Server at origin-download.mono-project.com Port 80
>
>
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Mono-3-0-10-download-link-for-windows-not-working-tp4659565.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] Mono embedding - null pointer access violation on ves_icall_System_Reflection_Assembly_GetExecutingAssembly

[Rodrigo Kumpera]

Did you attach the thread before calling into the mono runtime?


On Fri, Apr 12, 2013 at 8:00 PM,  wrote:

> Hi,
>
> I am trying to flush out bugs in an application with Mono (3.0.6)
> embedded. Improving on the Linux front, an issue on Windows is now baffling
> me. The issue seems deep in JIT exec code but has got to be because of my
> code.
> I tried to condense the diagnosis with the (visual studio) native stack
> trace (I could not get the managed part from MonoDevelop yet). I'd highly
> appreciate the informed guess of a guru to suggest where to look to fix it.
>
> Regards.
>
> The high level call (in the R language) is like:
> callStaticMethod( "SomeNamespace.AClassName", "TheStaticMethod",
> "SomeString", "AnotherString" )
>
> The main C code for preparing the CLR method call
> MonoMethod * methodCallStaticMethod = rclr_mono_get_method(
> spTypeClrFacade, "CallStaticMethodMono", 3);
> void** static_mparams = (void**)malloc(3*sizeof(void*));
> MonoArray* methParams = create_array_object(params, paramCount);
> static_mparams[0] = create_mono_string(ns_qualified_typename);
> static_mparams[1] = create_mono_string(methodName);
> static_mparams[2] = methParams;
> result = mono_runtime_invoke (methodCallStaticMethod, NULL,
> static_mparams, &exception);
> // calling the C# method:
> // public static object CallStaticMethodMono(string typename,
> string methodName, object[] arguments)
>
> further in the stack strace, in:
> icall.c :
> ves_icall_System_Reflection_Assembly_GetExecutingAssembly (void)
> the following line returns dest as a NULL pointer, which looks like a very
> unexpected condition hence the crash.
> mono_stack_walk_no_il (get_executing, &dest);
> It seems that the root cause is in the function:
> mono_walk_stack_full:
> while (MONO_CONTEXT_GET_SP (&ctx) <
> jit_tls->end_of_stack)
> which is already false at the first iteration, hence 'dest' remains NULL.
>
>
>
> ___
> 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] GC.Collect

[Rodrigo Kumpera]

Your application probably have a memory leak or you have found one in mono.

Enable GC logging (export this env var: MONO_LOG_MASK=debug) and see if the
managed heap is growing.
If it keeps growing you have a managed leak, you can use the current
profiler and its command line tools to try to figure out what's wrong.
If it's not you have a native leak, in such case, try to produce a minimal
test case and file a bug report.


On Wed, Apr 10, 2013 at 6:31 AM, Lin  wrote:

> Hello,
>
> I have a C# program run in windows 7 and openSuse 12.3
>
> In Windows 7, my program only use 17MB RAM and it works perfect.
>
> But, it use more than 600MB RAM in Linux.
>
> Mono and mono-sgen has the same problem, my software is crash.
>
> So, I need help.
>
> Is anybody can help to solve this problem, or give me an idea?
>
> Thanks.
>
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/GC-Collect-tp4659310.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] Determine what's using CPU

[Rodrigo Kumpera]

You can try to use kill -QUIT to ask mono to produce a full stack dump to
stderr.


On Tue, Apr 9, 2013 at 12:14 PM, David Evans
wrote:

> I usually use "top -H" to get the thread id of the thread that is hogging
> the CPU. Then I use "top" to get the process id, then connect to that
> process using gdb and use "info threads" to find the thread number for the
> thread id that was hogging the CPU. Then I switch to that thread and back
> trace to see what it's doing, sometimes continuing and breaking a few times
> as a poor man's sample of different stack traces for what it's doing.
>
> There are probably better ways of doing this, but that's the simple
> approach I've used with gdb.
>
> -Original Message-
> From: mono-list-boun...@lists.ximian.com [mailto:
> mono-list-boun...@lists.ximian.com] On Behalf Of Dave Curylo
> Sent: Tuesday, April 09, 2013 8:20 AM
> To: mono-list@lists.ximian.com
> Subject: [Mono-list] Determine what's using CPU
>
> I have a process that sporadically becomes unresponsive and starts using a
> lot of CPU.  Before I thought this was a GC issue, and switched to sgen,
> but the issue is still there.  I've use gdb with "thread apply all bk" in
> the past, which pointed me to the GC issues, but now it appears GC isn't
> really the problem.  Is there some other way to see what is causing the
> high CPU in gdb or is my only option to start the process with the mono
> profiler attached?
> ___
> 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 maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono LLVM

[Rodrigo Kumpera]

This was a bug on the last released mono and we've fixed it.

Besides that, no, it's not possible to use emscripten with mono's llvm
output for a lot of reasons.
The output embeds calls to the mono runtime and some trampilines.
Mono use a custom LLVM with custom IR operations and that won't work
on emscripten
without some work on their end.


On Wed, Apr 3, 2013 at 11:44 AM, Александр Гурьянов wrote:

> Hi all. It is possible to compile program into llvm ir for use it in
> emscripten? Now i try to compile aot with llvm, but got error:
>
> mono --aot=full --llvm Game.exe
> Mono Ahead of Time compiler - compiling assembly Game.exe
> * Assertion at image-writer.c:2177, condition `fp' not met
>
> Stacktrace:
>
>
> Native stacktrace:
>
> mono() [0x80e6431]
> [0xb773a40c]
> [0xb773a424]
> /lib/i386-linux-gnu/libc.so.6(gsignal+0x4f) [0xb75471df]
> /lib/i386-linux-gnu/libc.so.6(abort+0x175) [0xb754a825]
> mono() [0x82189f7]
> mono() [0x8218a73]
> mono() [0x80fa2b3]
> mono() [0x80cee35]
> mono(mono_main+0xd82) [0x80c0112]
> mono() [0x805bac8]
> /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3) [0xb75324d3]
> mono() [0x805bbc5]
>
> Debug info from gdb:
>
> [New LWP 21083]
> [New LWP 21082]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
> 0xb773a424 in __kernel_vsyscall ()
>   Id   Target Id Frame
>   3Thread 0xb71ccb40 (LWP 21082) "mono" 0xb773a424 in
> __kernel_vsyscall ()
>   2Thread 0xb668db40 (LWP 21083) "mono" 0xb773a424 in
> __kernel_vsyscall ()
> * 1Thread 0xb7517700 (LWP 21081) "mono" 0xb773a424 in
> __kernel_vsyscall ()
>
> Thread 3 (Thread 0xb71ccb40 (LWP 21082)):
> #0  0xb773a424 in __kernel_vsyscall ()
> #1  0xb76cd96b in pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:169
> #2  0x0822ba97 in ?? ()
> #3  0x08225db9 in ?? ()
> #4  0x0822a252 in ?? ()
> #5  0xb76c9d4c in start_thread (arg=0xb71ccb40) at pthread_create.c:308
> #6  0xb7607d3e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
>
> Thread 2 (Thread 0xb668db40 (LWP 21083)):
> #0  0xb773a424 in __kernel_vsyscall ()
> #1  0xb76cfcc5 in sem_wait@@GLIBC_2.1 () at
> ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/sem_wait.S:80
> #2  0x0820fa38 in mono_sem_wait ()
> #3  0x0815696c in ?? ()
> #4  0x081df5cd in ?? ()
> #5  0x0820a033 in ?? ()
> #6  0x0822b888 in ?? ()
> #7  0xb76c9d4c in start_thread (arg=0xb668db40) at pthread_create.c:308
> #8  0xb7607d3e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
>
> Thread 1 (Thread 0xb7517700 (LWP 21081)):
> #0  0xb773a424 in __kernel_vsyscall ()
> #1  0xb76d09db in read () at ../sysdeps/unix/syscall-template.S:82
> #2  0x080e65fc in ?? ()
> #3  
> #4  0xb773a424 in __kernel_vsyscall ()
> #5  0xb75471df in __GI_raise (sig=6) at
> ../nptl/sysdeps/unix/sysv/linux/raise.c:64
> #6  0xb754a825 in __GI_abort () at abort.c:91
> #7  0x082189f7 in ?? ()
> #8  0x08218a73 in ?? ()
> #9  0x080fa2b3 in ?? ()
> #10 0x080cee35 in ?? ()
> #11 0x080c0112 in mono_main ()
> #12 0x0805bac8 in ?? ()
> #13 0xb75324d3 in __libc_start_main (main=0x805b9d0, argc=4,
> ubp_av=0xbfd8f444, init=0x823e300, fini=0x823e370, rtld_fini=0xb774a270
> <_dl_fini>, stack_end=0xbfd8f43c) at libc-start.c:226
> #14 0x0805bbc5 in ?? ()
>
> =
> Got a SIGABRT while executing native code. This usually indicates
> a fatal error in the mono runtime or one of the native libraries
> used by your application.
> =
>
>
> Thanks.
>
> ___
> 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] Mono + CoreCLR + Nunit

[Rodrigo Kumpera]

Enabling CoreCLR requires embedding mono and building a custom BCL. It
cannot be readily enabled with vanilla mono.


On Wed, Mar 20, 2013 at 2:50 AM, sunwukong  wrote:

> Hi guys,
> I am planning to use Mono CoreCLR security infrastructure as a sandbox for
> running untrusted code. Specifically they are user tests which are run
> using
> nunit or msunit on the server once they are uploaded. I read about the
> CoreCLR attributes but I couldn't find any practical source online (Except
> the c++ examples and a test from mono github source). All of my code is in
> C# so no embedding I suppose. I tried invoking nunit-console with mono with
> security option core-clr and it failed (which I think is reasonable cause I
> haven't declared anywhere that nunit assemblies are safe).
>
> My current idea is to write a custom nunit runner, declare that as safe
> critical. And use that as a gateway to run my tests by passing the assembly
> path from commandline with mono core-clr security switch.
>
> Will this idea work or are there loopholes in it which I am missing.
>
> Thank you. Any pointers in this or examples are appreciated.
>
> ./sun
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Mono-CoreCLR-Nunit-tp4659096.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] Mono 3.0.x + llvm compile error

[Rodrigo Kumpera]

Use the branch named mono.

On Friday, March 22, 2013, Marco Ridoni wrote:

> Hello,
> I'm trying to compile Mono 3.0.7 from source with LLVM enabled. I know I
> should use the LLVM/Mono version on GitHub, but which branch should I use?
> Using mono-2-8, mono-2-10 or master gives in turn different errors. I
> followed the instructions on the website (
> http://www.mono-project.com/Mono_LLVM).
>
> In case I'm missing something, can someone list the steps needed to add
> LLVM support?
>
> Thanks
>
>
> m.
>
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] All threads go into sigsuspend()

[Rodrigo Kumpera]

You might have bumped into a bug in boehm gc, could you post a full thread
dump when it hangs?


On Tue, Mar 19, 2013 at 6:34 PM, Dave Curylo  wrote:

> I'm running mono 2.10.8.1 on CentOS 6.3 and running a mono-service
> application.  It seems to run fine for a while, but then after a few hours
> appears hung.  No CPU is in use, but my application doesn't respond to HTTP
> requests anymore, isn't logging anything, nothing.  I used gdb to get a
> backtrace when it's hung, and it appears that every thread is stuck in
> sigsuspend().  Most seem to be following a _GC_suspend_handler, like here
> is an example:
>
> Thread 13 (Thread 0x7f4c286a7700 (LWP 1395)):
> #0  0x7f4c2f1abc54 in sigsuspend () from /lib64/libc.so.6
> #1  0x005f2efe in _GC_suspend_handler (sig=30) at
> pthread_stop_world.c:186
> #2  0x005f2f3d in GC_suspend_handler (sig=30) at
> pthread_stop_world.c:211
> #3  
> #4  0x7f4c2f5177bb in pthread_cond_timedwait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #5  0x005aeeed in _wapi_handle_timedwait_signal_handle
> (handle=0x42b, timeout=0x7f4c286a6810, alertable=1, poll= out>) at handles.c:1653
> #6  0x005a6a11 in WaitForSingleObjectEx (handle=0x42b,
> timeout=, alertable=1) at wait.c:205
> #7  0x005995ab in
> ves_icall_System_Threading_WaitHandle_WaitOne_internal (this= optimized out>, handle=0x42b, ms=, exitContext=)
> at threads.c:1665
> #8  0x413d31f8 in ?? ()
> #9  0x7f4c1c40 in ?? ()
> #10 0x7fff1d77ba37 in clock_gettime ()
> #11 0x413d2ddb in ?? ()
> #12 0x270f in ?? ()
> #13 0x270f in ?? ()
> #14 0x413d1340 in ?? ()
> #15 0x413d137b in ?? ()
> #16 0x in ?? ()
>
> After I stop and restart the mono-service, the application responds as
> normal, and most of the threads are in pthread_cond_wait, but NONE of them
> are in sigsuspend():
>
> Thread 13 (Thread 0x7fabf2954700 (LWP 7493)):
> #0  0x7fabf4af643c in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib64/libpthread.so.0
> #1  0x005e455f in GC_wait_marker () at pthread_support.c:1863
> #2  0x005d55bd in GC_help_marker (my_mark_no=105) at mark.c:1116
> #3  0x005e32e0 in GC_mark_thread (id=0x3) at pthread_support.c:552
> #4  0x7fabf4af2851 in start_thread () from /lib64/libpthread.so.0
> #5  0x7fabf484090d in clone () from /lib64/libc.so.6
>
> Any idea why all the threads would go into sigsuspend()?  I'm not using
> sgen, by the way.  I can try if anyone expects that to be of any help.
>
> If you need a full backtrace of all the threads, let me know.
>
> Thanks for your help.
> -Dave
>
> ___
> 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] Poor Mono performance

[Rodrigo Kumpera]

A few important things to keep in mind:

-The Windows port of mono lags in terms of performance compared to OSX and
linux;
-The new, and significantly faster, garbage collector is not fully
supported on windows, and absent on 2.10;
-The new 3.0 series is significantly faster;


On Tue, Mar 12, 2013 at 12:54 PM, Nigel Delaney
wrote:

> Edward and Imre - Wow, okay your results definitely didn't mesh with mine,
> very strange things are afoot... On my windows 7 with an Intel i7 3.4 GHz
> processor I had substantially different runtimes comparing mono and .NET
> 4.5.  Below shows the 2x2 factorial for compiler versus runtime.  These
> results do not change much across replicates, and basically there is a
> massive performance difference between .NET and mono when I ran it.  I
> don’t know if at this stage this is due to cache misses/etc.  Looking at
> the IL produced by the two different compilers, there are some differences
> in the methods and they load the different methods at different positions
> in the table, in any event there is a clear difference between all of these
> 4 except the two mono treatments.  I wonder if this is a .NET 4 v 4.5 thing?
> 
>
> ** **
>
> *Compiler*
>
> *CLI*
>
> *Time*
>
> mcs 
>
> Mono 2.10.9
>
> 1.9 s
>
> mcs 
>
> .NET 4.5
>
> .93 s
>
> Visual Studio
>
> Mono 2.10.9
>
> 1.87 s
>
> Visual Studio
>
> .NET 4.5
>
> 0.64 s
>
> ** **
>
> ** **
>
> Imre  –  you missed the point of my email, and obviously I could have made
> the program a lot faster than I did.  The point is that your program is
> generally slow for other reasons, though you seemed to be worried about
> using Arrays or Lists which is peanuts compared to other things you could
> do.  In particular, in both Mono and .NET, method calls are expensive.  In
> my experience, adding numbers and incrementing values takes no time
> compared to calling the method that does these things.  I was suggesting
> you should do the following things:
>
> ** **
>
> 1 – Make sure the method is inlined, avoid the method call.
>
> ** **
>
> 2 – Do not insert the for loop inside a useless do while loop.  You are
> checking conditions inside and outside the method and likely preventing
> important optimizations like caching the list.count property.  I don’t know
> what you are trying to do, but note that if you replace the do/while code
> with the code below, than you inline the Advance method, can still do
> everything inside the loop and it is over an order of magnitude faster on
> either .NET or Mono.  Not sure if you can do this with your code, but the
> point is mono v. .NET performance differences pale in comparison to the
> nested for-loop-method-call-inside-do-while-loop performance penalty you
> are paying right now. 
>
> ** **
>
>for (int index = counters.Count - 1; index >= 0; --index)
>
>{
>
> ++counter;
>
> if (counters[index] == (totals[index] - 1))
>
> {
>
> counters[index] = 0;
>
> continue;
>
> }
>
> else
>
> {
>
> ++counters[index];
>
> }
>
> ** **
>
> //All kinds of other stuff can be done here
>
> }
>
> ** **
>
> -N
>
> ** **
>
> ** **
>
> -Original Message-
> From: mono-list-boun...@lists.ximian.com [mailto:
> mono-list-boun...@lists.ximian.com] On Behalf Of edward.harvey.mono
> Sent: Tuesday, March 12, 2013 10:06 AM
> To: imreolajos; mono-list@lists.ximian.com
> Subject: Re: [Mono-list] Poor Mono performance
>
> ** **
>
> > From: mono-list-boun...@lists.ximian.com [mailto:mono-list- 
>
> > boun...@lists.ximian.com] On Behalf Of imreolajos
>
> > 
>
> > SpeedTest.cs
>
> > 
>
> ** **
>
> Ok, you've provided some source code, you said it is important to you, and
> it represents your real life work load.  You've said you had some
> performance problems with it and would like to know why and what to do
> about it ...  Other people here have commented that it seems we're avoiding
> the problem.
>
> ** **
>
> So, I'll bite:
>
> ** **
>
> I downloaded the file you linked above, and compiled it, .Net 4 Windows 7
> x86_64 dual core intel i5.  It ran in 3.3 sec.  I then ran on the exact
> same machine in windows mono 2.10.9 and it ran in 3.66 sec.  To eliminate
> sampling error, I ran repeatedly, and alternatingly.  Windows 3.4, Mono
> 3.41, Win 3.3, Mono 3.41, Win 3.3, Mono 3.43
>
> ** **
>
> While the mono performance is a little lower, it's not dramatic.
>
> ** **
>
> I then set var totals = new List() { 10, 10, 100, 100, 1000 }; to
> make the job run longer, and ran again.  Win 32.7, Mono 32.8, Win 32.4,
> Mono 32.9
>
> ** **
>

Re: [Mono-list] Autofac 3.0.1 on Mono 3.0.5

[Rodrigo Kumpera]

Unfortunately running PCL binaries are hit-and-miss right now, so try to
use binaries compiled against .NET 4.5.

We're working on PCL, but there's no timeframe on when it will be available.


On Mon, Mar 4, 2013 at 4:01 AM, Erik Schierboom wrote:

>  Hi,
>
> Yes I am trying to consume a PCL libary. You say that Mono does not
> support PCL libraries, but the PCL library version without extension
> methods works fine. The problem is there solely with the PCL library
> version that contains extension methods.
>
> Erik
>
> Op 1-3-2013 16:35, Rodrigo Kumpera schreef:
>
> Are you trying to compile a PCL version of this lib? Mono doesn't support
> PCL.
>
>
> On Fri, Mar 1, 2013 at 8:25 AM, Alan  wrote:
>
>> This should be fixed by updating your mono to 3.0.6 or higher.
>>
>> Thanks,
>> Alan
>>
>> On 27 February 2013 13:34, Erik Schierboom 
>> wrote:
>> > I have been trying to get Autofac 3.0.1 working on Mono, but have so far
>> > been unsuccessful. When I try to run an application that references
>> Autofac
>> > 3.0.1 on Mono 3.0.5, I get the following exception:
>> >
>> > Mono: Assembly Loader probing location:
>> > '/opt/mono-3.0.5/lib/mono/4.5/mscorlib.dll'.
>> > Mono: Image addref mscorlib[0x14ce2c70] ->
>> > /opt/mono-3.0.5/lib/mono/4.5/mscorlib.dll[0x14ce1ec0]: 2
>> > Mono: Assembly Loader probing location:
>> > '/opt/mono-3.0.5/lib/mono/4.5/mscorlib.dll'.
>> > Mono: Assembly Loader loaded assembly from location:
>> > '/opt/mono-3.0.5/lib/mono/4.5/mscorlib.dll'.
>> > Mono: Assembly mscorlib[0x14ce2c70] added to domain
>> > ConsoleApplication1.exe, ref_count=1
>> > Mono: Assembly Loader probing location: 'ConsoleApplication1.exe'.
>> > Mono: Image addref ConsoleApplication1[0x14d20230] ->
>> > /var/www/sites/erik/monoconsole/ConsoleApplication1.exe[0x14d1f4a0]: 2
>> > Mono: Assembly ConsoleApplication1[0x14d20230] added to domain
>> > ConsoleApplication1.exe, ref_count=1
>> > Mono: Assembly Loader loaded assembly from location:
>> > 'ConsoleApplication1.exe'.
>> > Mono: Assembly Loader probing location: 'ConsoleApplication1.exe'.
>> > Mono: Assembly Ref addref ConsoleApplication1[0x14d20230] ->
>> > mscorlib[0x14ce2c70]: 2
>> > Mono: Assembly Loader probing location:
>> > '/var/www/sites/erik/monoconsole/Autofac.dll'.
>> > Mono: Image addref Autofac[0x14d269b0] ->
>> > /var/www/sites/erik/monoconsole/Autofac.dll[0x14d25c40]: 2
>> > Mono: Assembly Autofac[0x14d269b0] added to domain
>> > ConsoleApplication1.exe, ref_count=1
>> > Mono: Assembly Loader loaded assembly from location:
>> > '/var/www/sites/erik/monoconsole/Autofac.dll'.
>> > Mono: Assembly Ref addref ConsoleApplication1[0x14d20230] ->
>> > Autofac[0x14d269b0]: 2
>> > Mono: The request to load the retargetable assembly mscorlib
>> v2.0.5.0
>> > was remapped to mscorlib v4.0.0.0
>> > Mono: Assembly Ref addref Autofac[0x14d269b0] ->
>> mscorlib[0x14ce2c70]: 3
>> > Mono: The request to load the retargetable assembly System.Core
>> v2.0.5.0
>> > was remapped to System.Core v4.0.0.0
>> > Mono: Assembly Loader probing location:
>> >
>> '/opt/mono-3.0.5/lib/mono/gac/System.Core/4.0.0.0__7cec85d7bea7798e/System.Core.dll'.
>> > Mono: Assembly Loader probing location:
>> > '/var/www/sites/erik/monoconsole/System.Core.dll'.
>> > Mono: Assembly Loader probing location:
>> > '/opt/mono-3.0.5/lib/System.Core.dll'.
>> > Mono: Assembly Loader probing location:
>> >
>> '/opt/mono-3.0.5/lib/mono/gac/System.Core/4.0.0.0__7cec85d7bea7798e/System.Core.exe'.
>> > Mono: Assembly Loader probing location:
>> > '/var/www/sites/erik/monoconsole/System.Core.exe'.
>> > Mono: Assembly Loader probing location:
>> > '/opt/mono-3.0.5/lib/System.Core.exe'.
>> > Mono: The following assembly referenced from
>> > /var/www/sites/erik/monoconsole/Autofac.dll could not be loaded:
>> >  Assembly:   System.Core(assemblyref_index=1)
>> >  Version:2.0.5.0
>> >  Public Key: 7cec85d7bea7798e
>> > The assembly was not found in the Global Assembly Cache, a path
>> listed
>> > in the MONO_PATH environment variable, or in the l

Re: [Mono-list] Autofac 3.0.1 on Mono 3.0.5

[Rodrigo Kumpera]

Are you trying to compile a PCL version of this lib? Mono doesn't support
PCL.


On Fri, Mar 1, 2013 at 8:25 AM, Alan  wrote:

> This should be fixed by updating your mono to 3.0.6 or higher.
>
> Thanks,
> Alan
>
> On 27 February 2013 13:34, Erik Schierboom  wrote:
> > I have been trying to get Autofac 3.0.1 working on Mono, but have so far
> > been unsuccessful. When I try to run an application that references
> Autofac
> > 3.0.1 on Mono 3.0.5, I get the following exception:
> >
> > Mono: Assembly Loader probing location:
> > '/opt/mono-3.0.5/lib/mono/4.5/mscorlib.dll'.
> > Mono: Image addref mscorlib[0x14ce2c70] ->
> > /opt/mono-3.0.5/lib/mono/4.5/mscorlib.dll[0x14ce1ec0]: 2
> > Mono: Assembly Loader probing location:
> > '/opt/mono-3.0.5/lib/mono/4.5/mscorlib.dll'.
> > Mono: Assembly Loader loaded assembly from location:
> > '/opt/mono-3.0.5/lib/mono/4.5/mscorlib.dll'.
> > Mono: Assembly mscorlib[0x14ce2c70] added to domain
> > ConsoleApplication1.exe, ref_count=1
> > Mono: Assembly Loader probing location: 'ConsoleApplication1.exe'.
> > Mono: Image addref ConsoleApplication1[0x14d20230] ->
> > /var/www/sites/erik/monoconsole/ConsoleApplication1.exe[0x14d1f4a0]: 2
> > Mono: Assembly ConsoleApplication1[0x14d20230] added to domain
> > ConsoleApplication1.exe, ref_count=1
> > Mono: Assembly Loader loaded assembly from location:
> > 'ConsoleApplication1.exe'.
> > Mono: Assembly Loader probing location: 'ConsoleApplication1.exe'.
> > Mono: Assembly Ref addref ConsoleApplication1[0x14d20230] ->
> > mscorlib[0x14ce2c70]: 2
> > Mono: Assembly Loader probing location:
> > '/var/www/sites/erik/monoconsole/Autofac.dll'.
> > Mono: Image addref Autofac[0x14d269b0] ->
> > /var/www/sites/erik/monoconsole/Autofac.dll[0x14d25c40]: 2
> > Mono: Assembly Autofac[0x14d269b0] added to domain
> > ConsoleApplication1.exe, ref_count=1
> > Mono: Assembly Loader loaded assembly from location:
> > '/var/www/sites/erik/monoconsole/Autofac.dll'.
> > Mono: Assembly Ref addref ConsoleApplication1[0x14d20230] ->
> > Autofac[0x14d269b0]: 2
> > Mono: The request to load the retargetable assembly mscorlib v2.0.5.0
> > was remapped to mscorlib v4.0.0.0
> > Mono: Assembly Ref addref Autofac[0x14d269b0] ->
> mscorlib[0x14ce2c70]: 3
> > Mono: The request to load the retargetable assembly System.Core
> v2.0.5.0
> > was remapped to System.Core v4.0.0.0
> > Mono: Assembly Loader probing location:
> >
> '/opt/mono-3.0.5/lib/mono/gac/System.Core/4.0.0.0__7cec85d7bea7798e/System.Core.dll'.
> > Mono: Assembly Loader probing location:
> > '/var/www/sites/erik/monoconsole/System.Core.dll'.
> > Mono: Assembly Loader probing location:
> > '/opt/mono-3.0.5/lib/System.Core.dll'.
> > Mono: Assembly Loader probing location:
> >
> '/opt/mono-3.0.5/lib/mono/gac/System.Core/4.0.0.0__7cec85d7bea7798e/System.Core.exe'.
> > Mono: Assembly Loader probing location:
> > '/var/www/sites/erik/monoconsole/System.Core.exe'.
> > Mono: Assembly Loader probing location:
> > '/opt/mono-3.0.5/lib/System.Core.exe'.
> > Mono: The following assembly referenced from
> > /var/www/sites/erik/monoconsole/Autofac.dll could not be loaded:
> >  Assembly:   System.Core(assemblyref_index=1)
> >  Version:2.0.5.0
> >  Public Key: 7cec85d7bea7798e
> > The assembly was not found in the Global Assembly Cache, a path
> listed
> > in the MONO_PATH environment variable, or in the location of the
> executing
> > assembly (/var/www/sites/erik/monoconsole/).
> >
> > Mono: Failed to load assembly Autofac[0x14d269b0]
> >
> > Mono: Could not load file or assembly 'System.Core, Version=2.0.5.0,
> > Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes' or
> one
> > of its dependencies.
> > Missing method .ctor in assembly
> > /var/www/sites/erik/monoconsole/Autofac.dll, type
> > System.Runtime.CompilerServices.ExtensionAttribute
> > Can't find custom attr constructor image:
> > /var/www/sites/erik/monoconsole/Autofac.dll mtoken: 0x0a15
> > Hello!
> > Mono: Unloading domain ConsoleApplication1.exe[0x2b6f1cc0],
> assembly
> > mscorlib[0x14ce2c70], ref_count=3
> > Mono: Unloading domain ConsoleApplication1.exe[0x2b6f1cc0],
> assembly
> > ConsoleApplication1[0x14d20230], ref_count=1
> > Mono: Unloading assembly ConsoleApplication1 [0x14d20230].
> > Mono: Unloading image
> > /var/www/sites/erik/monoconsole/ConsoleApplication1.exe [0x14d1f4a0].
> > Mono: Unloading domain ConsoleApplication1.exe[0x2b6f1cc0],
> assembly
> > Autofac[0x14d269b0], ref_count=1
> > Mono: Unloading assembly Autofac [0x14d269b0].
> > Mono: Unloading image /var/www/sites/erik/monoconsole/Autofac.dll
> > [0x14d25c40].
> > Mono: Unloading assembly mscorlib [0x14ce2c70].
> > Mono: Unloading image /opt/mono-3.0.5/lib/mono/4.5/mscorlib.dll
> > [0x14ce1ec0].
> >
> > There are several things to note. First, it appears 

Re: [Mono-list] Mono on Xeon Phi

[Rodrigo Kumpera]

Well, you're porting to a new archtecture, it's expected that you'll need
to fix the whole codebase to handle it.

Given the xeon-phi is not a proper x86 derivative, the porting won't be
trivial.

Good luck


On Wed, Feb 6, 2013 at 7:25 AM, Yury Serdyuk  wrote:

> **
> Rodrigo Kumpera wrote:
>
> Mono is not usually build with icc, so it might be the case that it
> doesn't support some gcc flags. Just hack your way by removing them from
> configure.in for now.
>
> I've tried to compile the problematic module without any flags at all.
> The result is the following:
>
> 2 utils]# icc -I. -I../..  -I../.. -I../../mono -I../../libgc/include
> -I../../eglib/src -I../../eglib/src -mmic -o hazard-pointer.lo
> hazard-pointer.c
> /tmp/icciSatYwas_.s: Assembler messages:
> /tmp/icciSatYwas_.s:139: Error: `sfence' is not supported on `k1om'
> /tmp/icciSatYwas_.s:517: Error: `sfence' is not supported on `k1om'
>
> The assembler output points out the problematic place inside
> hazard-pointer.c:
>
> ..B1.23:# Preds ..B1.22 Latency 1
> movl  %ebx, highest_small_id(%rip)
> #hazard-pointer.c:113.3 c1
> # Begin ASM
> sfence
> # End ASM
> #hazard-pointer.c:114.3
>
> The corresponding line 114 in hazard-pointer.c is
>
>  112  if (id > highest_small_id) {
>113  highest_small_id = id;
>114  mono_memory_write_barrier ();
>115  }
>
> Finally we have
>
> $ cat mono-membar.h
> /*
>  * mono-membar.h: Memory barrier inline functions
>  *
>  * Author:
>  *  Mark Probst (mark.pro...@gmail.com)
>  *
>  * (C) 2007 Novell, Inc
>  */
>
> #ifndef _MONO_UTILS_MONO_MEMBAR_H_
> #define _MONO_UTILS_MONO_MEMBAR_H_
>
>  .   ..
>
> static inline void mono_memory_write_barrier (void)
> {
> __asm__ __volatile__ ("sfence" : : : "memory");
> }
>
> Yury
>
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono on Xeon Phi

[Rodrigo Kumpera]

Mono is not usually build with icc, so it might be the case that it doesn't
support some gcc flags. Just hack your way by removing them from
configure.in for now.



On Tue, Feb 5, 2013 at 7:35 AM, Yury Serdyuk  wrote:

> Rodrigo Kumpera wrote:
>
>  Fix the configure script to not do the check. Look at its history for
>> cross-compilation related fixes.
>>
>>  OK,  I've commented some checks like
> 1) checking for clang
> 2) checking for preceeding underscore ...
> 3) checking for pthread
> 4) checking for sigaltstack
> So the configure is good now.
>
> Trying to make, I've got more serious error:
>
>CC mono-context.lo
>> icc: command line warning #10006: ignoring unknown option
>> '-Wno-unused-but-set-variable'
>> icc: command line warning #10006: ignoring unknown option
>> '-Wnested-externs'
>> icc: command line warning #10006: ignoring unknown option
>> '-Wno-switch-enum'
>>   CC hazard-pointer.lo
>> icc: command line warning #10006: ignoring unknown option
>> '-Wno-unused-but-set-variable'
>> icc: command line warning #10006: ignoring unknown option
>> '-Wnested-externs'
>> icc: command line warning #10006: ignoring unknown option
>> '-Wno-switch-enum'
>> /tmp/iccVlIdYwas_.s: Assembler messages:
>> /tmp/iccVlIdYwas_.s:23: Error: `sfence' is not supported on `k1om'
>> make[4]: *** [hazard-pointer.lo] Error 1
>> make[4]: Leaving directory `/home/ips_serdyuk/mono-3.0.1/**mono/utils'
>>
>
> I think that a problem place is the following function from
> hazard-pointer.c:
>
>  static gboolean
>> is_pointer_hazardous (gpointer p)
>> {
>> int i, j;
>> int highest = highest_small_id;
>>
>> g_assert (highest < hazard_table_size);
>>
>> for (i = 0; i <= highest; ++i) {
>> for (j = 0; j < HAZARD_POINTER_COUNT; ++j) {
>> if (hazard_table [i].hazard_pointers [j] == p)
>> return TRUE;
>> LOAD_LOAD_FENCE;
>> }
>> }
>>
>> return FALSE;
>> }
>>
>
>
> How about this error ?
> Are there some simple ways to workaround it?
>
> Thanks.
>
> Yury
>
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Mono on Xeon Phi

[Rodrigo Kumpera]

Fix the configure script to not do the check. Look at its history for
cross-compilation related fixes.


On Mon, Feb 4, 2013 at 5:49 AM, Yury Serdyuk  wrote:

> Hi !
>
> I have tried to do the first steps to cross-compile Mono for Intel Xeon
> Phi coprocessor.
>
> At first, I've tried to configure Mono as
>
> >./configure --prefix=<..> --host=x86_64-k1om-linux CC="icc" CFLAGS="-mmic"
>
> but I've got the error
>
>  checking for clang... configure: error: in `/home/ips_serdyuk/mono-3.0.1'
>> **:
>> configure: error: cannot run test program while cross compiling
>>
>
> The corresponding fragment of configure is
>
>  CFLAGS="$CFLAGS -g $WARN"
>> CFLAGS_FOR_LIBGC="$CFLAGS_FOR_**LIBGC -g"
>>
>> { $as_echo "$as_me:${as_lineno-$LINENO}: checking for clang" >&5
>> $as_echo_n "checking for clang... " >&6; }
>> if ${mono_cv_clang+:} false; then :
>>   $as_echo_n "(cached) " >&6
>> else
>>
>> if test "$cross_compiling" = yes; then :
>>   { { $as_echo "$as_me:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
>> $as_echo "$as_me: error: in \`$ac_pwd':" >&2;}
>> as_fn_error $? "cannot run test program while cross compiling
>> See \`config.log' for more details" "$LINENO" 5; }
>> else
>>   cat confdefs.h - <<_ACEOF >conftest.$ac_ext
>> /* end confdefs.h.  */
>>
>> int main () {
>> #ifdef __clang__
>> return 0;
>> #else
>> return 1;
>> #endif
>> }
>>
>
> The last test program is compiled with the success:
>
>  [root@node002 Xeon_Phi]# cat clang_test.c
>> int main() {
>>   #ifdef __clang__
>>return 0;
>>   #else
>>return 1;
>>   #endif
>> }[root@node002 Xeon_Phi]#icc -mmic -o clang_test clang_test.c
>> [root@node002 Xeon_Phi]#
>>
>
> Are there any suggestions how to fix above problem?
>
> Thanks.
>
> Yury
>
> __**_
> 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] Cross-compiling Mono for many platforms using single machine

[Rodrigo Kumpera]

All you need are native toolchains that cross compile to those targets,
mkbundle itself does not support
cross builds without some work, but it's not a lot. Keep in mind that to
ship mkbundled software you need a
comercial license to mono.

On Wednesday, January 30, 2013, markcoburnwa wrote:

> I am working on a project where mkbundle is used to embed the mono runtime
> into our application’s executable.  As this is the case, I need to be able
> to build mono for the various platforms we support.  I am interested in
> provisioning a single build server that will let me compile mono for a
> variety of different platforms, specifically OSX, Linux x86, Linux x64,
> Windows, and ARM.  Is this possible, and if so what tools are available?
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Cross-compiling-Mono-for-many-platforms-using-single-machine-tp4658358.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] gsharp "attach to process"

[Rodrigo Kumpera]

This has nothing to do with the debugger, it simply allows you to run a
csharp session on a target process.


On Tue, Jan 22, 2013 at 10:38 AM, Ian Norton <
ian.norton-bad...@thales-esecurity.com> wrote:

> Hello,
>
> I noticed gsharp has an "attach to process" option.  It seems to do
> "somthing" in that if I choose my mono process I see messages about the
> debugger agent in it's window.
>
> I'm wondering what it is really for and how it should be used? Is it kind
> of like an immediate window when I do that?  I'd dearly like to be able to
> attach the soft debugger from within monodevelop to an existing process (
> hopefully even an existing process already started on another linux machine
> )
>
> Best Regards
>
> Ian
> __**_
> 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] Performance of Mono 2.10 vs. Mono 3.0

[Rodrigo Kumpera]

Please file a bug report as this definitely a regression.

On Saturday, January 19, 2013, Charles Esterbrook wrote:

> Hi,
>
> I have a benchmark for my project which takes the following number of
> milliseconds to run based on System.Diagnostics.Stopwatch, expressed
> in ranges:
>
> Mono JIT compiler version 2.10.9 (tarball Mon May  7 20:25:51 EDT 2012)
> 6888 - 6943 - default gc / boehm
> 5850 - 5932 - sgen
>
> Mono JIT compiler version 3.0.3 (master/39c48d5 Tue Jan  8 12:12:24 EST
> 2013)
> 9815 - 9892 - default gc / boehm
> 8454 - 8502 - sgen
>
> My system is Mac OS X 10.6.8, Intel Xeon. I shut down web browsers,
> cloud services and other apps to reduce interference, and I also ran
> multiple times, hence the ranges.
>
> The slowdown is about 40%. My program does a variety of things
> including loading assemblies, reflection, file i/o, string processing,
> data structures, etc. I have not yet investigated to see if some parts
> are slowing down more than others.
>
> What about other people on this list? If you test the performance of
> your apps between Mono 2.10 and 3.0, is there a change? How much and
> in what direction?
>
> For your convenience:
> https://www.google.com/search?q=.net+stopwatch
>
>
> --
> Charles Esterbrook
> http://charles-esterbrook.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] AES/CFB Stream Cipher Problem

[Rodrigo Kumpera]

The bug is: https://bugzilla.xamarin.com/show_bug.cgi?id=9247


On Thu, Jan 3, 2013 at 7:54 PM, Sebastien Pouliot <
sebastien.poul...@gmail.com> wrote:

> On Thu, Jan 3, 2013 at 7:40 PM, Drew DeVault  wrote:
> > I get access denied on that bug.
>
> Sorry I had not noticed the bug to be private (I assumed only the
> attachment was).
>
> Please fill a (public) bug report and I'll close the private one as a
> duplicate (but without leaking information from it). That way everyone
> interested can  be on c.c.
>
> > As for the MS implementation, it's
>
> which one ?* the RijndaelManaged one or the AesCryptoServiceProvider
> one - because they don't match each other :-( and they should when
> Rijndael is set to use 128bits blocks.
>
> * I presume the former based your link to the source code but, right
> now (and depending on some settings), Mono is not compatible with
> either. OTOH CFB8 (eight being the only feedback size supported for
> them) works for other ciphers (e.g. DES, 3DES, RC2).
>
> > compatible with the Java implementation, at least, so it's less likely
> to be
> > incorrect.
>
> one of MS implementations must be ;-)
>
> > How should this be solved? I can't have this only work on Windows with
> > MS.NET.
>
> First step is the bug report, along with all the data that can prove
> useful.
>
> After this you can wait for a fix I'm looking into it now but I
> can't promise when it will be done (need to be careful not to regress
> the other ciphers, CFB or other modes). Mono is also open source so
> you're welcome to contribute fixes.
>
> Sebastien
>
> >
> > On Thu, Jan 3, 2013 at 3:38 PM, Sebastien Pouliot
> >  wrote:
> >>
> >> Hello Drew,
> >>
> >> There was a bug filled yesterday, #9201 [1]. You might want to c.c.
> >> yourself to it.
> >>
> >> FWIW it's not really AES related. MS implementation(s) of CFB are a bit
> >> weird.
> >>
> >> RijndaelManaged does it differently than others .NET ciphers (which is
> >> what Mono supports), including AesCryptoServiceProvider (even when the
> >> former uses a 128 bits block size).
> >>
> >> AesManaged does not even support CFB (even if it was, once upon a
> >> time, documented as a wrapper on top of RijndaelManaged).
> >>
> >> Sebastien
> >>
> >> [1] https://bugzilla.xamarin.com/show_bug.cgi?id=9201
> >>
> >> On Thu, Jan 3, 2013 at 4:55 PM, Rodrigo Kumpera 
> wrote:
> >> > Please file a bug in bugzilla.xamarin.com with a test case.
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Jan 1, 2013 at 11:00 PM, Drew DeVault 
> >> > wrote:
> >> >>
> >> >> I'm having an issue with Mono that does not appear on Microsoft.NET,
> >> >> related to AES/CFB encryption with no padding. Firstly, here's my
> Mono
> >> >> version:
> >> >>
> >> >> Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-1ubuntu2.2)
> >> >> Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors.
> >> >> www.mono-project.com
> >> >> TLS:   __thread
> >> >> SIGSEGV:   altstack
> >> >> Notifications: epoll
> >> >> Architecture:  amd64
> >> >> Disabled:  none
> >> >> Misc:  softdebug
> >> >> LLVM:  supported, not enabled.
> >> >> GC:Included Boehm (with typed GC and Parallel
> Mark)
> >> >>
> >> >> Secondly, I would like to find a solution that does indeed work on
> this
> >> >> version of Mono, because most of my users are on the same version.
> The
> >> >> problem comes
> >> >> from using a CryptoStream with a RijndaelManaged cipher. I have
> >> >> attached a
> >> >> proof of concept to the email, along with the results of running it
> on
> >> >> Windows with
> >> >> Microsoft.NET and on Linux Mint 12 with Mono.
> >> >>
> >> >> The AesStream in the example comes from this project:
> >> >>
> >> >>
> https://github.com/SirCmpwn/Craft.Net/blob/master/Craft.Net/AesStream.cs
> >> >>
> >> >> In short, on Microsoft.NET, writing to the CryptoStream does indeed
> >> >> encrypt the data properly, where on Mono, no data is written, and an
> >> >> IndexOutOfBoundsException is thrown when trying to read the encrypted
> >> >> data.
> >> >>
> >> >> Drew DeVault
> >> >>
> >> >> ___
> >> >> 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] Mono 3.0 on CentOS 6.3

[Rodrigo Kumpera]

You have a broken installation. Use packages appropriate for your
distro/version or build from sources.


On Thu, Dec 27, 2012 at 7:36 PM, Lorenzo Lione wrote:

> I'm trying to run mono 3.0 on CentOS 6.3 but when I try to launch mono I
> receive this error:
>
> mono: /lib/libc.so.6: Version 'GLIBC 2.15' not found (required for mono)
>
> On CentOS 6.3 is installed glibc2-2.22, how can I solve this problem?
>
> Thank you all for your support.
>
> L
>
> -
>
> Lorenzo Lione
> Senior Systems Engineer
>
> Cell. : +39 (347) 8595000
>
> --
>
> Remote Italia S.r.l.
> Via Domenico Chelini, 4 - 00197 - Roma
> Tel : +39 (06) 8078775 - Fax : +39 (06) 8078884
> P.Iva/VAT id : IT08824611001
>
> ___
> 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] AES/CFB Stream Cipher Problem

[Rodrigo Kumpera]

Please file a bug in bugzilla.xamarin.com with a test case.




On Tue, Jan 1, 2013 at 11:00 PM, Drew DeVault  wrote:

> I'm having an issue with Mono that does not appear on Microsoft.NET,
> related to AES/CFB encryption with no padding. Firstly, here's my Mono
> version:
>
> Mono JIT compiler version 2.10.8.1 (Debian 2.10.8.1-1ubuntu2.2)
> Copyright (C) 2002-2011 Novell, Inc, Xamarin, Inc and Contributors.
> www.mono-project.com
> TLS:   __thread
> SIGSEGV:   altstack
> Notifications: epoll
> Architecture:  amd64
> Disabled:  none
> Misc:  softdebug
> LLVM:  supported, not enabled.
> GC:Included Boehm (with typed GC and Parallel Mark)
>
> Secondly, I would like to find a solution that does indeed work on this
> version of Mono, because most of my users are on the same version. The
> problem comes
> from using a CryptoStream with a RijndaelManaged cipher. I have attached a
> proof of concept to the email, along with the results of running it on
> Windows with
> Microsoft.NET and on Linux Mint 12 with Mono.
>
> The AesStream in the example comes from this project:
> https://github.com/SirCmpwn/**Craft.Net/blob/master/Craft.**
> Net/AesStream.cs
>
> In short, on Microsoft.NET, writing to the CryptoStream does indeed
> encrypt the data properly, where on Mono, no data is written, and an
> IndexOutOfBoundsException is thrown when trying to read the encrypted data.
>
> Drew DeVault
>
> ___
> 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] Memory profiler for Mono-1.9.1

[Rodrigo Kumpera]

You can try to backport heapshot to 1.9.1. Mind that this is an ancient
version of mono
with very little chance of having it working.


On Tue, Dec 4, 2012 at 3:49 PM, rchandrashekara <
raghavendra.chandrashek...@gmail.com> wrote:

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

Re: [Mono-list] Mono on ARM Chromebook

[Rodrigo Kumpera]

Mono doesn't support the hardfp ABI used by ubuntu.

On Saturday, December 1, 2012, Hall72215 wrote:

> I have installed ChrUbuntu on my new ARM Chromebook, and was interested in
> running a .NET WinForms app (KeyPass).  So, I did "apt-get install
> mono-complete" and tried to run it, but it crashes.  To make sure that mono
> wasn't completely broken, I made a program that just wrote "Success" to the
> console, and it worked.  Next, I made a "hello world" winforms app (just a
> form with a button), compiled it, and ran it.  It crashed with the exact
> same error as KeyPass.  So then I ran "mono --version", and saw that the
> architecture said armel.  The Chromebook is armhf, so I thought all I
> needed
> to do was download the source and compile it myself.  But then I found out
> that hard float ARM isn't supported yet.  Can I assume that the
> architecture
> mismatch is the problem?  Any idea on when armhf will be supported?
>
> Here's the top of the stack trace:
> Stacktrace:
>
>   at System.Drawing.Font.CreateFont
>
> (string,single,System.Drawing.FontStyle,System.Drawing.GraphicsUnit,byte,bool)
> <0x0013f>
>   at System.Drawing.Font..ctor
>
> (string,single,System.Drawing.FontStyle,System.Drawing.GraphicsUnit,byte,bool)
> <0x0007f>
>   at System.Drawing.Font..ctor (string,single,string) <0x00057>
>   at (wrapper remoting-invoke-with-check) System.Drawing.Font..ctor
> (string,single,string) <0x>
>   at System.Drawing.SystemFonts.get_DefaultFont () <0x0005b>
>
> And here's what gdb found:
> Debug info from gdb:
>
> Cannot access memory at address 0x616a653c
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library
> "/lib/arm-linux-gnueabihf/libthread_db.so.1".
> [New Thread 0x746ff460 (LWP 2483)]
> [New Thread 0x750c4460 (LWP 2481)]
> [New Thread 0x768a1460 (LWP 2480)]
> 0x76f393a0 in read () from /lib/arm-linux-gnueabihf/libpthread.so.0
>   Id   Target Id Frame
>   4Thread 0x768a1460 (LWP 2480) "mono" 0x76f3b384 in __libc_do_syscall
> () from /lib/arm-linux-gnueabihf/libpthread.so.0
>   3Thread 0x750c4460 (LWP 2481) "dconf worker" 0x76e50276 in ?? () from
> /lib/arm-linux-gnueabihf/libc.so.6
>   2Thread 0x746ff460 (LWP 2483) "gdbus" 0x76e50276 in ?? () from
> /lib/arm-linux-gnueabihf/libc.so.6
> * 1Thread 0x76ff6000 (LWP 2479) "mono" 0x76f393a0 in read () from
> /lib/arm-linux-gnueabihf/libpthread.so.0
>
> Thread 4 (Thread 0x768a1460 (LWP 2480)):
> #0  0x76f3b384 in __libc_do_syscall () from
> /lib/arm-linux-gnueabihf/libpthread.so.0
> #1  0x76f386da in do_futex_wait () from
> /lib/arm-linux-gnueabihf/libpthread.so.0
> #2  0x76f38756 in sem_wait@@GLIBC_2.4 () from
> /lib/arm-linux-gnueabihf/libpthread.so.0
> #3  0x001155dc in mono_sem_wait ()
> #4  0x000a5b10 in ?? ()
> #5  0x000a5b10 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Thread 3 (Thread 0x750c4460 (LWP 2481)):
> #0  0x76e50276 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
> #1  0x76ec11e8 in poll () from /lib/arm-linux-gnueabihf/libc.so.6
> #2  0x75c3f22e in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
> #3  0x75c3f22e in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Thread 2 (Thread 0x746ff460 (LWP 2483)):
> #0  0x76e50276 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6
> #1  0x76ec11e8 in poll () from /lib/arm-linux-gnueabihf/libc.so.6
> #2  0x75c3f22e in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
> #3  0x75c3f22e in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> Thread 1 (Thread 0x76ff6000 (LWP 2479)):
> #0  0x76f393a0 in read () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #1  0x76f39394 in read () from /lib/arm-linux-gnueabihf/libpthread.so.0
> #2  0x7ea49e70 in ?? ()
>
> =
> Got a SIGSEGV while executing native code. This usually indicates a fatal
> error in the mono runtime or one of the native libraries used by your
> application.
> =
>
> Thanks,
> Sean
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Mono-on-ARM-Chromebook-tp4657617.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] Mono-list Digest, Vol 91, Issue 29

[Rodrigo Kumpera]

Install X11 on your mac.


On Thu, Nov 29, 2012 at 12:24 PM, jeff clausius wrote:

>
> Also, just tried this suggestion against the 3.0.1 Mono release.  This
> presents a whole different set of problems:
>
> Unhandled Exception:
> System.TypeInitializationException: An exception was thrown by the type
> initializer for System.Windows.Forms.XplatUI --->
> System.DllNotFoundException: libX11.dylib
>   at (wrapper managed-to-native)
> System.Windows.Forms.XplatUIX11:XInitThreads ()
>   at System.Windows.Forms.XplatUIX11..ctor () [0x0] in  unknown>:0
>   at System.Windows.Forms.XplatUIX11.GetInstance () [0x0] in
> :0
>   at System.Windows.Forms.XplatUI..cctor () [0x0] in  unknown>:0
>   --- End of inner exception stack trace ---
>   at System.Windows.Forms.Application.EnableVisualStyles () [0x0] in
> :0
>   at WindowsFormsApplicationMono1.Program.Main () [0x0] in  unknown>:0
> [ERROR] FATAL UNHANDLED EXCEPTION: System.TypeInitializationException:
> An exception was thrown by the type initializer for
> System.Windows.Forms.XplatUI ---> System.DllNotFoundException: libX11.dylib
>   at (wrapper managed-to-native)
> System.Windows.Forms.XplatUIX11:XInitThreads ()
>   at System.Windows.Forms.XplatUIX11..ctor () [0x0] in  unknown>:0
>   at System.Windows.Forms.XplatUIX11.GetInstance () [0x0] in
> :0
>   at System.Windows.Forms.XplatUI..cctor () [0x0] in  unknown>:0
>   --- End of inner exception stack trace ---
>   at System.Windows.Forms.Application.EnableVisualStyles () [0x0] in
> :0
>   at WindowsFormsApplicationMono1.Program.Main () [0x0] in  unknown>:0
>
> I will be looking into ways around the "libX11.dylib" issue.  Symlink
> perhaps?
>
> Jeff
>
> On 11/28/2012 6:00 AM, mono-list-requ...@lists.ximian.com wrote:
> > WinForms works the worst on Mac. Although I don't have a Mac, I
> recommend the
> > users of my WinForms app to run their app this way, and it seems to work
> > fine for them: "MONO_MWF_MAC_FORCE_X11=1 mono yourapp.exe"
> > That makes it so it runs the app using the X11 driver rather than the Mac
> > (Carbon) one, which means the app should work as well as on Linux. The
> only
> > problem is that it requires an X11 server to be installed on the Mac.
> ___
> 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] Mono 3.0.1 - release notes?

[Rodrigo Kumpera]

There are only bug fixes or minor changes on 3.0.1


On Tue, Nov 13, 2012 at 5:19 AM, Dimitar Dobrev  wrote:

> Hi,
>
> The page for the release notes of Mono 3.0.1 is empty, what has changed?
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Mono-3-0-1-release-notes-tp4657347.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] Where is the source of libgdiplus-3.0.tar.gz

[Rodrigo Kumpera]

Mono 3.0 is the new stable series for mono, it features about two years of
feature work and all stability work that 2.10 has.

2.10 support will be discontinued earlier next year and our focus will
switch 100% to 3.0.

You can say that 2.10 is stabler now as it has been under bug fixing only
for a very very long time but doing so ignores
where we're moving to. It doesn't make sense to start with 2.10 now as in a
few months it's a release branch that will die.

We'll look into the 3.0 libgdiplus packaging issue. Thanks for pointing it
our.



On Mon, Nov 5, 2012 at 2:18 AM, Daniel Isenmann wrote:

>  This isn't really an option. If you try to package mono 3 and you don't
> have a tarball of the 3.0 source code, this is really annoying.
>
> Even on the download page mono 3.0 is stated as beta and MacOSX only
> release. There is no clear statement that mono 3.0 is the new stable
> release and should be used instead of mono 2.10.x!
>
> Would be great if there is a clear statement of the mono developers if
> it's a stable release or not, as a packager (like me for Arch Linux, I'm
> the mono maintainer) it's really hard to follow the stable release series
> here. Since Xamarin took over the development, the webpage of the
> mono-project is rarely updated with the necessary information! Please
> change this! I want really support mono and I want really package it to
> deliver the latest mono release to our users.
>
> My 2 cent to the release politics!
>
> Daniel
>
>
> Am 04.11.2012 23:17, schrieb Daniel Lo Nigro:
>
> Try grabbing the master branch from Github:
> https://github.com/mono/libgdiplus/archive/master.tar.gz
>
>  This will have the latest code (and should therefore be compatible with
> Mono 3.0)
>
>
> On Mon, Nov 5, 2012 at 8:00 AM, Akira Sonoda wrote:
>
>> Hello,
>>
>> As described in the Mono 3.0 Releasenotes:
>> http://www.mono-project.com/Release_Notes_Mono_3.0
>>
>> Mono 3.0 can be built from source. But i am failing at the first step:
>>
>> Compile libgdiplus to support System.Drawing:
>>
>> $ tar xzf libgdiplus-3.0.tar.gz
>>
>>
>> Where is libgdiplus-3.0.tar.gz? Here it does not show up:
>> http://download.mono-project.com/sources/libgdiplus/
>>
>> Regards,
>> Akira
>>
>> ___
>> Mono-list maillist  -  Mono-list@lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-list
>>
>>
>
>
> ___
> Mono-list maillist  -  
> Mono-list@lists.ximian.comhttp://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 maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] C++ interop with Mono

[Rodrigo Kumpera]

Mono supports a pretty complete p/invoke implementation. Even upporting
more options that .NET in some cases.

You can try CXXI or COM support on mac as the code is there and it's a
matter of using a COM middleware available there.


On Sat, Nov 3, 2012 at 12:07 PM, obiwanjacobi wrote:

> Thought of something else...
>
> Does Mono support CRL/COM Callable Wrappers?
>
> The reason I ask is because the C++ interfaces are modeled after the COM
> standard. It even has a binary compatible IUnknown...
>
> Question is would that work on a non-windows machine...?
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/C-interop-with-Mono-tp4657239p4657242.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] How can I get line numbers on MonoMac app stack traces?

[Rodrigo Kumpera]

No, It's MONO_ENV_OPTIONS.


On Fri, Nov 2, 2012 at 7:50 AM, Andres G. Aragoneses wrote:

>
> Should be MONO_OPTIONS, not MONO_ENV_OPTIONS, right?
>
>
>
> On 01/11/12 21:29, Maurício Linhares wrote:
>
>> No deal:
>>
>> ➜  winclient git:(develop) ✗ export MONO_ENV_OPTIONS="--debug"
>> ➜  winclient git:(develop) ✗ ./Sync.app/Contents/MacOS/Sync
>>
>> Unhandled Exception: System.Reflection.**TargetInvocationException:
>> Exception has been thrown by the target of an invocation. --->
>> System.Exception: I am going to crash now.
>>at Sync.MacConfiguration..ctor (System.String destinationPath,
>> IDatabasePathGenerator pathGenerator) [0x0] in :0
>>at Sync.MacConfiguration..ctor () [0x0] in :0
>>at (wrapper managed-to-native)
>> System.Reflection.MonoCMethod:**InternalInvoke
>> (System.Reflection.**MonoCMethod,object,object[],**System.Exception&)
>>at System.Reflection.MonoCMethod.**Invoke (System.Object obj,
>> BindingFlags invokeAttr, System.Reflection.Binder binder,
>> System.Object[] parameters, System.Globalization.**CultureInfo culture)
>> [0x0] in :0
>>--- End of inner exception stack trace ---
>> at System.Reflection.MonoCMethod.**Invoke
>> (object,System.Reflection.**BindingFlags,System.**
>> Reflection.Binder,object[],**System.Globalization.**CultureInfo)
>> <0x001f3>
>> at System.Reflection.MonoCMethod.**Invoke
>> (System.Reflection.**BindingFlags,System.**Reflection.Binder,object[],**
>> System.Globalization.**CultureInfo)
>> <0x00024>
>> at System.Reflection.**ConstructorInfo.Invoke (object[]) <0x00042>
>> at System.Activator.**CreateInstance (System.Type,bool) <0x001d3>
>> at System.Activator.**CreateInstance (System.Type) <0x00013>
>> at Sync.ConfigurationSection.get_**Configuration () <0x00043>
>> at Sync.Configuration.LoadFromXML (string) <0x000cf>
>> at Sync.Configuration.get_Default () <0x0005f>
>> at Sync.Mac.AppDelegate..ctor () <0x00037>
>> at (wrapper dynamic-method) object.f57e4aeb-6b60-4541-**bc56-c7326f76297f
>> (intptr,MonoMac.ObjCRuntime.**Selector) <0x00057>
>> at (wrapper native-to-managed)
>> object.f57e4aeb-6b60-4541-**bc56-c7326f76297f
>> (intptr,MonoMac.ObjCRuntime.**Selector) <0x0006f>
>> at (wrapper managed-to-native)
>> MonoMac.AppKit.NSApplication.**NSApplicationMain (int,string[]) <0x3>
>> at MonoMac.AppKit.NSApplication.**Main (string[]) <0x0003f>
>> at Sync.Mac.MainClass.Main (string[]) <0x000e7>
>>
>> -
>> Maurício Linhares
>> http://techbot.me/ - 
>> http://twitter.com/#!/**mauriciojr<http://twitter.com/#!/mauriciojr>
>>
>>
>> On Thu, Nov 1, 2012 at 5:23 PM, Rodrigo Kumpera > <mailto:kump...@gmail.com>> wrote:
>>
>> Run with --debug
>>
>>
>> On Thu, Nov 1, 2012 at 5:06 PM, Maurício Linhares
>> > <mailto:mauricio.linhares@**gmail.com
>> >>
>>
>> wrote:
>>
>> I'm most likely doing something really stupid here, but I can't
>> find a way to get line numbers on my stack traces.
>>
>> I have manually added the ".mdb" files to the
>> "Contents/MonoBundle" folder (so they're at the same folder as
>> the DLLs) but still can't get it to work.
>>
>> Am I missing something here?
>>
>> -
>> Maurício Linhares
>> http://techbot.me/ - 
>> http://twitter.com/#!/**mauriciojr<http://twitter.com/#!/mauriciojr>
>>
>> __**_
>> Mono-list maillist  - Mono-list@lists.ximian.com
>> <mailto:Mono-list@lists.**ximian.com 
>> >
>> 
>> http://lists.ximian.com/**mailman/listinfo/mono-list<http://lists.ximian.com/mailman/listinfo/mono-list>
>>
>>
>>
>>
>>
>>
>> __**_
>> Mono-list maillist  -  Mono-list@lists.ximian.com
>> http://lists.ximian.com/**mailman/listinfo/mono-list<http://lists.ximian.com/mailman/listinfo/mono-list>
>>
>>
>
> __**_
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/**mailman/listinfo/mono-list<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] How can I get line numbers on MonoMac app stack traces?

[Rodrigo Kumpera]

Run with --debug


On Thu, Nov 1, 2012 at 5:06 PM, Maurício Linhares <
mauricio.linha...@gmail.com> wrote:

> I'm most likely doing something really stupid here, but I can't find a way
> to get line numbers on my stack traces.
>
> I have manually added the ".mdb" files to the "Contents/MonoBundle" folder
> (so they're at the same folder as the DLLs) but still can't get it to work.
>
> Am I missing something here?
>
> -
> Maurício Linhares
> http://techbot.me/ - http://twitter.com/#!/mauriciojr
>
> ___
> 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] Right way to detect if SGEN is available?

[Rodrigo Kumpera]

On Sun, Oct 21, 2012 at 5:43 PM, Ben  wrote:

>
> I know SGEN is not available on all systems. We'd like to look again at
> using it by default when compiling and running the F# compiler.
>
> Is there a "right" way to probe to see if SGEN is supported? Do we just
> look for mono-sgen in the path? If SGEN is not supported, will mono-sgen
> still exist?
>

mono-sgen won't be generated if the target doesn't support it, so checking
for it is the right way to do it. Using mono --sgen will instead
fail at execution time.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Problem with LLVM + AOT

[Rodrigo Kumpera]

Hey,

Can you try it with --aot=asmwriter?

On Mon, Oct 15, 2012 at 9:23 AM, mridoni  wrote:

> Hello, I downloaded the last 2.11.4 tarball and compiled it, enabling the
> LLVM support. My LLVM install comes from the 2012-10-11 branch on github.
>
> I installed LLVM in /opt/mono-llvm and added the bin and lib subdirs to
> PATH
> and LD_LIBRARY_PATH (don't know if the latter is actually needed). Mono
> 2.1..4 is already in the path.
>
> I wrote a small "hello world app" and compiled it with:
>
> gmcs test.cs
>
> Then I try to AOT it:
>
> debian:~/test# mono --llvm --aot test.exe
> Mono Ahead of Time compiler - compiling assembly /root/test/test.exe
> * Assertion at image-writer.c:2177, condition `fp' not met
>
> Stacktrace:
>
>
> Native stacktrace:
>
> mono() [0x80e55f9]
> [0xb777640c]
> /lib/i686/cmov/libc.so.6(abort+0x182) [0xb7603b82]
> mono() [0x824ce85]
> mono() [0x824ced4]
> mono() [0x80f6f2e]
> mono() [0x80cf44a]
> mono(mono_main+0x1523) [0x80bde93]
> mono() [0x8059698]
> /lib/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xb75ecc76]
> mono() [0x80594c1]
>
> If I run it without "--llvm" it works ait should:
>
> debian:~/test# mono --aot test.exe
> Mono Ahead of Time compiler - compiling assembly /root/test/test.exe
> Code: 68 Info: 5 Ex Info: 10 Unwind Info: 17 Class Info: 34 PLT: 2 GOT
> Info:
> 12 GOT: 24 Offsets: 48
> Compiled 2 out of 2 methods (100%)
> Methods without GOT slots: 1 (50%)
> Direct calls: 0 (100%)
> JIT time: 0 ms, Generation time: 17 ms, Assembly+Link time: 7 ms.
>
> Should I go back to some non-blleding-edge version or am I missing
> something
> obvious? BTW: the assertion at line 2177 complains about a file pointer
> being NULL, but at this point I know too little about Mno's internals.
>
> Thanks
>
>
> Marco Ridoni
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Problem-with-LLVM-AOT-tp4656966.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] How stable is SGEN in Mono 2.10.9 and Mono 2.11?

[Rodrigo Kumpera]

On Wed, Oct 10, 2012 at 9:47 AM, Ben  wrote:

>
> I'm working on F# support for Mono
>
> How stable is SGEN? The F# compiler runs 50% faster with it and haven't
> seen any problems so far
>

I'm always happy to know that sgen is faster than boehm on some workload.

Do you think SGEN is
>   (a) not to be trusted at all yet
>   (b) stable enough to use in the bootstrap process (where only people
> bootstrapping the compiler itself would use it)
>   (c) stable enough to use by default for anyone using the compiler?
>
> I guess the answers could be different for 2.10.9 and 2.11.
>
>
Sgen is not as solid as boehm since it did not receive a decade of
bugfixing and testing. So, if you need rock solid
stability over anything else, boehm is the right choice today.

Said that, sgen did receive a humongous amount of testing and stabilization
work over the past 18 months that I say
it should be stable to use by anyone. Sgen is the only GC available on
Xamarin's Android product, for example.

I suggest that you should use it and, if you find bugs, file them as they
will be fixed.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Addresses marked as ??? in Valgrind stack trace

[Rodrigo Kumpera]

On Tue, Oct 9, 2012 at 12:40 PM, Kerrick Staley wrote:

> On Thu, Oct 4, 2012 at 1:40 PM, Tom Hughes  wrote:
> > The "mono_jit_runtime_invoke" is a big clue - those will be run time
> > generated code that the JIT has created so they won't be in the symbol
> table.
>
> Ah, that makes a lot more sense than my theory.
>
> On Thu, Oct 4, 2012 at 1:50 PM, Philippe Waroquiers
>  wrote:
> > If that is effectively the case, have you given
> > the argument --smc-check=all (or =all-non-file) ?
> > One of these two is for sure mandatory in a JITted env (on x86/amd64
> > at least).
>
> Yes, I'm passing this argument.
>
> > Otherwise, you might always try using gdb/vgdb to connect to the process
> > under Valgrind when the error is raised : gdb might maybe help
> > to see what is going on.
>
> You mean I should use --db-attach=yes (as Greg suggested)?
>
> On Thu, Oct 4, 2012 at 5:38 PM, Gregory Junker  wrote:
> > Well, for starters, you can look at what line 5791 in mini.c is doing:
> >
> > https://github.com/mono/mono/blob/master/mono/mini/mini.c
>
> Not everyone runs master :)
>
> https://github.com/mono/mono/blob/mono-2-10-9/mono/mini/mini.c#L5791
>
> It looks like the line is calling runtime_invoke, which means it's
> running JIT code (as others suggested).
>
> > One thing you can do with Valgrind is have it break to debugger on
> errors,
> > by supplying the --attach-db=yes option. If you still can't get function
> > names in GDB, you may be able to get module names (the addresses look to
> be
> > in different modules than the Mono runtime), and from there you might
> have
> > to get your hands dirty with nm or objdump.
>
> OK, I'll try seeing what I can turn up with gdb. Initial results
> aren't promising; when I try the disassemble command at the site of
> the error, it tells me "No function contains program counter for
> selected frame".
>
> On Fri, Oct 5, 2012 at 1:11 PM, Rodrigo Kumpera  wrote:
> > Mono features a JIT that dynamically generates code and those unknown
> frames
> > are precisely that.
> > Look at the man page to see how to enable valgrind integration to show
> > actual names instead.
>
> Per the manpage, I tried setting MONO_XDEBUG=true and passing
> --debug=gdb to Mono; neither caused the ???'s to be replaced with
> useful information. Mono generated an xdb.il and an xdb.s file when I
> did this, but it doesn't seem like GDB can use these files. I'm going
> to see if I can get anywhere with the --aot flag (enabling
> ahead-of-time compilation).
>
> I also noticed this blog post describing Valgrind integration for Mono:
>
> http://tirania.org/blog/archive/2007/Jun-29.html


Valgrind support does exist in mono for a few years, you just need to make
sure that
your mono build has detected and enabled it correctly.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] Addresses marked as ??? in Valgrind stack trace

[Rodrigo Kumpera]

Mono features a JIT that dynamically generates code and those unknown
frames are precisely that.
Look at the man page to see how to enable valgrind integration to show
actual names instead.

On Thu, Oct 4, 2012 at 2:19 PM, Kerrick Staley wrote:

> Hello,
>
> I'm running Valgrind on Mono as it executes a C# program. The C# program
> in question invokes several native routines in several different shared
> object files, and it's crashing in one of these native routines. The
> following is a snippet from Valgrind's output:
>
> ==3652== Thread 5:
> ==3652== Conditional jump or move depends on uninitialised value(s)
> ==3652==at 0xA55A385: ???
> ==3652==by 0xA55A1F7: ???
> ==3652==by 0x78C8074: ???
> ==3652==by 0x8064415: mono_jit_runtime_invoke (mini.c:5791)
> ==3652==by 0x81AF4EE: mono_runtime_invoke (object.c:2755)
> ==3652==by 0x81AF8F3: mono_runtime_delegate_invoke (object.c:3420)
> ==3652==by 0x8202FEB: start_wrapper (threads.c:790)
> ==3652==by 0x82305EE: thread_start_routine (wthreads.c:287)
> ==3652==by 0x416FD5D: clone (clone.S:130)
> ==3652==
> ==3652== Invalid read of size 4
> ==3652==at 0xA55A543: ???
> ==3652==by 0xA55A1F7: ???
> ==3652==by 0x78C8074: ???
> ==3652==by 0x8064415: mono_jit_runtime_invoke (mini.c:5791)
> ==3652==by 0x81AF4EE: mono_runtime_invoke (object.c:2755)
> ==3652==by 0x81AF8F3: mono_runtime_delegate_invoke (object.c:3420)
> ==3652==by 0x8202FEB: start_wrapper (threads.c:790)
> ==3652==by 0x82305EE: thread_start_routine (wthreads.c:287)
> ==3652==by 0x416FD5D: clone (clone.S:130)
> ==3652==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
> ==3652==
> ==3652== Thread 5 return signal frame corrupted.  Killing process.
> ==3652==
> ==3652== Process terminating with default action of signal 11 (SIGSEGV)
> ==3652==  General Protection Fault
> ==3652==at 0x408F655: ??? (in /lib/libpthread-2.11.3.so)
> ==3652==by 0xA55A1F7: ???
> ==3652==by 0x78C8074: ???
> ==3652==by 0x8064415: mono_jit_runtime_invoke (mini.c:5791)
> ==3652==by 0x81AF4EE: mono_runtime_invoke (object.c:2755)
> ==3652==by 0x81AF8F3: mono_runtime_delegate_invoke (object.c:3420)
> ==3652==by 0x8202FEB: start_wrapper (threads.c:790)
> ==3652==by 0x82305EE: thread_start_routine (wthreads.c:287)
> ==3652==by 0x416FD5D: clone (clone.S:130)
>
> I can't track down the error since the stack trace doesn't indicate which
> shared object and function it occurs in.
>
> According to http://valgrind.org/docs/manual/faq.html#faq.unhelpful, if a
> shared object is unloaded before the program terminates, ??? entries will
> appear in the stack trace, so I'm guessing that Mono is dynamically
> unloading the shared object after the segfault. I'm unsure as to whether
> this hunch even makes sense, though. Is there anything I can do on either
> the Valgrind or the Mono side to get more information from the stack trace?
>
> Thanks,
> Kerrick
>
> ___
> 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] Mono Sqlite driver leaking file handles

[Rodrigo Kumpera]

Consts.cs is a generated file by the whole runtime build process. If you
have the whole thing configured, just hit make.




On Mon, Sep 17, 2012 at 2:03 PM, Maurício Linhares <
mauricio.linha...@gmail.com> wrote:

> Hello guys,
>
> I just found myself suffering from this bug -
> https://bugzilla.xamarin.com/show_bug.cgi?id=2915 and wanted to debug it
> and see if I could fix it myself.
>
> I cloned the Mono repo from github and tried to open the SQLite driver
> piece and the project doesn't compile due to a missing "Consts.cs" file:
>
> Error CS2001: Source file
> `/Users/mauricio/projects/mono/mono/mcs/build/common/Consts.cs' could not
> be found (CS2001) (Mono.Data.Sqlite-net_4_0)
>
> Should this file be here somewhere? Is it a generated file?
>
> -
> Maurício Linhares
> http://mauricio.github.com/ - http://twitter.com/#!/mauriciojr
>
>
>
> ___
> 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] How does mono translated into C++ Native Code in Linux

[Rodrigo Kumpera]

P/invoke can only call C functions, so you need to wrap it an "extern C"
function.

Beyond that, mono will not marshal the AutoReset Event into something
usable to you,
so my suggestion is to pass a delegate that does it for you.


On Fri, Sep 14, 2012 at 4:33 PM, John Chen  wrote:

> Hi,
> I need to call Natvie Linux C++ code with a Pinvoke and passing a AutoReset
> Event, my problem is I do not know what  Mono translate the AutoReset Event
> handler . I need to find out how to be able to signal the AutoReset Event
> from C++.
>
> Please advice.
> Thanks in advice.
> John
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/How-does-mono-translated-into-C-Native-Code-in-Linux-tp4656633.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] C++/CLI Support

[Rodrigo Kumpera]

On Mon, Sep 10, 2012 at 7:21 PM, kpedersen  wrote:

> >> There are a bunch of thorny issues to consider.
>
> Heh, I would imagine ;)
>
> I would not expect to support binaries from MSVC (even on Windows). After
> all, Mingw and obviously Linux versions of vanilla GCC do not support them
> due to things like name mangling.
>
> I would be extremely happy to just be able to compile multiple binaries
> specific to the platforms I am targeting (as I currently do with native C++
> builds) but with the benefit of using the same .NET plugins (written in C#)
> and all the functionality that .NET provides.
>
> So basically, as it stands I don't particularly see a need for /clr:safe or
> a 100% .NET output because we already have C# for that. Platform specific
> binaries would obviously be the aim so we can take advantage of OS specific
> functionality anyway (such as sys/sockets in UNIX and DirectX in Windows)
>
> The AOT stuff does actually sound like a good idea. I didn't think of that.
> Obviously we would need a way to parse out the code to generate it.
>
> As for someone doing it... How long in man hours do you predict it will
> take?
>

No clue, probably months for someone that knows the mono runtime and LLVM.
___
Mono-list maillist  -  Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list

Re: [Mono-list] C++/CLI Support

[Rodrigo Kumpera]

There are a bunch of thorny issues to consider.

Do we want to support C++ CLI binaries done using the MS toolchain outside
of windows?
Supporting those requires writing a whole PE dynamic linkers, which is a
huge amount of work.

If not, we can very much simply use mono's AOT engine and produce a pair of
.dll and .dll.so
files and be done with it. This approach is doable but the only issue is
that the AOT file format
inside an ELF file is not set in stone and changes frequently - we're at
version 84.

We can derive a stable forward, add mono support for it, and use it in
conjunction with LLVM
to output a linux/osx C++ CLI binary pair. This is doable, but keep in mind
that those binaries
are platform specific.

So, given than, all it's left is someone doing it.


On Mon, Sep 10, 2012 at 5:59 PM, kpedersen  wrote:

> Indeed LLVM/clang certainly seems capable enough since I have seen some
> pretty good frontends and backends developed for it in the past.
>
> I think it depends if the work started using GCC
> (http://gcc.gnu.org/projects/cli.html) can be offset with the future
> development speed or maintainability using LLVM.
>
> However I am simply not skilled / knowledgeable enough in the matter or I
> would love to create it myself!
>
> As I understand we would need our compiler to generate a binary which also
> hosts the CLR and runs the embedded bytecode. (As well as tonnes of other
> stuff such as communicating native data with managed data and visa versa).
>
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/C-CLI-Support-tp4656534p4656552.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] Lockup with callstack on osx (2.10.9)

[Rodrigo Kumpera]

Do you have a reproducible test case? Please file a bug report with it.


On Wed, Sep 5, 2012 at 4:27 AM, Carlo Kok  wrote:

> I have an ever growing set of threads stuck in this pattern:
> http://pastebin.com/raw.php?i=**GgrmkWWU
>
> I checked the mono sources, this seems to be the code:
>
> http://pastebin.com/6kVBXz6U (CHECK_OBJECT)
>
> it gets stuck in. I see no reason 6 threads should be there. I'm using
> Mono.Security which calls delegate.BeginInvoke for it's callbacks. What can
> I do to narrow down what causes this?
>
> Mono/OSX 2.10.9
>
> Carlo Kok
> __**_
> 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