from:"Rodrigo Kumpera"

Re: [Mono-dev] Volatile fields don't enforce acquire - release semantics like Volatile.Read() and Volatile.Write()

2016-07-07 Thread Rodrigo Kumpera

A better test case? Awesome! Thanks for looking into this.

We're aware of the issue so it's up to you on filing a bug.



On Thu, Jul 7, 2016 at 12:53 PM, Petros Douvantzis <petrak...@gmail.com>
wrote:

> Hello Rodrigo,
>
> Sure you can. However this specific test does not reproduce the error in
> iOS most of the time. I will send another one that has more repetitions
> (and wraps-around the array).
>
> I should file the bug, right?
>
> Best,
>
> On Thu, Jul 7, 2016 at 6:38 PM, Rodrigo Kumpera <kump...@gmail.com> wrote:
>
>> Hi Petros,
>>
>> It does look like a bug in our end. We do enforce ECMA's load-acquire,
>> store-release semantics for volatiles.
>>
>> Can we integrate your test case into mono?
>>
>>
>> --
>> Rodrigo
>>
>> On Thu, Jul 7, 2016 at 11:05 AM, Petros Douvantzis <petrak...@gmail.com>
>> wrote:
>>
>>> Hello Miguel,
>>>
>>> The initial code does *not *have the field marked as volatile. However,
>>> it may work in Net 2.0 because it has stronger memory guarantees than the
>>> ECMA.
>>>
>>> So, the articles continues saying "*Making the instance variable
>>> volatile can make it work*". So, *if* the field were volatile, it would
>>> work in every ECMA implementation.
>>>
>>> Also, I tried using:
>>> adb shell setprop debug.mono.env "'MONO_ENV_OPTIONS=-O=-intrins'"
>>> with no difference in the outcome.
>>>
>>> Best,
>>>
>>> On Thu, Jul 7, 2016 at 5:59 PM, Miguel de Icaza <mig...@microsoft.com>
>>> wrote:
>>>
>>>> Hello Petros,
>>>>
>>>>
>>>>
>>>> That blog post on double-check-locking explicitly states that without
>>>> extra steps the pattern would not work.   Maybe I missed something?
>>>>
>>>>
>>>>
>>>> From that post:
>>>>
>>>> · Without any memory barriers, it's broken in the ECMA CLI
>>>> specification too. It's possible that under the .NET 2.0 memory model
>>>> (which is stronger than the ECMA spec) it's safe, but I'd rather not rely
>>>> on those stronger semantics, especially if there's any doubt as to the
>>>> safety. Making the instance variable volatile can make it work, as
>>>> would explicit memory barrier calls, although in the latter case even
>>>> experts can't agree exactly which barriers are required. I tend to try to
>>>> avoid situations where experts don't agree what's right and what's wrong!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From: *Petros Douvantzis <petrak...@gmail.com>
>>>> *Date: *Thursday, July 7, 2016 at 3:54 AM
>>>> *To: *"mono-devel-list@lists.ximian.com" <
>>>> mono-devel-list@lists.ximian.com>, Miguel de Icaza <
>>>> mig...@microsoft.com>
>>>> *Cc: *Rodrigo Kumpera <kump...@gmail.com>
>>>>
>>>> *Subject: *Re: [Mono-dev] Volatile fields don't enforce acquire -
>>>> release semantics like Volatile.Read() and Volatile.Write()
>>>>
>>>>
>>>>
>>>> Hello Miguel,
>>>>
>>>>
>>>>
>>>> I see your point. Even worse, it's a bit ambiguous of what guarantees
>>>> does the volatile field make. For example in MSDN
>>>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmsdn.microsoft.com%2fen-us%2flibrary%2fx13ttww7.aspx=01%7c01%7cmiguel%40microsoft.com%7cbdcbcb26fc8744e9b67d08d3a63c01c8%7c72f988bf86f141af91ab2d7cd011db47%7c1=s02wpedE5%2fUhB9yawFzf3QlY51QePjK5rUj1c16Selk%3d>
>>>>  nothing is mentioned about fences or memory re-orders. In that sense, Mono
>>>> is correct. However, in ECMA 335 they mention acquire-release semantics
>>>> such as the ones in the Volatile class you mentioned.
>>>>
>>>>
>>>>
>>>> One this to consider is that if the Volatile field does not have these
>>>> semantics, then* lazy initialization* that relies on a volatile field
>>>> and a lock ( double-check locking
>>>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcsharpindepth.com%2fArticles%2fGeneral%2fSingleton.aspx=01%7c01%7cmiguel%40microsoft.com%7cbdcbcb26fc8744e9b67d08d3a63c01c8%7c72f988bf86f141af91ab2d7cd011db47%7c1=yk%2bj4W775WX%2b82pOGWXA4xyURhfDzV1XSvJle2p3L2w%3d>
>>>>  )
>>>> is *broken *in Mo

Re: [Mono-dev] Volatile fields don't enforce acquire - release semantics like Volatile.Read() and Volatile.Write()

2016-07-07 Thread Rodrigo Kumpera

Hi Petros,

It does look like a bug in our end. We do enforce ECMA's load-acquire,
store-release semantics for volatiles.

Can we integrate your test case into mono?


--
Rodrigo

On Thu, Jul 7, 2016 at 11:05 AM, Petros Douvantzis <petrak...@gmail.com>
wrote:

> Hello Miguel,
>
> The initial code does *not *have the field marked as volatile. However,
> it may work in Net 2.0 because it has stronger memory guarantees than the
> ECMA.
>
> So, the articles continues saying "*Making the instance variable volatile
> can make it work*". So, *if* the field were volatile, it would work in
> every ECMA implementation.
>
> Also, I tried using:
> adb shell setprop debug.mono.env "'MONO_ENV_OPTIONS=-O=-intrins'"
> with no difference in the outcome.
>
> Best,
>
> On Thu, Jul 7, 2016 at 5:59 PM, Miguel de Icaza <mig...@microsoft.com>
> wrote:
>
>> Hello Petros,
>>
>>
>>
>> That blog post on double-check-locking explicitly states that without
>> extra steps the pattern would not work.   Maybe I missed something?
>>
>>
>>
>> From that post:
>>
>> · Without any memory barriers, it's broken in the ECMA CLI
>> specification too. It's possible that under the .NET 2.0 memory model
>> (which is stronger than the ECMA spec) it's safe, but I'd rather not rely
>> on those stronger semantics, especially if there's any doubt as to the
>> safety. Making the instance variable volatile can make it work, as would
>> explicit memory barrier calls, although in the latter case even experts
>> can't agree exactly which barriers are required. I tend to try to avoid
>> situations where experts don't agree what's right and what's wrong!
>>
>>
>>
>>
>>
>>
>>
>> *From: *Petros Douvantzis <petrak...@gmail.com>
>> *Date: *Thursday, July 7, 2016 at 3:54 AM
>> *To: *"mono-devel-list@lists.ximian.com" <
>> mono-devel-list@lists.ximian.com>, Miguel de Icaza <mig...@microsoft.com>
>> *Cc: *Rodrigo Kumpera <kump...@gmail.com>
>>
>> *Subject: *Re: [Mono-dev] Volatile fields don't enforce acquire -
>> release semantics like Volatile.Read() and Volatile.Write()
>>
>>
>>
>> Hello Miguel,
>>
>>
>>
>> I see your point. Even worse, it's a bit ambiguous of what guarantees
>> does the volatile field make. For example in MSDN
>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmsdn.microsoft.com%2fen-us%2flibrary%2fx13ttww7.aspx=01%7c01%7cmiguel%40microsoft.com%7cbdcbcb26fc8744e9b67d08d3a63c01c8%7c72f988bf86f141af91ab2d7cd011db47%7c1=s02wpedE5%2fUhB9yawFzf3QlY51QePjK5rUj1c16Selk%3d>
>>  nothing is mentioned about fences or memory re-orders. In that sense, Mono
>> is correct. However, in ECMA 335 they mention acquire-release semantics
>> such as the ones in the Volatile class you mentioned.
>>
>>
>>
>> One this to consider is that if the Volatile field does not have these
>> semantics, then* lazy initialization* that relies on a volatile field
>> and a lock ( double-check locking
>> <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fcsharpindepth.com%2fArticles%2fGeneral%2fSingleton.aspx=01%7c01%7cmiguel%40microsoft.com%7cbdcbcb26fc8744e9b67d08d3a63c01c8%7c72f988bf86f141af91ab2d7cd011db47%7c1=yk%2bj4W775WX%2b82pOGWXA4xyURhfDzV1XSvJle2p3L2w%3d>
>>  )
>> is *broken *in Mono for iOS and Android, because there is a chance that
>> a half created object is viewed by another thread. The way the volatile
>> field is supposed to help, is explained in this post
>> <https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fmsdn.microsoft.com%2fen-us%2fmagazine%2fjj883956.aspx=01%7c01%7cmiguel%40microsoft.com%7cbdcbcb26fc8744e9b67d08d3a63c01c8%7c72f988bf86f141af91ab2d7cd011db47%7c1=Edq89e1H1sGysBYfBQFrb9WUTXczZe0ZlQfh1FQJvJc%3d>
>> .
>>
>>
>>
>> The only way to make this work right now is using the Volatile class, but
>> most probably someone would expect the volatile field to work.
>>
>>
>>
>> Best,
>>
>>
>>
>> On Wed, Jul 6, 2016 at 9:24 PM, Miguel de Icaza <mig...@microsoft.com>
>> wrote:
>>
>> Hello,
>>
>>
>>
>> I am not convinced that this is a bug worth fixing.
>>
>>
>>
>> I think this requires some thinking.  While this might have been the
>> intended visible behavior from C#, this predates the extensive use of C#
>> beyond the x86 platform.   I believe this is why the Volatile APIs were
>> introduced.
>>
>>
>>
>> Consder the documentation f

Re: [Mono-dev] Volatile fields don't enforce acquire - release semantics like Volatile.Read() and Volatile.Write()

2016-07-06 Thread Rodrigo Kumpera

Yes, it looks like a bug.

On Wed, Jul 6, 2016 at 11:13 AM, petrakeas  wrote:

> According to C#  specification
>   :
>
> •   A read of a volatile field is called a volatile read. A volatile
> read has
> “acquire semantics”; that is, it is guaranteed to occur prior to any
> references to memory that occur after it in the instruction sequence.
> •   A write of a volatile field is called a volatile write. A volatile
> write
> has “release semantics”; that is, it is guaranteed to happen after any
> memory references prior to the write instruction in the instruction
> sequence.
>
> The spec presents  an example
>    where
> one thread writes "data" on a non volatile variable and "publishes" the
> result by writing on a volatile variable that acts as a flag. The other
> thread checks the volatile flag and if set, it accesses the non-volatile
> variable that is now *guaranteed* to contain the data.
>
> It seems that Mono 4.4 (the one used in Xamarin) does not enforce these
> semantics or in other words does not prevent memory re-ordering in Android
> and iOS that have relaxed memory models due to their CPU.
>
> I have created an a test that reproduces the problem in iOS and Android
> Program.cs   .
>
> If the access to the volatile field is replaced by Volatile.Read() and
> Volatile.Write(), then no-problems occur. It seems that Volatile.Read() and
> Volatile.Write() implement half fences in Mono, but the volatile keyword
> does not.
>
> Is this a bug?
>
>
>
>
> --
> View this message in context:
> http://mono.1490590.n4.nabble.com/Volatile-fields-don-t-enforce-acquire-release-semantics-like-Volatile-Read-and-Volatile-Write-tp4668111.html
> Sent from the Mono - Dev mailing list archive at Nabble.com.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] FW: Random hangs while running mono app

2016-06-07 Thread Rodrigo Kumpera

The crash you shown are unrelated to sgen, switching to boehm will do you
no good.

On Mon, Jun 6, 2016 at 2:10 AM, Burkhard Linke <
bli...@cebitec.uni-bielefeld.de> wrote:

> Hi,
>
> On 06/03/2016 09:12 PM, George, Glover E ERDC-RDE-ITL-MS CIV wrote:
>
>> I¹ve been trying to reproduce the case where my jobs get a core dump when
>> the finalizer doesn¹t return in time, but I¹ve only been able to reproduce
>> the previously posted stack trace which causes the job to hang in ³Sl²
>> state (using ps).  Posting the stack trace again because I somehow didn¹t
>> pasted on of the threads entire stacktrace:
>>
>> Rodrigo, can you please follow up on the email I posted about not seeing
>> anything in STDOUT/STDERR?  My code doesn¹t seem to make it to where you
>> are referring to.
>>
>> Burkhard, what file system are you guys using on your cluster?  NFS,
>> Gluster, Lustre?
>>
> The cluster is using CephFS based on the kernel implementation in for
> accessing data (Ubuntu Xenial kernel backport for Trusty, version
> 4.4.0-21). We are currently trying to "resolve" the bug by falling back to
> boehm gc (mono-boehm instead of mono-sgen).
>
> Regards,
> Burkhard
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] FW: Random hangs while running mono app

2016-06-03 Thread Rodrigo Kumpera

d
> code)
> 0x1 - running (BAD, unless it's the gc thread)
> 0x2 - detached (GOOD, unless the thread is running managed
> code)
> 0x?03   - async suspended (GOOD)
> 0x?04   - self suspended (GOOD)
> 0x?05   - async suspend requested (BAD)
> 0x?06   - self suspend requested (BAD)
> 0x*07   - blocking (GOOD)
> 0x?08   - blocking with pending suspend (GOOD)
> --thread 0xa38b30 id 0x7fffec637700 [(nil)] state 105
> --thread 0x9d8640 id 0x7fffedae7780 [(nil)] state 1  GC INITIATOR
> WAITING for 1 threads, got 0 suspended
> suspend_thread suspend took 200 ms, which is more than the allowed 200 ms
> STATE CUE CARD: (? means a positive number, usually 1 or 2, * means any
> number)
> 0x0 - starting (GOOD, unless the thread is running managed
> code)
> 0x1 - running (BAD, unless it's the gc thread)
> 0x2 - detached (GOOD, unless the thread is running managed
> code)
> 0x?03   - async suspended (GOOD)
> 0x?04   - self suspended (GOOD)
> 0x?05   - async suspend requested (BAD)
> 0x?06   - self suspend requested (BAD)
> 0x*07   - blocking (GOOD)
> 0x?08   - blocking with pending suspend (GOOD)
> --thread 0xa38b30 id 0x7fffec637700 [(nil)] state 105
> --thread 0x9d8640 id 0x7fffedae7780 [(nil)] state 1  GC INITIATOR
>
>
> ‹ ‹ ‹
> Glover E. George
> Computer Scientist
> Information Technology Laboratory
> US Army Engineer Research and Development Center
> Vicksburg, MS 39180
> 601-634-4730
>
>
>
>
>
> From:  Rodrigo Kumpera <kump...@gmail.com>
> Date:  Friday, April 29, 2016 at 9:12 AM
> To:  Glover George <glover.e.geo...@erdc.dren.mil>
> Cc:  "mono-devel-list@lists.ximian.com" <mono-devel-list@lists.ximian.com>
> Subject:  Re: [Mono-dev] FW: Random hangs while running mono app
>
>
> This looks like a shutdown bug in mono.
>
> Do you have a reliable way to reproduce it?
> How loaded are the machines running your workload?
>
>
> On Thu, Apr 28, 2016 at 6:41 PM, George, Glover E ERDC-RDE-ITL-MS CIV
> <glover.e.geo...@erdc.dren.mil> wrote:
>
> One more important point I forgot to mention, when this occurs, it is
> generally only a few mono instances out of the 500+ simultaneous mono
> instances.  Most of them terminate.  And more importantly, the mono
> instances that do hang actually complete their
>  work!  It seems to be when mono is trying to close down.
>
> This has occurred with mono 4.2.x, 4.3.x, 4.4.x, and current git.
>
> Happened today with this configuration:
> Mono JIT compiler version 4.3.2 (Stable 4.3.2.467/ba2e5e4 Tue Mar 15
> 11:44:06 CDT 2016)
> Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors.
> Blockedwww.mono-project.comBlocked
> <Blockedhttp://www.mono-project.comBlocked>
> TLS:   __thread
> SIGSEGV:   altstack
> Notifications: epoll
> Architecture:  amd64
> Disabled:  none
> Misc:  bigarrays softdebug
> LLVM:  supported, not enabled.
> GC:sgen
>
>
>
>
> From: <mono-devel-list-boun...@lists.ximian.com> on behalf of Glover
> George <glover.e.geo...@erdc.dren.mil>
> Date: Thursday, April 28, 2016 at 5:25 PM
> To: "mono-devel-list@lists.ximian.com" <mono-devel-list@lists.ximian.com>
> Subject: [Mono-dev] Random hangs while running mono app
>
>
> Hi all,
>
> Quick background: We¹re running mono on an HPC platform (SGI ICE-X / SUSE
> Enterprise Linux 11) with a Lustre filesystem.  For several months, I¹ve
> noticed random hangs with our application.  In a given batch job, we run
> 500+ instances of mono in parallel
>  (no interprocess communication).   I haven¹t been able to reliably
> reproduce the issue which leads me to believe it¹s a timing issue, and
> more specifically, I have reason to believe it may be an issue with the
> interaction of mono and the filesystem.  Being
>  a clustered file-system, the load on the backing stores can vary due to
> other users.
>
> When I notice that my job hasn¹t finished in a reasonable amount of time,
> I log into the compute node and do a  ³ ps -efL | grep mono ³ which
> reveals:
>
> george  16728 16575 16728  63 16:13 ?00:03:58 mono
> --runtime=v4.0.30319 /app/MyConsole.exe
> ggeorge  16728 16575 16768  03 16:13 ?00:00:02 mono
> --runtime=v4.0.30319 /app/MyConsole.exe
> ggeorge  16728 16575 16815  03 16:13 ?00:00:04 mono
> --runtime=v4.0.30319 /app/MyConsole.exe
>
>
> 16728 is the top proc which spawns 16768 and 16815 (main, gc and maybe
> finalizer thread?).
>
> Attaching to each of these 3 pi

Re: [Mono-dev] Loader Optimization with mono

2016-06-03 Thread Rodrigo Kumpera

Mono doesn't implement LoaderOptimization.

On Thu, Jun 2, 2016 at 5:59 AM, techi eth  wrote:

> Does  [LoaderOptimization(LoaderOptimization.MultiDomainHost)] work as
> desired on mono?
>
> I am using Mono 4.2 version on ubuntu  to test.
>
>
>
> I had following observation
>
>
>
> 1. Exe with this attribute and without this attribute take same memory.
> Even I had check shared memory also is same and residual - shared is also
> same .
>
> 2. Is there any tool on linux like Process explorer in windows to verify
> that all GAC assembly go to shares memory after this attribute is applied.
>
>
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] FW: Random hangs while running mono app

2016-04-29 Thread Rodrigo Kumpera

This looks like a shutdown bug in mono.

Do you have a reliable way to reproduce it?
How loaded are the machines running your workload?

On Thu, Apr 28, 2016 at 6:41 PM, George, Glover E ERDC-RDE-ITL-MS CIV <
glover.e.geo...@erdc.dren.mil> wrote:

> One more important point I forgot to mention, when this occurs, it is
> generally only a few mono instances out of the 500+ simultaneous mono
> instances.  Most of them terminate.  And more importantly, the mono
> instances that do hang actually complete their work!  It seems to be when
> mono is trying to close down.
>
> This has occurred with mono 4.2.x, 4.3.x, 4.4.x, and current git.
>
> Happened today with this configuration:
> Mono JIT compiler version 4.3.2 (Stable 4.3.2.467/ba2e5e4 Tue Mar 15
> 11:44:06 CDT 2016)
> 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:  bigarrays softdebug
> LLVM:  supported, not enabled.
> GC:sgen
>
>
> From:  on behalf of Glover
> George 
> Date: Thursday, April 28, 2016 at 5:25 PM
> To: "mono-devel-list@lists.ximian.com" 
> Subject: [Mono-dev] Random hangs while running mono app
>
> Hi all,
>
> Quick background: We’re running mono on an HPC platform (SGI ICE-X / SUSE
> Enterprise Linux 11) with a Lustre filesystem.  For several months, I’ve
> noticed random hangs with our application.  In a given batch job, we run
> 500+ instances of mono in parallel (no interprocess communication).   I
> haven’t been able to reliably reproduce the issue which leads me to believe
> it’s a timing issue, and more specifically, I have reason to believe it may
> be an issue with the interaction of mono and the filesystem.  Being a
> clustered file-system, the load on the backing stores can vary due to other
> users.
>
> When I notice that my job hasn’t finished in a reasonable amount of time,
>  I log into the compute node and do a  “ ps -efL | grep mono “ which
> reveals:
>
> george  16728 16575 16728  63 16:13 ?00:03:58 mono
> --runtime=v4.0.30319 /app/MyConsole.exe
> ggeorge  16728 16575 16768  03 16:13 ?00:00:02 mono
> --runtime=v4.0.30319 /app/MyConsole.exe
> ggeorge  16728 16575 16815  03 16:13 ?00:00:04 mono
> --runtime=v4.0.30319 /app/MyConsole.exe
>
> 16728 is the top proc which spawns 16768 and 16815 (main, gc and maybe
> finalizer thread?).
>
> Attaching to each of these 3 pid’s with gdb and doing a backtrace reveals
> the traces below.
>
> 1.  Is it possible this is a GC hang?
>
> 2.  Is it possible this is a race condition that has anything to do with
> the filesystem?
>
> 3.  Any idea how this sequence could occur?  If there’s a way to gather
> more information, please let me know.
>
> The reason for the file system suspicion is my app writes several small
> files, times the number of mono instances (500+).  It only happens
> randomly, but seems to be more frequent the more mono instances I run.
>
> Any help is HIGHLY appreciated.
>
> PID 16728
> ———
> (gdb) bt
> #0  0x7fffecccd324 in __lll_lock_wait () from /lib64/libpthread.so.0
> #1  0x7fffeccc8684 in _L_lock_1091 () from /lib64/libpthread.so.0
> #2  0x7fffeccc84f6 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #3  0x7fffed8f6dcc in _dl_open () from /lib64/ld-linux-x86-64.so.2
> #4  0x7fffec842530 in do_dlopen () from /lib64/libc.so.6
> #5  0x7fffed8f2e86 in _dl_catch_error () from
> /lib64/ld-linux-x86-64.so.2
> #6  0x7fffec8425e5 in dlerror_run () from /lib64/libc.so.6
> #7  0x7fffec8426d7 in __libc_dlopen_mode () from /lib64/libc.so.6
> #8  0x7fffec81d2e5 in init () from /lib64/libc.so.6
> #9  0x7fffecccbd03 in pthread_once () from /lib64/libpthread.so.0
> #10 0x7fffec81d43c in backtrace () from /lib64/libc.so.6
> #11 0x004ac025 in mono_handle_native_sigsegv (signal= out>, ctx=, info=)
> at mini-exceptions.c:2309
> #12 
> #13 0x7fffec75e875 in raise () from /lib64/libc.so.6
> #14 0x7fffec75fe51 in abort () from /lib64/libc.so.6
> #15 0x0064528a in monoeg_log_default_handler (log_domain=0x0,
> log_level=G_LOG_LEVEL_ERROR, message=
> 0x1ac7660 "suspend_thread suspend took 200 ms, which is more than the
> allowed 200 ms", unused_data=0x0) at goutput.c:233
> #16 0x00645077 in monoeg_g_logv (log_domain=0x0,
> log_level=G_LOG_LEVEL_ERROR, format=
> 0x7015d8 "suspend_thread suspend took %d ms, which is more than the
> allowed %d ms", args=0x7fffce58) at goutput.c:113
> #17 0x0064512d in monoeg_g_log (log_domain=0x0,
> log_level=G_LOG_LEVEL_ERROR, format=
> 0x7015d8 "suspend_thread suspend took %d ms, which is more than the
> allowed %d ms") at goutput.c:123
> #18 0x0063a13f in mono_threads_wait_pending_operations () at
>

Re: [Mono-dev] Using valgrind with Mono

2016-03-29 Thread Rodrigo Kumpera

This is the PR in question: https://github.com/mono/mono/pull/2783

It probably won't make into 4.2, but should definitely be in 4.4.


On Tue, Mar 29, 2016 at 11:55 AM, Zinkevicius, Matt <
matt.zinkevic...@hpe.com> wrote:

> Hi Rodrigo,
>
>
>
> Is the following the PR that you were referring to that fixes the
> “mono_method_get_header” leak?
>
>
>
> https://github.com/mono/mono/pull/2705
>
>
>
> I am eager to find it, as this particular leak seems to be the most
> egregious of the ones we’re experiencing, in terms of both occurrences and
> total bytes leaked (hundreds of MB/hour when under load).
>
>
>
> If so, I’ll try to backport it to Mono 4.2.3, though it is far from
> patching cleanly currently.
>
>
>
> Matt
>
>
>
> *From:* mono-devel-list-boun...@lists.ximian.com [mailto:
> mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Zinkevicius, Matt
> *Sent:* Monday, March 28, 2016 2:42 PM
> *To:* Rodrigo Kumpera <kump...@gmail.com>
>
> *Cc:* Straw, David (Storage) <david.st...@hpe.com>;
> mono-devel-list@lists.ximian.com
> *Subject:* Re: [Mono-dev] Using valgrind with Mono
>
>
>
> Hi Rodrigo,
>
>
>
> I am not finding a recent commit in master that mentions
> “mono_method_get_header”. Do you happen to have the commit ID or log
> message handy?
>
>
>
> Sorry for the bother,
>
> Matt
>
>
>
> *From:* Rodrigo Kumpera [mailto:kump...@gmail.com <kump...@gmail.com>]
> *Sent:* Monday, March 28, 2016 1:58 PM
> *To:* Zinkevicius, Matt <matt.zinkevic...@hpe.com>
> *Cc:* Zoltan Varga <var...@gmail.com>; Straw, David (Storage) <
> david.st...@hpe.com>; mono-devel-list@lists.ximian.com
> *Subject:* Re: [Mono-dev] Using valgrind with Mono
>
>
>
> The memory leak on mono_method_get_header was recently fixed in master.
>
>
>
>
>
>
>
> On Mon, Mar 28, 2016 at 3:31 AM, Zinkevicius, Matt <
> matt.zinkevic...@hpe.com> wrote:
>
> I can confirm that Zoltan’s fix does indeed remove any leak instances with
> a call stack containing “ves_icall_Type_GetNestedTypes”, but unfortunately
> that accounted for only 36 leak instances out of the 19,900 reported.
>
>
>
> I have filed a bug (https://bugzilla.xamarin.com/show_bug.cgi?id=39940)
> and attached the latest valgrind output there.
>
>
>
> Thanks again for any help you can provide,
>
> Matt Zinkevicius
>
>
>
> *From:* mono-devel-list-boun...@lists.ximian.com [mailto:
> mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Zinkevicius, Matt
> *Sent:* Sunday, March 27, 2016 11:06 PM
> *To:* Zoltan Varga <var...@gmail.com>
> *Cc:* Straw, David (Storage) <david.st...@hpe.com>;
> mono-devel-list@lists.ximian.com
>
>
> *Subject:* Re: [Mono-dev] Using valgrind with Mono
>
>
>
> Hi Zoltan,
>
>
>
> Thank you for investigating my findings. I will apply the fix you linked
> to and report back. While I understand the other leaks are small, valgrind
> reported over 19,000 instances of leaked memory in under 5 minutes of our
> app running without load.
>
>
>
> Matt Zinkevicius
>
>
>
> *From:* Zoltan Varga [mailto:var...@gmail.com <var...@gmail.com>]
> *Sent:* Sunday, March 27, 2016 4:45 PM
> *To:* Zinkevicius, Matt <matt.zinkevic...@hpe.com>
> *Cc:* mono-devel-list@lists.ximian.com; Straw, David (Storage) <
> david.st...@hpe.com>
> *Subject:* Re: [Mono-dev] Using valgrind with Mono
>
>
>
> Hi,
>
>
>
>   Fixed the last one in:
>
>
> https://github.com/mono/mono/commit/b97ac0023256bf7d915552f5f24a7742b28c32b7
>
>
>
> The first two are leaks, but they should be small and bounded. Will look
> into fixing them to decrease the noise.
>
>
>
>   Zoltan
>
>
>
> On Sun, Mar 27, 2016 at 6:23 PM, Zinkevicius, Matt <
> matt.zinkevic...@hpe.com> wrote:
>
> Hello,
>
>
>
> Our backend service running on Mono 4.2.2 on Linux is experiencing an
> unmanaged memory leak. When running our stress tests for several hours, we
> see the managed heap sit around 50 MB, while private memory keeps growing
> until the process is killed because of OOM. I am therefore attempting to
> use valgrind to find the culprit, but I am getting so many leaks detected
> that I think many must be false positives, so I thought I would ask here
> for some guidance about which are safe to suppress or any other valgrind +
> mono tricks you can share.
>
>
>
> The vast majority of leaks reported have call stacks that closely match
> one of the following:
>
>
>
> ==16846== 4 bytes in 1 blocks are definitely lost in loss re

Re: [Mono-dev] Using valgrind with Mono

2016-03-28 Thread Rodrigo Kumpera

The memory leak on mono_method_get_header was recently fixed in master.



On Mon, Mar 28, 2016 at 3:31 AM, Zinkevicius, Matt  wrote:

> I can confirm that Zoltan’s fix does indeed remove any leak instances with
> a call stack containing “ves_icall_Type_GetNestedTypes”, but unfortunately
> that accounted for only 36 leak instances out of the 19,900 reported.
>
>
>
> I have filed a bug (https://bugzilla.xamarin.com/show_bug.cgi?id=39940)
> and attached the latest valgrind output there.
>
>
>
> Thanks again for any help you can provide,
>
> Matt Zinkevicius
>
>
>
> *From:* mono-devel-list-boun...@lists.ximian.com [mailto:
> mono-devel-list-boun...@lists.ximian.com] *On Behalf Of *Zinkevicius, Matt
> *Sent:* Sunday, March 27, 2016 11:06 PM
> *To:* Zoltan Varga 
> *Cc:* Straw, David (Storage) ;
> mono-devel-list@lists.ximian.com
>
> *Subject:* Re: [Mono-dev] Using valgrind with Mono
>
>
>
> Hi Zoltan,
>
>
>
> Thank you for investigating my findings. I will apply the fix you linked
> to and report back. While I understand the other leaks are small, valgrind
> reported over 19,000 instances of leaked memory in under 5 minutes of our
> app running without load.
>
>
>
> Matt Zinkevicius
>
>
>
> *From:* Zoltan Varga [mailto:var...@gmail.com ]
> *Sent:* Sunday, March 27, 2016 4:45 PM
> *To:* Zinkevicius, Matt 
> *Cc:* mono-devel-list@lists.ximian.com; Straw, David (Storage) <
> david.st...@hpe.com>
> *Subject:* Re: [Mono-dev] Using valgrind with Mono
>
>
>
> Hi,
>
>
>
>   Fixed the last one in:
>
>
> https://github.com/mono/mono/commit/b97ac0023256bf7d915552f5f24a7742b28c32b7
>
>
>
> The first two are leaks, but they should be small and bounded. Will look
> into fixing them to decrease the noise.
>
>
>
>   Zoltan
>
>
>
> On Sun, Mar 27, 2016 at 6:23 PM, Zinkevicius, Matt <
> matt.zinkevic...@hpe.com> wrote:
>
> Hello,
>
>
>
> Our backend service running on Mono 4.2.2 on Linux is experiencing an
> unmanaged memory leak. When running our stress tests for several hours, we
> see the managed heap sit around 50 MB, while private memory keeps growing
> until the process is killed because of OOM. I am therefore attempting to
> use valgrind to find the culprit, but I am getting so many leaks detected
> that I think many must be false positives, so I thought I would ask here
> for some guidance about which are safe to suppress or any other valgrind +
> mono tricks you can share.
>
>
>
> The vast majority of leaks reported have call stacks that closely match
> one of the following:
>
>
>
> ==16846== 4 bytes in 1 blocks are definitely lost in loss record 74 of
> 19,903
>
> ==16846==at 0x4C26FEF: calloc (vg_replace_malloc.c:711)
>
> ==16846==by 0x62D1D9: monoeg_malloc0 (in /usr/bin/mono-sgen)
>
> ==16846==by 0x4870F2: decode_exception_debug_info (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x488975: mono_aot_find_jit_info (in /usr/bin/mono-sgen)
>
> ==16846==by 0x53C3A7: mono_jit_info_table_find_internal (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x493C04: mini_jit_info_table_find_ext (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x4988FB: mini_add_method_trampoline (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x499067: common_call_trampoline_inner (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x403217C: ???
>
> ==16846==by 0x10D3FB63: ???
>
> ==16846==by 0x10D3F41B: ???
>
> ==16846==by 0x10D3F117: ???
>
>
>
> ==16846== 12 bytes in 1 blocks are definitely lost in loss record 1,172 of
> 19,903
>
> ==16846==at 0x4C2828A: malloc (vg_replace_malloc.c:299)
>
> ==16846==by 0x62D221: monoeg_malloc (in /usr/bin/mono-sgen)
>
> ==16846==by 0x55B8EF: mono_metadata_type_dup (in /usr/bin/mono-sgen)
>
> ==16846==by 0x49FC4B: get_shared_gparam (in /usr/bin/mono-sgen)
>
> ==16846==by 0x49FE70: get_shared_inst (in /usr/bin/mono-sgen)
>
> ==16846==by 0x4A073A: mini_get_shared_method_full (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x414723: lookup_method (in /usr/bin/mono-sgen)
>
> ==16846==by 0x4147FA: mono_jit_compile_method_with_opt (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x414B9A: mono_jit_compile_method (in /usr/bin/mono-sgen)
>
> ==16846==by 0x498DA4: common_call_trampoline_inner (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x403405C: ???
>
> ==16846==by 0x10D2DCA7: ???
>
>
>
> ==16846== 10 bytes in 1 blocks are definitely lost in loss record 739 of
> 19,903
>
> ==16846==at 0x4C2828A: malloc (vg_replace_malloc.c:299)
>
> ==16846==by 0x62D221: monoeg_malloc (in /usr/bin/mono-sgen)
>
> ==16846==by 0x62BA8C: monoeg_g_utf16_to_utf8 (in /usr/bin/mono-sgen)
>
> ==16846==by 0x5A8646: mono_string_to_utf8_checked (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x5A885B: mono_string_to_utf8 (in /usr/bin/mono-sgen)
>
> ==16846==by 0x52DE3C: ves_icall_Type_GetNestedTypes (in
> /usr/bin/mono-sgen)
>
> ==16846==by 0x120D4256: ???
>
>

Re: [Mono-dev] profiling

2016-02-29 Thread Rodrigo Kumpera

Hi Neale,

It is a concern as we addressed that issue over last year.

If possible, could you file bugs with those .mlpd files attached so we can
take a look?

--
Rodrigo

On Thu, Feb 25, 2016 at 3:18 PM, Neale Ferguson 
wrote:

> Sometimes when we run the profiler and then run mprof-report we get
> instances of “unresolved classes” in the report. How does this happen and
> is it a concern?
>
> Neale
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] (no subject)

2016-02-20 Thread Rodrigo Kumpera

Yes, we'll participate on this year GSoC.  :)

On Sat, Feb 20, 2016 at 1:57 PM, a7med usama 
wrote:

> Hi.
> Does the organization will enter into Google summer of code 2016 ?
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] sgen crash on x86_64 (when using libmono from Wine)

2016-02-09 Thread Rodrigo Kumpera

Hi Paul,

Great catch! Using long in the code base is frowned upon as it has this
sort of issues.
Your patch can be merged as is. I can do it if you don't mind.

--
Rodrigo






On Tue, Feb 9, 2016 at 12:08 PM, Paul Gofman  wrote:

> Hi,
>
> while working with 64-bit mono under Wine (using libmono x64 dll) I came
> through a problem with SGen garbage collector crashing on either from
> finalizer thread or seemingly every time some garbage collection already
> happened before. Finally I found the problem in sgen-marksweep.c:
> bitcount(mword) implementation. I am attaching a patch which fixes it
> for me.
> The problem is only in libmono, mono 64 bit standalone executable
> does not have it. I am attaching a trivial test case which I finally
> used to isolate the problem (testprint.cs). If compile it with: 'mcs
> gccollect.cs -platform:x64', and then run with wine64 on a 64-bit
> wineprefix, there is a native SIGSEGV in second GC collect. I used
> vanilla wine 1.9.3 to reproduce the issue. Compiling test case with
> -platform:x64 is important as otherwise it will be run as 32-bit process
> for which the problem does not exist.
> Could you please advice if this (or similar) patch can somehow be
> pushed upstream?
>
> Thanks,
> Paul.
>
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Profiler Locations

2015-11-15 Thread Rodrigo Kumpera

It's on lib. That's where the default profiler is shipped.

Try running you program with MONO_LOG_LEVEL=debug and see where mono is
probing,

On Fri, Nov 13, 2015 at 4:12 PM, Greg Young  wrote:

> In OSX Capitan you can't install something to /usr/lib. I figured mono
> installation/lib would work for installing a profiler but still not
> found. Where is the correct place to install a profiler?
>
> --
> Studying for the Turing test
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] The impact of running dlls compiled with /platform:x86 on a x86_64 machine under mono

2015-11-06 Thread Rodrigo Kumpera

Yes, mono will ignore the assembly options and run with the bitness the
runtime was compiled for.

On Fri, Nov 6, 2015 at 5:28 AM, Dan Liew <d...@su-root.co.uk> wrote:

> On 6 November 2015 at 05:29, Rodrigo Kumpera <kump...@gmail.com> wrote:
> > Mono ignores those settings and will run with the bitness it was compiled
> > as.
>
> Okay, by "it" I presume you are referring to the target Mono was
> compiled for, not the target the application was compiled for.
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] The impact of running dlls compiled with /platform:x86 on a x86_64 machine under mono

2015-11-05 Thread Rodrigo Kumpera

Mono ignores those settings and will run with the bitness it was compiled
as.

On Thu, Nov 5, 2015 at 10:11 AM, Dan Liew  wrote:

> Hi,
>
> I'm sorry if this is a dumb question but I couldn't find any
> information on this regarding mono.
>
> I've just noticed that a project I've been working on has dlls where
> the compilation platform is kind of messed up. Some are
> "Release|AnyCPU" and some are "Release|x86". I just noticed by looking
> at [1] that "x86" actually means 32-bit x86 which now has me a little
> worried.
>
> I (unintentionally) compiled my application with a mix of dlls
> compiled with "Release|AnyCPU" and "Release|x86" (the ``.exe`` was
> built as "Release|x86"). Does that mean my application actually ran in
> some sort of 32-bit mode inside mono, where less memory (i.e. <= 4GiB)
> was available?
>
> Similarly, under Windows would my application run as a 32-bit application
> too?
>
>
> [1] https://msdn.microsoft.com/en-us/library/zekwfyz4.aspx
>
> Thanks,
> Dan.
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Clarifying the relationship between docs/ and the website

2015-11-05 Thread Rodrigo Kumpera

Hey Andi,

He's my take on your suggestions.

We have a big gap in our docs story. It would be great if we got back to
publishing API and runtime docs together with
each release. That would solve the issue of making them available.

Moving them back to the mono repo creates some friction to publish them on
the website and, if anything, we want to
reduce any friction. Getting better docs is hard as is today.

I like your second option, of embedding version strings in the docs. For
parts we got documents on, the runtime internal
design doesn't change as a pace that is fast enough to be a hassle.

Later we should have as part of our release process record in the mono repo
the docs hash and export the relevant parts to a
per-version archive. That would be great to have.



--
Rodrigo


On Wed, Oct 28, 2015 at 2:21 PM, Andi McClure 
wrote:

> Hi. I have started working on refactoring the assembly/class loading in
> mono, and will be writing some conceptual documentation as part of this
> project. Because of this I am interested in trying to clean up the
> situation with the mono runtime’s documentation, which I feel is a little
> messy. At the moment, all of the design documentation for mono is in a
> separate repository from the source, https://github.com/mono/website ,
> which is published on the web directly to http://www.mono-project.com/
> using Github Pages. There are three big problems I see:
>
> - The documentation is not versioned. There is a git history for the
> website repo, but if you have a copy of the mono repo there is no way to
> relate a particular revision of mono (or even a particular major release)
> to a specific version of the website docs.
>
> - There are still some docs in the main mono repository, under docs/,
> which were never moved over to the website. These are almost all inaccurate
> now.
>
> - The embedding API for the runtime is not documented on the web. There is
> doxygen in the source, and it is possible to build HTML from that source,
> but the mono project does not do this officially.
>
> I would like to do something about at least the first two of these
> problems in the short term. The stale docs problem is easy: Delete the
> stale docs. The first problem on the other hand seems to have multiple
> possible solutions, so Rodrigo asked I put a request for comments on the
> mailing list.
>
> After discussing this with a couple of people at Xamarin, here are the
> potential solutions I see to the versioning problem:
>
> 1. The simple approach: Put a line in docs/README in the mono repo
> specifically listing (or linking on Github) the git commit in the website
> repo which documents that version. We would then make it part of the mono
> release process to always update this link before tagging/tarballing.
>
> 2. Manually embed versioning information in the docs themselves: Start
> writing the website documents in such a way that each one contains text
> like “the following applies to version 4.4” or “this paragraph is true as
> of 4.2.1 or later”. If a document changes significantly, the out-of-date
> information could be moved to a /archived or /historical section within the
> docs directory.
>
> 3. Move the runtime docs back from the website repo to the mono repo, so
> that the docs and runtime are versioned in lockstep again, but have an
> export process where at certain times (such as a release) the current state
> is copied to the website. Probably only some parts of the website docs
> would be exported in this way (for example, docs/advanced and
> docs/compiling-mono on the website would be mirrors of folders in the mono
> repo, but the gui and database folders on the website would not be).
>
> 4. Do something with git submodules. Instead of manually copying files, we
> could make a new mono-docs repo on github, make this a submodule of the
> mono repo inside docs/, and also make it a submodule of the website repo
> inside docs/. Github Pages allows submodules inside of the gh-pages repo as
> long as the submodule is set up read-only. This would be like the “export”
> option, but instead of copying many files we would just have to update the
> submodule state on the website every so often.
>
> I think my suggestion would be to start with “option 1” immediately, and
> then plan to transition to option 3 as soon as practical. I like option 3
> because it separates the “product” of the website from the working state of
> the mono repo (at the moment, if I want to create a half-finished document
> describing something that only exists in the master branch, there is no
> good place to put it), and because option 3 is easy to build further work
> on later. For example, if we had an export-to-website process, part of the
> export process could be to build doxygen and copy it to the website also,
> or to back up the old state of the docs to something like an /archived/4.3
> directory within the website.
>
> (Starting to adopt a style of being specific

Re: [Mono-dev] Profiling: Tail calls

2015-10-18 Thread Rodrigo Kumpera

There's nothing in it that handles tail calls specially.

On Fri, Oct 16, 2015 at 8:20 AM, Greg Young  wrote:

> Is there anything to let you know that a tail call was made in the
> profiling api? I haven't see anything so far but figured I might have
> missed it.
>
> --
> Studying for the Turing test
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] bug #28777

2015-08-21 Thread Rodrigo Kumpera

No timeline for 4.0.5. It might be a community only release.
Mono 4.2.0 has already been branched and an alpha release is happening in
the coming weeks.

--
Rodrigo


On Mon, Aug 17, 2015 at 11:28 AM, Stephen G. Parry sgpa...@mainscreen.com
wrote:

 When are either 4.2 or 4.0.5 due to be fully live?


 On 17/08/15 14:44, Rodrigo Kumpera wrote:

 The fix will be part of mono 4.2.0.

 We could later backport it to mono 4.0.5 if 4.2 is not an option.

 --
 Rodrigo


 On Sat, Aug 15, 2015 at 10:59 AM, Stephen G. Parry sgpa...@mainscreen.com
  wrote:

 Hi All,
 We have what looks like a reversion of bug #28777
 (https://bugzilla.xamarin.com/show_bug.cgi?id=28777). This is causing
 KeePass to fail when saving compressed files whilst running on
 4.0.3.20-0xamarin1. The same problem was reported by the community as
 fixed in 4.0.1.44-1 arch linux, although whether that was downstream
 patch or not I'm not sure. Either way, it is currently broken in the
 'stable' version. The bug is marked as fixed in 4.3 trunk. Please can we
 have a backport / re-fix? This is causing serious grief for those of us
 who need a recent mono runtime for keepass, e.g. to get ssl support
 working via ca-certificates-mono.
 Thanks
 Stephen Parry

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




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

Re: [Mono-dev] bug #28777

2015-08-17 Thread Rodrigo Kumpera

The fix will be part of mono 4.2.0.

We could later backport it to mono 4.0.5 if 4.2 is not an option.

--
Rodrigo


On Sat, Aug 15, 2015 at 10:59 AM, Stephen G. Parry sgpa...@mainscreen.com
wrote:

 Hi All,
 We have what looks like a reversion of bug #28777
 (https://bugzilla.xamarin.com/show_bug.cgi?id=28777). This is causing
 KeePass to fail when saving compressed files whilst running on
 4.0.3.20-0xamarin1. The same problem was reported by the community as
 fixed in 4.0.1.44-1 arch linux, although whether that was downstream
 patch or not I'm not sure. Either way, it is currently broken in the
 'stable' version. The bug is marked as fixed in 4.3 trunk. Please can we
 have a backport / re-fix? This is causing serious grief for those of us
 who need a recent mono runtime for keepass, e.g. to get ssl support
 working via ca-certificates-mono.
 Thanks
 Stephen Parry

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

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

Re: [Mono-dev] Compile failure with -with-static_mono=no

2015-08-12 Thread Rodrigo Kumpera

That looks like a bug.

Do you mind filing a bug at bugzilla.xamarin.com and assign it to me?

--
Rodrigo

On Wed, Aug 12, 2015 at 12:08 PM, Martin Potter martin.pot...@faithlife.com
 wrote:

 We build Mono with the -with-static_mono=no for various reasons and it
 looks like this commit (
 https://github.com/mono/mono/commit/83e22234037a0e3560909b311811391efa117f22)
 broke the ability to compile with that flag. Attempting to build results in
 an undefined symbol error for mono_build_date.

 Undefined symbols for architecture x86_64:
   _mono_build_date, referenced from:
   _main in mono_sgen-main-sgen.o

 — Martin

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


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

Re: [Mono-dev] Compiling Mono with debug symbols to diagnose an issue with embedded Mono 4.0.2.5

2015-08-07 Thread Rodrigo Kumpera

This is caused because your mono was built with a bad TLS model and the
runtime is unable to find
the required offset.

Rebuild it using --with-tls=pthread should workaround your issue until
someone figures out what's wrong with
your setup.

On mixed mode debugging. It's incredibly complicated and there are no plans
to support it in the immediate future.

--
Rodrigo




On Tue, Aug 4, 2015 at 3:26 AM, jean-michel.perr...@csiro.au wrote:

 I have an R package with embedded Mono, on Linux, that is working on Mono
 3.12.x series but broken since  Mono 4.0.x.
 Crashes with:
 Assertion at sgen-alloc.c:774, condition `tlab_next_addr_offset != -1'
 not met

 Repro and details at https://github.com/jmp75/rClr/issues/7, but optional
 for this present question.

 What I am after is to step in debug mode through Mono, to diagnose and
 hopefully figure out a fix, but could not find a procedure to:

 * build/install mono from source (I know that) but with debug symbols
 * If the above is done, can I use MonoDevelop or other graphical front-end
 to attach to the process with embedded Mono and step through code with GDB.
 I can already attach  MonoDevelop to the R process and catch the crash, but
 the call stack is devoid of info and reference to the source code
 (presumably lacking the former debug symbols?)

 Any advice on how to go about it is welcome. I hope we can do better than
 command line gdb.

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

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

Re: [Mono-dev] Timing/race conditions

2015-05-28 Thread Rodrigo Kumpera

I'm not keen on introducing yield calls all over the place in the runtime
to work around bad test-environment combinations.

Adding them to the test suite it fine though.

Maybe the 200ms timeout is too low to deal with overloaded systems and must
be increased. The goal is to
detect bugs in the suspend code.

It would be much easier if unix had a way to transfer the quantum in a
yield call instead of just giving up on it.
We can definitely increase the timeout if that would help or make it
optional guarded behind an env var.

Does changing the timeout to infinite fix those crashes?


On Thu, May 21, 2015 at 4:20 PM, Neale Ferguson ne...@sinenomine.net
wrote:

 Hi,
 I have been experiencing some failures with the tests in mono/tests,
 particularly in a single core configuration.

 Firstly, the sleep test: when the delegated thread is started, the main
 thread goes to call the StopWatch start method which requires JITting.
 This involves gc interaction as objects are allocated. However, the
 delegated thread gets up and starts issuing GC.Collection() calls which
 end up occurring every 50 microseconds. This means the main thread never
 gets a chance to get out of the allocation phase so never gets to execute
 the stopwatch start, thread sleep etc. so the thread never ends. In a
 multi-core configuration this is not a problem and the test passes. I
 found by inserting a Thread.Yield() as the first method called in the
 delegated thread eliminates the problem [1].

 Secondly, the x-exit (e.g. thread-exit) tests will occasionally fail
 with an abort due to suspend_thread suspend took xxx ms, which is more
 than the allowed 200 ms” where xxx exceeds 200. This seems to be due to
 the exiting thread sometimes not getting to the stage of setting the
 thread-state to ThreadState_Stopped in the
 ves_icall_System_Environment_Exit() processing within the 200ms time
 period. Again, with multiple cores this is not a problem (or the problem
 is much rarer). I found by inserting a mono_thread_info_yield() prior to
 the suspend_internal_thread() in mono_thread_suspend_all_other_threads()
 fixes the problem [2]. I am not sure this is the best option and it’s
 still theoretically possible for the problem to still occur depending on
 how heavily the system is loaded. I was wondering if the setting of the
 state to ThreadState_stopped could be moved earlier in the process rather
 than in thread_cleanup() or if there’s another alternative.

 While the occasional failure has been experienced with some of the more
 pathological tests, the trouble is they happen nearly 100% of the time on
 a single core virtual machine, less often on a 2 core but in a virtual
 machine environment where there may be 100s of virtual machines competing
 for the real cores the probability of failure increases. In addition tests
 in the main test suite also have failed for the same reason as described
 in the second case.

 Neale

 [1] Circumvention for case 1 -

 --- a/mono/tests/sleep.cs
 +++ b/mono/tests/sleep.cs
 @@ -13,6 +13,7 @@ public class Tests
 public static int test_0_time_drift () {
 // Test the Thread.Sleep () is able to deal with time
 drifting due to interrupts
 Thread t = new Thread (delegate () {
 +   Thread.Yield();
 while (!finished)
 GC.Collect ();
 });

 [2] Circumvention for case 2 -

 --- a/mono/metadata/threads.c
 +++ b/mono/metadata/threads.c

 @@ -3132,6 +3147,8 @@ void mono_thread_suspend_all_other_threads (void)

 UNLOCK_THREAD (thread);

 +   mono_thread_info_yield ();
 +
 /* Signal the thread to suspend */
 suspend_thread_internal (thre

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

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

Re: [Mono-dev] do_rehash race

2015-05-28 Thread Rodrigo Kumpera

Good catch!

That's indeed a bug.

On Thu, May 28, 2015 at 2:35 PM, Neale Ferguson ne...@sinenomine.net
wrote:

 Hi,
  When a hash table exceeds a threshold a rehash operation is triggered. At
 the moment the new table is allocated and its address placed in the table
 field of the structure. The do_rehash also then copies the entries from
 the old table to the new. However, if there is another thread active that
 is doing lookups then there is a window where the new table is still being
 filled such that a lookup can fail. This is because the new table is made
 active before it has been copied. This proposed patch will fill the new
 table before swapping the old for the new table in the hash structure.

 Neale

 @@ -194,24 +196,24 @@ do_rehash (void *_data)
 Slot **table;

 /* printf (Resizing diff=%d slots=%d\n, hash-in_use -
 hash-last_rehash, hash-table_size); */
 -   hash-last_rehash = hash-table_size;
 current_size = hash-table_size;
 -   hash-table_size = data-new_size;
 /* printf (New size: %d\n, hash-table_size); */
 table = hash-table;
 -   hash-table = data-table;

 for (i = 0; i  current_size; i++){
 Slot *s, *next;

 for (s = table [i]; s != NULL; s = next){
 -   guint hashcode = ((*hash-hash_func) (s-key)) %
 hash-table_size;
 +   guint hashcode = ((*hash-hash_func) (s-key)) %
 data-new_size;
 next = s-next;

 -   s-next = hash-table [hashcode];
 -   hash-table [hashcode] = s;
 +   s-next = data-table [hashcode];
 +   data-table [hashcode] = s;
 }
 }
 +   hash-table_size = data-new_size;
 +   hash-last_rehash = hash-table_size;
 +   hash-table = data-table;
 return table;
  }


 Neale

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

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

Re: [Mono-dev] Can't run mono-3.12.X on Windows XP (Mono-devel-list Digest, Vol 120, Issue 4)

2015-04-10 Thread Rodrigo Kumpera

Good point, we should update the release notes / website to reflect this.

On Thu, Apr 9, 2015 at 11:39 PM, Keedi Kim keed...@gmail.com wrote:

 Thanks for the information. I was able to save time. :-)

 I also think it is appropriate to discontinue support windows XP. IMHO,
 it is important to notice about supporting XP is expired in Mono homepage.
 Since Mono is cross-platform dev environment, many people could
 misunderstand that they can run it everywhere if they want.

 Thanks!


 Best Regards,

 Keedi Kim

 
 http://keedi.pe.kr

 2015-04-10 5:59 GMT+09:00 Alexander Köplinger alex.koeplin...@outlook.com
 :

 FYI, I looked briefly into this and I think the only thing that XP
 doesn't have is InterlockedCompareExchange64 win api. msvc supports the 
 _InterlockedCompareExchange64
 intrinsic we could probably use instead, but I couldn't test it since the
 runtime wouldn't build for me in VS when I tried.

 I agree that XP is an EOL platform and we shouldn't invest any time in it
 (but it'd be pretty funny nonetheless if I could run asp.net 5 on a
 decades old OS *g*).

 -- Alex


  Date: Thu, 9 Apr 2015 21:43:44 +0100
  From: direct...@apebox.org
  To: mono-devel-list@lists.ximian.com
  Subject: Re: [Mono-dev] Can't run mono-3.12.X on Windows XP
 (Mono-devel-list Digest, Vol 120, Issue 4)

 
 
 
  On 09/04/15 18:48, Keedi Kim wrote:
   Hi, guys.
  
   I tried recent version of Mono (3.12.X) on Windows XP machine. I've
   installed Visual C++ 2013 (x86) redistributable, then installed Mono.
 But
   every mono related executables are failed to run. The error message
 was:
  
   mono.exe is not a valid win32 application
  
   I checked download page ( http://download.mono-project.com/archive/
 ) and
   installed previous older version which is
   mono-3.2.3-gtksharp-2.12.11-win32-0.exe then all mono binaries are
 executed
   well. I wonder if the mono supports Windows XP. Are there extra works
 to
   use recent version of mono in XP machine?
 
  So... The short version is it doesn't work with 3.12+, which
  are built with Visual Studio 2013.
 
  I tried building with parameters to enable legacy XP support, and it
  should *install* on XP now, with the 4.0.0 alpha release - but it will
  fail to work, due to needing commands in kernel32.dll (one of the most
  fundamental Windows components) which are only available in Vista or
 above.
 
  XP stopped having any support whatsoever from Microsoft more than a year
  ago, and is now a massive security risk for anyone running it - I don't
  want to invest any more time than I already have on XP support, until
  management tells me otherwise - at which point it's the runtime team's
  problem to stop relying on basic kernel32.dll functionality.
 
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list

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



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


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

Re: [Mono-dev] Snapshot of stack

2015-03-17 Thread Rodrigo Kumpera

kill -QUIT the target process

On Mon, Mar 16, 2015 at 8:10 PM, Greg Young gregoryyou...@gmail.com wrote:

 To be clear I know I can do if installed as a profiler but would
 prefer to do it from the outside

 On Tue, Mar 17, 2015 at 2:07 AM, Greg Young gregoryyou...@gmail.com
 wrote:
  I generally know how to snapshot the stack from outside code in C but
  I am not quite sure how to translate mono methods like can be done in
  a few ways (like this
  http://blogs.msdn.com/b/jmstall/archive/2005/11/28/snapshot.aspx) on
  the clr. Is there any equivalent way of getting this information in
  mono?
 
  Cheers,
 
  Greg
 
  --
  Studying for the Turing test



 --
 Studying for the Turing test
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Mono release headsup

2015-02-25 Thread 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 publ...@arocholl.com
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-list@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 publ...@arocholl.com
 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 kump...@gmail.com
 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-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list





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

Re: [Mono-dev] Mono release headsup

2015-02-24 Thread 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 publ...@arocholl.com 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 kump...@gmail.com
 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-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list



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

Re: [Mono-dev] Mono release headsup

2015-02-24 Thread 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 publ...@arocholl.com
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-list@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 publ...@arocholl.com
 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 kump...@gmail.com
 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-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list





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

[Mono-dev] Mono release headsup

2015-02-23 Thread 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-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Status for PR-1489 - AppSettings File attribute symlink

2015-01-26 Thread Rodrigo Kumpera

Hi David,

I guess that's a good rationale for the change.

Said that, why resolving the symlink is needed as they work transparently
when open/closing files?

On Fri, Jan 23, 2015 at 4:22 PM, David Curylo cury...@asme.org wrote:

 I got a little feedback from Rodrigo Kumpera on this PR 1489 and
 responded, but no more discussion since.  I’d like to clear up any issues
 and make any necessary changes to get this in.  The purpose is to get the
 appSettings file attribute to work properly when using a symlink to the
 application’s .config file, which I do so that I can keep userland
 applications in /usr and configuration in /etc.

 Any more feedback would be welcome, and if this approach is unacceptable,
 a suggested alternative would be much appreciated.

 Thanks,
 Dave

 On Jan 21, 2015, at 1:08 AM, David Curylo cury...@asme.org wrote:

  I have a pull request that’s been complete for a few weeks for adding
 symlink support to the path reference in the AppSettings File attribute.
 There was a little discussion and seems to be in good shape to merge, but
 it’s still waiting.  Any status on this one?
 
  https://github.com/mono/mono/pull/1489
 
  Is something more required?
 
  Thanks,
  Dave

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

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

Re: [Mono-dev] mono_class_get_name and generics

2015-01-21 Thread Rodrigo Kumpera

For class: mono_type_get_name (mono_class_get_type (class))

For method: mono_method_full_name

On Wed, Jan 21, 2015 at 11:39 AM, Greg Young gregoryyou...@gmail.com
wrote:

 Is there a helper method in mono to get class/method names including
 generics information as opposed to the canon `1

 Cheers,

 Greg

 --
 Studying for the Turing test
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Unix.Native

2015-01-12 Thread Rodrigo Kumpera

I agree we would be better with a better error message.

Said that, right now Mono.Posix lacks a more dedicated maintainer and it
would be lovely if you
could bring some love to it. :)

On Mon, Jan 12, 2015 at 8:39 PM, Greg Young gregoryyou...@gmail.com wrote:

 There are a ton to surface ... I just ran into this one :)

 In general I agree with you surfacing is better I was thinking just
 letting me call it if it doesn't understand it (or having a better
 message) would be useful. I spun for hours thinking what was wrong
 with my parameters to the call thinking it for some undocumented
 reason was returning EINVAL :)

 On Tue, Jan 13, 2015 at 3:30 AM, Rodrigo Kumpera kump...@gmail.com
 wrote:
  That would change the behavior of the function and translate into a more
  fragile API.
 
  The way to go is to surface this option.
 
  On Mon, Jan 12, 2015 at 8:23 PM, Greg Young gregoryyou...@gmail.com
 wrote:
 
  I figured out why after a while of looking. The C code translates the
  argument
 
  int Mono_Posix_FromFcntlCommand (int x, int *r)
 
  When its something that is not a known command it returns EINVAL.
  Might a better option be to try to let it pass through otherwise how
  could I call for instance a value on a ac?
 
  Cheers,
 
  Greg
 
  On Tue, Jan 13, 2015 at 2:28 AM, Greg Young gregoryyou...@gmail.com
  wrote:
   I have been trying to set F_NOCACHE via fcntl on a mac to no avail.
  
r = Syscall.fcntl
   (handle.DangerousGetHandle().ToInt32(), (FcntlCommand) MAC_F_NOCACHE,
   1);
} while (UnixMarshal.ShouldRetrySyscall ((int) r));
if (r == -1)
UnixMarshal.ThrowExceptionForLastError ();
  
   (EINVAL)
  
   I have tried
   48
   0x400
   and 0x4
   for F_NOCACHE though from
  
  
 https://github.com/realthunder/mac-headers/blob/master/usr/include/sys/fcntl.h#L256
  
   Given FcntlCommandFlags does not expose F_NOCACHE but it still should
   be fine to jam the value into the enum
  
   Has anyone set this before? Chances of finding this on google are
   slightly better than 0 :)
  
   Cheers,
  
   Greg
   --
   Studying for the Turing test
 
 
 
  --
  Studying for the Turing test
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list
 
 



 --
 Studying for the Turing test

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

Re: [Mono-dev] Unix.Native

2015-01-12 Thread Rodrigo Kumpera

That would change the behavior of the function and translate into a more
fragile API.

The way to go is to surface this option.

On Mon, Jan 12, 2015 at 8:23 PM, Greg Young gregoryyou...@gmail.com wrote:

 I figured out why after a while of looking. The C code translates the
 argument

 int Mono_Posix_FromFcntlCommand (int x, int *r)

 When its something that is not a known command it returns EINVAL.
 Might a better option be to try to let it pass through otherwise how
 could I call for instance a value on a ac?

 Cheers,

 Greg

 On Tue, Jan 13, 2015 at 2:28 AM, Greg Young gregoryyou...@gmail.com
 wrote:
  I have been trying to set F_NOCACHE via fcntl on a mac to no avail.
 
   r = Syscall.fcntl
  (handle.DangerousGetHandle().ToInt32(), (FcntlCommand) MAC_F_NOCACHE,
  1);
   } while (UnixMarshal.ShouldRetrySyscall ((int) r));
   if (r == -1)
   UnixMarshal.ThrowExceptionForLastError ();
 
  (EINVAL)
 
  I have tried
  48
  0x400
  and 0x4
  for F_NOCACHE though from
 
 https://github.com/realthunder/mac-headers/blob/master/usr/include/sys/fcntl.h#L256
 
  Given FcntlCommandFlags does not expose F_NOCACHE but it still should
  be fine to jam the value into the enum
 
  Has anyone set this before? Chances of finding this on google are
  slightly better than 0 :)
 
  Cheers,
 
  Greg
  --
  Studying for the Turing test



 --
 Studying for the Turing test
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Cycle4 - Reminders (Mono-devel-list Digest, Vol 115, Issue 45)

2014-11-26 Thread Rodrigo Kumpera

Hi Jo,

On the PRs.

PR1319 is for the aot cache, which is a feature that still under
development, so it's ok if it slips 3.12.
PR1297 is security related and I don't feel qualified to make a call on it.
Miguel and Sebastien are the experts on the matter.

On the windows fixes, I reviewed them and they look good. Could you either
make a PR with them against 3.12 or cherry pick
yourself if you have commit rights?

I'll update the Xamarin internal thread with a note about those commits.

--
Rodrigo


On Wed, Nov 26, 2014 at 8:05 AM, Jo Shields direct...@apebox.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1



 On 25/11/14 23:00, Rodrigo Kumpera wrote:
  Hi ppl,
 
  We're rounding up mono 3.12 as we speak. (y'all probably heard the
  github gossip about such a branch existing ;)
 
  This would be a great opportunity to gather feedback on what
  blocking bugs you've been facing that can be quickly addressed for
  this release.

 It'd be great to get PR1297 and PR1319 sorted in time for 3.12, plus a
 bunch of recent Windows/MSVC commits so I can work towards a stable
 3.12 Windows installer:

 9bdd77969a8f9057f3b46994135d39adb3ef216f
 1d6b8a75fa31d60e9ddbc0b9eddbf05ed3fb6c12
 9f6f6a9ccef9e65adc281b5c0609f79d1dce6fcf
 d2b8c8557b90dfaef3d3b582a847fda12630c680
 ab61b5c7ad106187b00be32bc356e2e197467745
 0279e7dc28c2d25ebe2fb87289b78c891ff84a15
 cf4d77d21d2d15f5775a1cf72bfe8486e5a0dff5
 67da1215f33fb20fe948402d8aa8e38a82c29598
 076e80f725d16d85d74e8aecbe281af53ebc62c2

 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQEcBAEBAgAGBQJUddAbAAoJEMkPnLkOH60MIfUIAIiPpCFnypB5xjirQ9hyPOZV
 clunW3vzrZ6WO/CXxmKQRjyF8P/awXRW1EBMZX+U8rpRdG15tNL1OveLg4e84Su/
 NUjdsUykouGLtfwGK7/pM8jZBE4/ewciR1ygaK+fuw9vvvnN95pvJTcqgIJXNi40
 1OEusLP9aLwJXOkxYQRlGZMF2S7KfjPXU5vHi5L2YGknlz0u+73I1eT4wdPzWp4K
 YVHESxEqcQDzSWYSUib8Jbikcw/hzKkqiQq6kK8rwOY5qXtmqobs1Hlab87FJCdY
 niQhZuUcjDYaQb6OMLO0vOu4ckoacVgu2joDl4kcReI/Ygr87/gbmheZGqU73UY=
 =G4dc
 -END PGP SIGNATURE-
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Cycle4 - Reminders

2014-11-25 Thread Rodrigo Kumpera

Hi ppl,

We're rounding up mono 3.12 as we speak. (y'all probably heard the github
gossip about such a branch existing ;)

This would be a great opportunity to gather feedback on what blocking bugs
you've been facing that can be quickly addressed for this release.


--
Rodrigo



On Mon, Nov 24, 2014 at 5:35 PM, Miguel de Icaza mig...@xamarin.com wrote:

 Hello team,

 As you guys have seen we started Cycle4, and we are now branching all the
 modules.

 At this point, we are not adding new features, and we only should land
 fixes for blocker/critical/major bugs.  Some of the lesser bugs, features
 will at this point be delayed until the next release cycle.

 If in doubt, consult with your manager.

 Miguel.

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


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

Re: [Mono-dev] SetThreadPriority patch for mono-3.2.8

2014-11-07 Thread Rodrigo Kumpera

Up to you to use a new PR or update  reopen the existing one.

Just remember to ping me either here on or github to keep me honest and the
review cycle short.

Thanks a lot for looking into this.

--
Rodrigo

On Fri, Nov 7, 2014 at 4:10 AM, Bent Bisballe Nyeng d...@aasimon.org
wrote:

 I'll look into the issues you describe. Should I have the PR reopened once
 I get it done or should I open up a new one?

 Kind regards
 Bent Bisballe Nyeng

 On 11/06/14 17:35, Rodrigo Kumpera wrote:

 PR 1391 cannot be accepted for multiple reasons:

 -The commit message is empty and has no licensing;
 -It changes MonoInternalThread layout for no good reason, the introduced
 field is not used anywhere;
 -It's adding code to the io-layer for which we don't want to continue to
 expand;

 How to do it in way that's mergeable?

 Add a pair of functions to utils/mono-threads.h that get/set the priority.
 Implement that functions on all backends or add stubs when appropriate.
 Use this new API from metadata/threads.h to implement the managed
 functionality;
 Use C89.
 License the code under the MIT license.

 --
 Rodrigo





 On Thu, Nov 6, 2014 at 9:16 AM, Bent Bisballe Nyeng d...@aasimon.org
 mailto:d...@aasimon.org wrote:

 I have made pull request now:
 https://github.com/mono/mono/__pull/1391
 https://github.com/mono/mono/pull/1391

 I have updated the patch to work with HEAD and tested it. Everything
 seems to work as expected.

 I'm a bit new to the whole github concept, so forgive me if I have
 not done everything by the book ;-)

 Kind regards
 Bent Bisballe Nyeng

 On 11/06/14 12:37, Alexander Köplinger wrote:

 There is a PR that also claims to implement SetThreadPriority
 (https://github.com/mono/mono/__pull/1272
 https://github.com/mono/mono/pull/1272), but it has many other
 unrelated changes, so not in a state to be merged.
   From a quick look, your patch seems to be much more focused
 and thus
 more likely to get merged. Can you open a pull request on GitHub?

 -- Alex


Date: Thu, 6 Nov 2014 09:12:02 +0100
From: d...@aasimon.org mailto:d...@aasimon.org
To: mono-devel-list@lists.ximian.__com
 mailto:mono-devel-list@lists.ximian.com
Subject: [Mono-dev] SetThreadPriority patch for mono-3.2.8
   
Hi mono devs
   
I created a patch for SetThreadPriority support in
 mono-3.2.8 and would
very much like som feedback on it.
It can be found here:
https://gist.github.com/__aasimon/c8ae6fc3cf5d9b82b6ca
 https://gist.github.com/aasimon/c8ae6fc3cf5d9b82b6ca
Comments are welcome both here on the list as well as on the
 actual gist
paste.
   
Kind regards
Bent Bisballe Nyeng
_
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.__com
 mailto:Mono-devel-list@lists.ximian.com
http://lists.ximian.com/__mailman/listinfo/mono-devel-__list
 http://lists.ximian.com/mailman/listinfo/mono-devel-list


 _
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.__com
 mailto:Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/__mailman/listinfo/mono-devel-__list
 http://lists.ximian.com/mailman/listinfo/mono-devel-list



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

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

Re: [Mono-dev] SetThreadPriority patch for mono-3.2.8

2014-11-06 Thread Rodrigo Kumpera

PR 1391 cannot be accepted for multiple reasons:

-The commit message is empty and has no licensing;
-It changes MonoInternalThread layout for no good reason, the introduced
field is not used anywhere;
-It's adding code to the io-layer for which we don't want to continue to
expand;

How to do it in way that's mergeable?

Add a pair of functions to utils/mono-threads.h that get/set the priority.
Implement that functions on all backends or add stubs when appropriate.
Use this new API from metadata/threads.h to implement the managed
functionality;
Use C89.
License the code under the MIT license.

--
Rodrigo





On Thu, Nov 6, 2014 at 9:16 AM, Bent Bisballe Nyeng d...@aasimon.org
wrote:

 I have made pull request now: https://github.com/mono/mono/pull/1391

 I have updated the patch to work with HEAD and tested it. Everything seems
 to work as expected.

 I'm a bit new to the whole github concept, so forgive me if I have not
 done everything by the book ;-)

 Kind regards
 Bent Bisballe Nyeng

 On 11/06/14 12:37, Alexander Köplinger wrote:

 There is a PR that also claims to implement SetThreadPriority
 (https://github.com/mono/mono/pull/1272), but it has many other
 unrelated changes, so not in a state to be merged.
  From a quick look, your patch seems to be much more focused and thus
 more likely to get merged. Can you open a pull request on GitHub?

 -- Alex


   Date: Thu, 6 Nov 2014 09:12:02 +0100
   From: d...@aasimon.org
   To: mono-devel-list@lists.ximian.com
   Subject: [Mono-dev] SetThreadPriority patch for mono-3.2.8
  
   Hi mono devs
  
   I created a patch for SetThreadPriority support in mono-3.2.8 and would
   very much like som feedback on it.
   It can be found here:
   https://gist.github.com/aasimon/c8ae6fc3cf5d9b82b6ca
   Comments are welcome both here on the list as well as on the actual
 gist
   paste.
  
   Kind regards
   Bent Bisballe Nyeng
   ___
   Mono-devel-list mailing list
   Mono-devel-list@lists.ximian.com
   http://lists.ximian.com/mailman/listinfo/mono-devel-list


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

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

Re: [Mono-dev] PR944 - Improve COM error handling

2014-10-30 Thread Rodrigo Kumpera

On Thu, Oct 30, 2014 at 3:13 AM, Eberhard Beilharz e...@sil.org wrote:

  The code in your pull request is windows specific so it won't work on
 unix.

  No, it isn't. It's possible to build a Unix library that emulates the
 Windows COM implementation - as we did it in our projects (
 https://github.com/sillsdev/libcom), and a mapping of oleaut32.dll to
 that library.

 The code in the pull request deals with the possibility that there is no
 suitable COM implementation available, but if there is it'll make use of it.



I see, you're right, I didn't pay enough attention to the change.
Perhaps we could add a wiki page to mono-project that explains this and
link to your implementation as a reference (if you feel inclined to).

Said that, catching Exception is not ideal, it will break some threading
operations such as soft aborts that are not automatically rethrown or
internal VM errors.

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

Re: [Mono-dev] [eglib] Warning: assertion function returning

2014-10-30 Thread Rodrigo Kumpera

Since the noreturn behavior is not verifiable by the compiler (it's part of
the API contract) we can a hack to silence the warning.

On Thu, Oct 30, 2014 at 12:08 PM, Alex J Lennon 
ajlen...@dynamicdevices.co.uk wrote:

 Hi,

 I'm seeing an eglib warning about an assertion handling function with a
 G_GNUC_NORETURN attribute that is returning.

 goutput.c: In function ‘monoeg_assertion_message’:
 goutput.c:135:1: warning: ‘noreturn’ function does return [enabled by
 default]

 I'm wondering how this should be resolved, ie. whether this function
 should block, whether the attribute should be removed, or something else?

 If the assertion handler should block then is while(1); sensible, or a
 very bad idea?

 Thanks,

 Alex


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

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

[Mono-dev] Fwd: [eglib] Warning: assertion function returning

2014-10-30 Thread Rodrigo Kumpera

Forgot to CC dev

-- Forwarded message --
From: Rodrigo Kumpera kump...@gmail.com
Date: Thu, Oct 30, 2014 at 1:57 PM
Subject: Re: [Mono-dev] [eglib] Warning: assertion function returning
To: Alex J Lennon ajlen...@dynamicdevices.co.uk

On Thu, Oct 30, 2014 at 12:34 PM, Alex J Lennon 
ajlen...@dynamicdevices.co.uk wrote:

  Hi Rodrigo,

 On 30/10/2014 17:28, Rodrigo Kumpera wrote:

 Since the noreturn behavior is not verifiable by the compiler (it's part
 of the API contract) we can a hack to silence the warning.

 If that's what's wanted that's fine by me of course. Easily done.

 But I don't understand: Surely the fact the compiler is complaining shows
 that it does know that the function is returning, when it has been told via
 the attributing that the function should not?

 As a test, if I add a while(1); at the bottom of the function then the
 complaint goes away as the compiler knows that the return is unreachable.

 I am guessing I am misunderstanding your point?

 More importantly, should the assertion handler return or not... ?

The problem is that the abort happens through the logging callback and that
can't be verified by the compiler.

Any well behaved implementation must make sure it does not return. I think
adding a while (1); at the end is a good enough solution.
We want the noreturn semantics there.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] PR1375: cleanup

2014-10-29 Thread Rodrigo Kumpera

I know that :) is in there.

On Tue, Oct 28, 2014 at 11:16 AM, Greg Young gregoryyou...@gmail.com
wrote:

 Can I buy a vowel?


 On Tuesday, October 28, 2014, Miguel de Icaza mig...@xamarin.com wrote:



 ▉, ▉▉ . ▉▉▉ - ▉▉.   ▉▉, , ,
 ▉▉

 MIguel

 On Tue, Oct 28, 2014 at 1:57 PM, Alexander Köplinger 
 alex.koeplin...@outlook.com wrote:
 
   Sounds good!
 
  Can you share what large patch you're working on or is that a secret
 new feature? :-)
 
  -- Alex
 
 
  
  From: mig...@xamarin.com
  Date: Tue, 28 Oct 2014 12:47:40 -0400
  Subject: Re: [Mono-dev] PR1375: cleanup
  To: champetier.etie...@gmail.com; alex.koeplin...@outlook.com
  CC: mono-devel-list@lists.ximian.com
 
 
  Hey,
 
  I love this patch, and I also love the patch from Alexander to remove
 deprecated code.
 
  But we have a relatively large patch that changes a lot of files, and I
 am afraid that landing these changes now will make our currently forked
 tree a pain to merge.   We need about two more weeks to merge those
 patches, then we can proceed to remove this stuff.
 
  Miguel
 
  On Tue, Oct 28, 2014 at 10:45 AM, Etienne Champetier 
 champetier.etie...@gmail.com wrote:
 
  Hi
 
  while investigating a bug in System.Web, there was a lot of (now
 useless) TARGET_J2EE ifdef.
  This PR remove all TARGET_J2EE ifdef (using unifdef).
  I also remove all mainsoft stuff (it's not working anymore as i
 understand it).
  To finish the cleanup remove *.jvm* files and folders (TARGET_JVM was
 remove in PR1200)
 
  https://github.com/mono/mono/pull/1375
 
  Regards
  Etienne
 
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list
 
 



 --
 Studying for the Turing test


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


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

Re: [Mono-dev] PR944 - Improve COM error handling

2014-10-29 Thread Rodrigo Kumpera

The code in your pull request is windows specific so it won't work on unix.

Mono works with unix com implementations such as xpcom.

On Wed, Oct 29, 2014 at 3:06 PM, Eberhard Beilharz e...@sil.org wrote:

 Hi,

 To revive one of my old pull requests: #944 implements some missing
 pieces related to COM error handling. Namely it sets the error info in
 GetHRForException() and converts the HRESULT values to managed exceptions.

 https://github.com/mono/mono/pull/944

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

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

Re: [Mono-dev] elimination of TARGET_J2EE/TARGET_JVM ?

2014-10-24 Thread Rodrigo Kumpera

They are no longer in use but we're not in a rush to remove the from the
code base.

If it's making it hard for you to read a piece of code, remove them and
submit a pull request - we'd love to
kill more of those defines. :)

On Fri, Oct 24, 2014 at 2:10 AM, Etienne Champetier 
champetier.etie...@gmail.com wrote:

 Hi,

 Is TARGET_J2EE still in use (and TARGET_JVM), because it really complicate
 some class?

 Thanks in advance
 Etienne

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


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

Re: [Mono-dev] Memleak in mono_domain_unload

2014-10-24 Thread Rodrigo Kumpera

Please file a bug report with your test case so we can fix any leaks.



On Fri, Oct 24, 2014 at 7:56 AM, Vardar Sahin sakirs...@gmail.com wrote:

 Hello to all,

 I noticed that mono_domain_unload is leaking memory. I wrote a small test
 in my application
 where I create a domain, load an assembly into it, execute the C# main
 which does nothing and then call mono_domain_unload. The assembly and all
 its references are loaded with mono_image_open_from_data. It seems like
 Unity somehow solved this problem.

 Is there any work to fix this? Or any hint for me?

 Best regards
 Sahin



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


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

Re: [Mono-dev] How to find extern definition for MonoIO void Lock(

2014-09-15 Thread Rodrigo Kumpera

If it's an icall, it's either on that table of throw explicit calls to
register it.

If it's a pinvoke, it's up to the user to specify the target library

On Sat, Sep 13, 2014 at 9:54 AM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

  From: Rodrigo Kumpera [mailto:kump...@gmail.com]
 
  See icall-def.h

 Thanks.  How did you know that?

 Since I look in there, I can very clearly see a matching method
 definition, and what it's connected to, and I was then able to find the
 implementation in source and get all the answers I was looking for - But
 the method definition I was looking for was Lock which is quite a generic
 search term in hundreds of locations.

 I'd like to know how I can find that again next time I need it.
 Especially if it's some completely unrelated application (not mono source)
 where memorization isn't going to help me.

 When an extern specifies the dll it comes from, that makes it completely
 obvious where to look.  But lots of times externs don't specify a dll,
 and my best guess after that, is that the compiler / linker / something in
 Makefile or the csproj must be including it, which could be a horrible pain
 to track down.  I'm hoping there's an easier or better way...

 Thanks again.  Helped a bunch this time.

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

Re: [Mono-dev] Mono 3.10 Threadpool requires remoting??

2014-09-15 Thread Rodrigo Kumpera

Minimal builds are not supported for general consumption, use at your own
risk.



On Sat, Sep 13, 2014 at 12:03 PM, Chris Tacke cta...@opennetcf.com wrote:

 This may seem like a simplistic question, but how do I explicitly set a C#
 preprocessor directive when manually building with make?  I'd like to *not*
 modify the makefile if I can avoid it, since I'm trying to write procedures
 that can be applied on future builds with a clean pull from git.

 -Chris



  -Original Message-
  From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
  boun...@lists.ximian.com] On Behalf Of Chris Tacke
  Sent: Saturday, September 13, 2014 10:44 AM
  To: DavidKarlas; mono-devel-list@lists.ximian.com
  Subject: Re: [Mono-dev] Mono 3.10 Threadpool requires remoting??
 
  The procedure I used for building both was identical (I wrote down the
  procedures the first time and followed then exactly the second).
 
  The configuration command used was:
 
  ./configure --prefix=/usr/local
 --enable-minimal=aot,profiler,com,remoting -
  -with-profile2=no --with-profile4=no
 
  So it's definitely a difference between the two builds.
 
  -Chris
 
 
   -Original Message-
   From: mono-devel-list-boun...@lists.ximian.com [mailto:
 mono-devel-list-
   boun...@lists.ximian.com] On Behalf Of DavidKarlas
   Sent: Saturday, September 13, 2014 1:41 AM
   To: mono-devel-list@lists.ximian.com
   Subject: Re: [Mono-dev] Mono 3.10 Threadpool requires remoting??
  
   You probably defined DISABLE_REMOTING in 3.2.7 and forgot to define it
 in
   3.10...
  
  https://github.com/mono/mono/blob/master/mcs/class/corlib/System/Del
   egate.cs#L614
  
  
  
   --
   View this message in context: http://mono.1490590.n4.nabble.com/Mono-
  3-
   10-Threadpool-requires-remoting-tp4663848p4663851.html
   Sent from the Mono - Dev mailing list archive at Nabble.com.
   ___
   Mono-devel-list mailing list
   Mono-devel-list@lists.ximian.com
   http://lists.ximian.com/mailman/listinfo/mono-devel-list
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Mono 3.10 Threadpool requires remoting??

2014-09-15 Thread Rodrigo Kumpera

It's not a regression, it's just a configuration we don't support as a
project.

Feel free to fix it on your own and make a pull request.



On Mon, Sep 15, 2014 at 11:24 AM, Chris Tacke cta...@opennetcf.com wrote:

 Mono itself, being open source is “use at my own risk”.  Anything that I
 build from source, I’d assume was “use at my own risk”.  I understand and
 accept that risk.



 Maybe it’s just that it’s Monday, but that response sure reads to me as
 “There’s been a regression in the build system between 3.2 and 3.10 and
 though you’ve taken the time to report it, we don’t really care.”



 When I find and fix this problem locally, should I bother to report it?



 -Chris









 *From:* Rodrigo Kumpera [mailto:kump...@gmail.com]
 *Sent:* Monday, September 15, 2014 11:18 AM
 *To:* Chris Tacke
 *Cc:* DavidKarlas; mono-devel-list@lists.ximian.com

 *Subject:* Re: [Mono-dev] Mono 3.10 Threadpool requires remoting??



 Minimal builds are not supported for general consumption, use at your own
 risk.







 On Sat, Sep 13, 2014 at 12:03 PM, Chris Tacke cta...@opennetcf.com
 wrote:

 This may seem like a simplistic question, but how do I explicitly set a C#
 preprocessor directive when manually building with make?  I'd like to *not*
 modify the makefile if I can avoid it, since I'm trying to write procedures
 that can be applied on future builds with a clean pull from git.

 -Chris



  -Original Message-
  From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
  boun...@lists.ximian.com] On Behalf Of Chris Tacke
  Sent: Saturday, September 13, 2014 10:44 AM
  To: DavidKarlas; mono-devel-list@lists.ximian.com
  Subject: Re: [Mono-dev] Mono 3.10 Threadpool requires remoting??
 

  The procedure I used for building both was identical (I wrote down the
  procedures the first time and followed then exactly the second).
 
  The configuration command used was:
 
  ./configure --prefix=/usr/local
 --enable-minimal=aot,profiler,com,remoting -
  -with-profile2=no --with-profile4=no
 
  So it's definitely a difference between the two builds.
 
  -Chris
 
 
   -Original Message-
   From: mono-devel-list-boun...@lists.ximian.com [mailto:
 mono-devel-list-
   boun...@lists.ximian.com] On Behalf Of DavidKarlas
   Sent: Saturday, September 13, 2014 1:41 AM
   To: mono-devel-list@lists.ximian.com
   Subject: Re: [Mono-dev] Mono 3.10 Threadpool requires remoting??
  
   You probably defined DISABLE_REMOTING in 3.2.7 and forgot to define it
 in
   3.10...
  
  https://github.com/mono/mono/blob/master/mcs/class/corlib/System/Del
   egate.cs#L614
  
  
  
   --
   View this message in context: http://mono.1490590.n4.nabble.com/Mono-
  3-
   10-Threadpool-requires-remoting-tp4663848p4663851.html
   Sent from the Mono - Dev mailing list archive at Nabble.com.
   ___
   Mono-devel-list mailing list
   Mono-devel-list@lists.ximian.com
   http://lists.ximian.com/mailman/listinfo/mono-devel-list
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list



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

Re: [Mono-dev] How to find extern definition for MonoIO void Lock(

2014-09-12 Thread Rodrigo Kumpera

See icall-def.h

On Fri, Sep 12, 2014 at 1:08 PM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

  I am trying to find the definition for this:

 mcs/class/corlib/System.IO/MonoIO.cs:   public
 extern static void Lock (...)



 I'd like to know how the Lock() method is implemented, so I can understand
 the valid parameters.  (I know the two ints must be = 0, but I'd like to
 know what else.  And generally speaking, know how it's implemented so I can
 know its limitations).

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


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

Re: [Mono-dev] peverify vs mono --verify-all

2014-09-12 Thread Rodrigo Kumpera

peverify does verify everything eagerly and do very strict checks.

mono --verify-all disables some of the strict checks and does perform the
checking lazily only on what's executed.

Could you file a bug with your binary attached so I can take a look on
fixing this assert (I'm the author of this particular assert).

--
Rodrigo

On Fri, Sep 12, 2014 at 3:28 PM, mono user mono.user...@gmail.com wrote:

 I would really appreciate help with this. I need to check that a dll I
 generated via reflection is correct, however peverify won't even start:

 [me@somewhere]$ peverify tmp.dll
 Could not load class with token 202
 * Assertion at class.c:5607, condition `!mono_loader_get_last_error ()'
 not met

 Aborted

 On the other hand,

 mono --verify-all --security=validil tmp.dll

 ponders things for a bit, then starts executing the dll file (it's really
 an executable).

 Could someone please tell me if the two commands should find the same
 problems  or not. Also, can I just take it that the dll is fine if the
 Microsoft implementation of peverify says so? Any hints on what to try to
 get the Mono implementation of peverify working would be especially helpful.

 I am using mono-3.10.0-branch because it fixes a problem manifesting
 itself with a triggered assertion inside mono (many thanks to Zoltan for
 the fix). I have seen similar behaviour under other recent versions of Mono.







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


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

Re: [Mono-dev] mono_thread_manage causes subsequent mono_jit_cleanup call to hang?

2014-09-11 Thread Rodrigo Kumpera

How about internally renaming mono_thread_manage and add a no-op version of
it.

It would retain compatibility with wine and would not further complicate
the shutdown sequence.

This assumes that there's no good use case for calling the two
independently.

--
Rodrigo

On Wed, Sep 10, 2014 at 5:58 PM, Vincent Povirk madewokh...@gmail.com
wrote:

  2. Should Mono be fixed to account for what I was doing? I'd prefer to
  have code that is as version-independent as possible. Maybe mono could
  somehow detect that mono_thread_manage was already completed by the
  current thread, and do nothing in this case?

 I wrote a patch using this approach:

 https://github.com/madewokherd/mono/commit/7baf38fd134f92f7d80f43bb3cf6d77122b3eb1e

 But I'm really not sure about this.

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

Re: [Mono-dev] Mono crash

2014-09-06 Thread Rodrigo Kumpera

This last backtrace looks perfectly fine.

It's the GC suspend signal handler been executed.


On Sat, Sep 6, 2014 at 10:39 AM, mono user mono.user...@gmail.com wrote:

 I am afraid that max-heap-size might not be the reason. I am seeing the
 crashes at different levels of memory usage.

 I have checked that setting the heap size to a small value does not result
 in a crash - an exception is thrown instead. It does not appear to be the
 same OOM exception as under .net, but there is no crash with mono
 stacktraces etc. In contrast, the issue I need help with produces several
 native stacktraces and no IL stacktrace.

 Also, it would be be hard to explain why running under a debugger might
 make the problem go away if that was the reason.

 BTW, The message at the end of this stacktrace didn't use to happen under
 mono 3.6 and might be an additional indication that some mono internals are
 rather ill at crashtime, though in principle it could be unprovoked and/or
 unrelated gdb breakage.

 Thread 1 (Thread 0x7fedacfca780 (LWP 30016)):
 #0  0x7fedac1b19e4 in sigsuspend () from /lib64/libc.so.6
 #1  0x005cbf54 in suspend_thread (sig=value optimized out,
 siginfo=value optimized out, context=0x7fffaa5a8440) at
 sgen-os-posix.c:113
 #2  suspend_handler (sig=value optimized out, siginfo=value optimized
 out, context=0x7fffaa5a8440) at sgen-os-posix.c:140
 #3  signal handler called
 #4  0x7fedac51e5ba in pthread_cond_wait@@GLIBC_2.3.2 () from
 /lib64/libpthread.so.0
 #5  0x0060d99c in _wapi_handle_timedwait_signal_handle
 (handle=0x280a, timeout=0x0, alertable=1, poll=value optimized
 out) at handles.c:1596
 #6  0x0061fe4b in WaitForSingleObjectEx (handle=0x280a,
 timeout=4294967295, alertable=1) at wait.c:194
 #7  0x0058233c in ves_icall_System_Threading_Thread_Join_internal
 (this=0x7fedacf242d0, ms=-1, thread=0x280a) at threads.c:1306
 #8  0x414e04de in ?? ()
 #9  0x7feda5c50908 in ?? ()
 #10 0x7fffaa5a8fa0 in ?? ()
 #11 0x0001 in ?? ()
 #12 0x7fffaa5a8fa0 in ?? ()
 #13 0x414c5c40 in ?? ()
 #14 0x00a0ba50 in ?? ()
 #15 0x414e046c in ?? ()
 #16 0x7fffaa5a8d40 in ?? ()
 #17 0x7fffaa5a8b30 in ?? ()
 #18 0x7feda45a51b3 in System.Threading.Thread:Join
 (this=../../gdb/dwarf2-frame.c:694: internal-error: Unknown CFI
 encountered.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) [answered Y; input not from terminal]
 ../../gdb/dwarf2-frame.c:694: internal-error: Unknown CFI encountered.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Create a core file of GDB? (y or n) [answered Y; input not from terminal]





 On 6 September 2014 08:58, Andrea Francesco Iuorio 
 andreafrancesco.iuo...@gmail.com wrote:

 Stupid question but someone have to ask: have you set MONO_GC_PARAMS for
 use a bigger heap ? You can set mono heap size appending
 max-heap-size= to your MONO_GC_PARAMS.


 2014-09-05 20:24 GMT+02:00 mono user mono.user...@gmail.com:

 Sorry, I meant to say I was using 3.8.0, not 3.0.8. I'll try the git
 version later.


 On 5 September 2014 19:19, Juan Cristóbal Olivares 
 cristo...@cxsoftware.com wrote:

 I think you should try with mono 3.8 or, even better, with the git
 version.


 On Fri, Sep 5, 2014 at 1:26 PM, mono user mono.user...@gmail.com
 wrote:

 It was suggested I try the boehm garbage collector. My code dies
 quickly, saying Too many heap sections: Increase MAXHINCR or
 MAX_HEAP_SECTS

 It was also suggested the reason might be that I am running out of
 memory. That is a possibility, though I now have a crash that happens when
 Mono is using about 12G of virtual space on a 64G machine. I still wanted
 to verify if the reason was a failed allocation, and ran mono in a
 debugger. The code then executed fine, suggesting that lack of resources
 might not be the reason for the crashes. The same code fails reliably when
 started from the command line. Having said that, something probably does
 think that memory has run out. I have seen error messages along the lines
 of Error: Garbage collector could not allocate 16384 bytes of memory for
 major heap section. even though there is plenty of memory available. I
 have also seen clean out-of-memory crashes (i.e. my code terminates 
 cleanly
 with a clear error message and no mono stacktrace(s)).

 I am afraid I cannot provide an example, except possibly if we can
 narrow down the cause so I can reproduce the crash using a small amount of
 code and without using any proprietary data (that is currently needed to
 reproduce the crashes). I am running 3.0.8.

 Many thanks for any help/suggestions/etc.



 On 22 August 2014 15:55, mono user mono.user...@gmail.com wrote:

 Is there anything I can do to avoid the following crash? I am running
 Mono 3.6.0. I

Re: [Mono-dev] OracleClient.Oci and GC

2014-08-25 Thread Rodrigo Kumpera

Finalization is not deterministic, it depends on the GC been able to
collect all related objects.

Maybe you have things keeping some of those 700 objects around?

The way I test those things in a way that is reasonably reliable is:

var t = new Thread (myTest);

t.Start ();
t.Join ();

GC.Collect ();
GC.WaitForPendingFinalizers ();

//now verify the result.




On Mon, Aug 25, 2014 at 11:08 AM, Neale Ferguson nealefergu...@verizon.net
wrote:

 I implemented a Dispose method for OracleParameter:

 ~OracleParameter ()
 {
 Dispose(false);
 }

 public void Dispose ()
 {
 Dispose (true);
 }

 void Dispose (bool disposing)
 {
 if (disposing) {
 GC.SuppressFinalize(this);
 }
 if (indicator != IntPtr.Zero) {
 Marshal.FreeHGlobal (indicator);
 indicator = IntPtr.Zero;
 }
 }

 However, when I run the test program I see 1251 constructors being run but
 only 572 destructors/disposals. How do I reconcile this disparity?

 Neale

 On Aug 22, 2014, at 11:40 AM, Neale Ferguson nealefergu...@verizon.net
 wrote:

  Thanks. I've made changes to OciDefineHandle and have cured nearly all
 the failures I had been experiencing. I have started on OracleParameter as
 it has an object called indicator that is used by the OCIBindxxx calls and
 appears to suffer from the same problem. I was allocating the object in
 native memory in the constructors and was going to free them in a
 destructor. However, in my test runs I see I'm allocating 1200+ objects but
 only freeing ~900. Would you elaborate on your final comment failing to
 dispose... as I'm reading this as I don't need to Marshal.FreeHGlobal()
 the object I allocated in the constructors.
 
  Neale
 
  On Aug 22, 2014, at 11:31 AM, Rodrigo Kumpera kump...@gmail.com wrote:
 
  Hey Neale,
 
  You can safely pass interior pointers to pinvoke without fearing the
 object been collected for the duration of the call.
  Mind that you have to correctly use specify in/out/ref depending on the
 copy semantics you need.
 
  Problems only arise when native keeps that pointer after the call
 finishes, this can result in the object been moved
  as the GC has no visibility into the native heap.
 
  For those cases you can either create a pinning GC handle to the victim
 object or you can allocate a chunk of native
  memory that will be shared between managed and native to store the
 desired value. Both options suck, TBH.
 
  I'd say go with the native chunk of code if you can't lexically scope
 the pinning regions, it will be more reliable as
  failing to dispose the object won't lead to permanent leaks.


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

Re: [Mono-dev] OracleClient.Oci and GC

2014-08-22 Thread Rodrigo Kumpera

Mono does conservative scanning of the native stack, so once the pointer
has crossed over to native, the containing object will remain pinned.




On Fri, Aug 22, 2014 at 9:45 AM, Neale Ferguson nealefergu...@verizon.net
wrote:

 I am also wondering about the parameters in some of the OCIBind
 methods and the OCIDefineByPosPtr that are ref IntPtr. There's a small
 window when GC could suspend the thread where the IntPtr object is also
 moved before the OCI call has completed and set the underlying IntPtr field.

 On Aug 21, 2014, at 9:48 PM, Miguel de Icaza mig...@xamarin.com wrote:

 Hello,

 Wanted to follow up to Neale's comment, as he clarified an important point
 that I overlooked.

 There are two ref parameters that are being passed to unmanaged code, both
 point to fields inside the OciDefineHandle managed type.

 Neale's analysis is correct: the object might move and with it, the two
 short variables that were passed to OciDefineByPos.   This would explain
 the crashes that developers are experiencing with the OracleClient provider
 and Sgen.

 The proposed fix is one possible solution: to allocate the values outside
 of the managed heap for both the short values.

 There is another suspicious use that we should look into.  The
 OciDefineByPos method is actually a set of overloaded methods, with
 different types for the value parameter.It is often a handle that is
 usually allocated via an unmanaged API.   But there are a few troubling
 uses:

- ref value: used in DefineTimeStamp
- ref value: when passing the reference to a Handle defined in a
separate class, DefineLob, DefineInterval

 The above does not look very easy to fix.

 Given that these are resources that should be explicitly disposed, perhaps
 what we should do is allocate a GCHandle for the OciDefineHandle object
 (from OciStatementHandle, the one place that creates these objects) and
 also create GCHandles for the objects that we use their Handle fields from
 (in DefineTimeStamp, DefineLob, DefineInterval) and release the GCHandles
 in the respective Dispose methods.

 Miguel


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


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

Re: [Mono-dev] OracleClient.Oci and GC

2014-08-22 Thread Rodrigo Kumpera

Hey Neale,

You can safely pass interior pointers to pinvoke without fearing the object
been collected for the duration of the call.
Mind that you have to correctly use specify in/out/ref depending on the
copy semantics you need.

Problems only arise when native keeps that pointer after the call finishes,
this can result in the object been moved
as the GC has no visibility into the native heap.

For those cases you can either create a pinning GC handle to the victim
object or you can allocate a chunk of native
memory that will be shared between managed and native to store the desired
value. Both options suck, TBH.

I'd say go with the native chunk of code if you can't lexically scope the
pinning regions, it will be more reliable as
failing to dispose the object won't lead to permanent leaks.











On Fri, Aug 22, 2014 at 11:11 AM, Neale Ferguson nealefergu...@verizon.net
wrote:

 Is that just a comment on my ref IntPtr question or the use of ref with
 the OCI stuff in general?

 On Aug 22, 2014, at 10:45 AM, Rodrigo Kumpera kump...@gmail.com wrote:

  Mono does conservative scanning of the native stack, so once the pointer
 has crossed over to native, the containing object will remain pinned.

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

Re: [Mono-dev] thread6 test

2014-08-19 Thread Rodrigo Kumpera

Thread 1 started

Count: 0

cought exception level 3

cought exception level 2 STATETEST

System.Threading.ThreadAbortException: Thread was being aborted

  at Tests.ThreadStart1 () [0x00087] in
/Users/kumpera/src/mono/mono/tests/thread6.cs:51

cought exception level 1

System.Threading.ThreadAbortException: Thread was being aborted

  at Tests.ThreadStart1 () [0x00087] in
/Users/kumpera/src/mono/mono/tests/thread6.cs:51

end

Regression tests: 6 ran, 0 failed in Tests


On Tue, Aug 19, 2014 at 4:47 PM, Neale Ferguson nealefergu...@verizon.net
wrote:

 What should the output of thread6 test look like (apart from caught
 instead of cought)? Here's what I'm getting at the moment -

 Thread 1 started
 Count: 0
 cought exception level 3
 cought exception level 2 STATETEST
 System.Threading.ThreadAbortException: Thread was being aborted
   at Tests.ThreadStart1 () [0x00087] in
 /home/neale/mono/mono/tests/thread6.cs:51
 cought exception level 1
 System.Threading.ThreadAbortException: Thread was being aborted
   at Tests.ThreadStart1 () [0x00087] in
 /home/neale/mono/mono/tests/thread6.cs:51
 end
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Linux ARM: finally_block_ending_in_dead_bb.cs failure

2014-06-20 Thread Rodrigo Kumpera

This finally test is not supposed to work on ARM as the require block guard
work was not done there.

--
Rodrigo


On Fri, Jun 20, 2014 at 3:05 PM, Damien Diederen d...@crosstwine.com wrote:


 Hello,

 The finally_block_ending_in_dead_bb.cs runtime test fails on one of my
 current Linux/ARM builds:

 $ cd mono/tests
 $ mono finally_block_ending_in_dead_bb.exe; echo $?
 Could not abort thread final state 4
 4

 Before I spend too much time investigating, can you tell me whether the
 test is supposed to pass on (non-Android) ARM Linux?  A bit of googling
 seems to hint that it isn't:

   *
 http://stackoverflow.com/questions/23941478/mono-3-4-1-isnt-compiling-correctly-on-the-raspberry-pi

   * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735901

 More generally, is there a list of tests which are know to be broken on
 various platforms and/or architectures (besides Xamarin's Bugzilla, but
 search did not return any results for that test)?

 Thanks,
 Damien

 --
 http://crosstwine.com
 tel:  +49 89 2189 2939
 cell: +49 174 3489 428

 “Strong Opinions, Weakly Held”
  — Bob Johansen
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Linux x86: marshal7.cs failure

2014-06-19 Thread Rodrigo Kumpera

Linux and OSX have different alignment rules, that's why the difference.

This was fixed a few months back on master. If it's failing please file a
bug report.

--
Rodrigo


On Thu, Jun 19, 2014 at 2:19 PM, Damien Diederen d...@crosstwine.com wrote:


 Hello,

 I am observing the following failure on Linux 86:

 $ cd mono/tests
 $ mono marshal7.exe; echo $?
 14

 which corresponds to the following check:

 if (Marshal.SizeOf (typeof (TestStruct8)) != 16)
 return 14;

 My current build of Mono returns 12.  Which seems reasonable according
 to GCC (on the same machine, and on any 32-bit Linux I could test it
 on):

 $ cat  foo.c
 #include stdio.h
 #include stddef.h
 #include stdint.h

 struct TestStruct8 {
 int a;
 uint64_t b;
 };

 int main(int argc, char **argv) {
 size_t size = sizeof(struct TestStruct8);
 size_t offset_a = offsetof(struct TestStruct8, a);
 size_t offset_b = offsetof(struct TestStruct8, b);

 printf(Size: %zu, Offset A: %zu, Offset B: %zu\n,
size, offset_a, offset_b);
 return 0;
 }
 ^D
 $ gcc -m32 -g -Wall -o foo foo.c
 $ ./foo
 Size: 12, Offset A: 0, Offset B: 4

 Could the test be wrong, and should 32-bit Linux be folded with OS X:

 if (IsOSX ()  IntPtr.Size == 4) {
 if (Marshal.SizeOf (typeof (TestStruct8)) != 12)
 return 14;
 ...

 The test was last modified with the fix to Bug #4510, which is
 relatively recent; could it be that it has not been verified on a 32-bit
 Linux machine yet?

 Thanks,
 Damien

 --
 http://crosstwine.com
 tel:  +49 89 2189 2939
 cell: +49 174 3489 428

 “Strong Opinions, Weakly Held”
  — Bob Johansen
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Large object size limits

2014-06-13 Thread Rodrigo Kumpera

Hi Neale,

We should change from SIZE_MAX to the max value a ssize_t can hold.

--
Rodrigo


On Thu, Jun 12, 2014 at 4:38 PM, Neale Ferguson nealefergu...@verizon.net
wrote:

 The following program runs fine on .NET -

 using System;
 using System.Collections.Generic;
 using System.Runtime;
 using System.Text;

 namespace LargeObjectTest
 {
 class Program
 {
 static void Main(string[] args)
 {

 IListdouble myList = new Listdouble();


 long index = 1024*1024*1024;

 Console.WriteLine(index: + index);

 double[] array = null;

 Console.WriteLine(UInt32.MaxValue:
 +UInt32.MaxValue);
 try
 {
 array = new double[index];

 Console.WriteLine(doubleArray:LongLength
  + array.Length * sizeof(double) +  bytes);
 Console.WriteLine(sizeof(double)  +
 sizeof(double) +  bytes);
 Console.WriteLine(index  + index);
 Console.WriteLine(doubleArray:LongLength
  + array.LongLength);
 Console.WriteLine(doubleArray:Size  +
 array.LongLength * sizeof(double) * 1.0 +  Bytes);
 }
 catch (Exception e)
 {
 Console.WriteLine(Exception: + e);
 Console.WriteLine(Exception: + e.Message
 +  allocating : + index);
 Console.WriteLine(Exception: + e.Message
 +  allocating : + index * sizeof(double));
 }
 }
 }
 }

 However, on mono on Linux it results in:

 index:1073741824
 UInt32.MaxValue: 4294967295
 Exception:System.OutOfMemoryException: Out of memory
   at (wrapper managed-to-native)
 object:__icall_wrapper_mono_array_new_specific (intptr,int)
   at LargeObjectTest.Program.Main (System.String[] args) [0x0] in
 filename unknown:0
 Exception:Out of memory allocating :1073741824
 Exception:Out of memory allocating :8589934592

 If I make the following change to override the SIZE_MAX value from
 /usr/include/stdint.h:

 --- a/mono/metadata/sgen-los.c
 +++ b/mono/metadata/sgen-los.c
 @@ -342,8 +342,12 @@ sgen_los_alloc_large_inner (MonoVTable *vtable,
 size_t size)
  *
  * size = SIZE_MAX - (mono_pagesize () - 1) - sizeof (LOSObject)
  */
 +#undef SIZE_MAX
 +#define SIZE_MAX (17179869184U)
 if (size  SIZE_MAX - (mono_pagesize () - 1) - sizeof (LOSObject))
 return NULL;
 +#undef SIZE_MAX
 +#define SIZE_MAX (4294967295U)

  #ifdef LOS_DUMMY
 if (!los_segment)

 Then the program works as it does under .NET:

 index:1073741824
 UInt32.MaxValue: 4294967295
 doubleArray:LongLength 0 bytes
 sizeof(double) 8 bytes
 index 1073741824
 doubleArray:LongLength 1073741824
 doubleArray:Size 8589934592 Bytes

 The question is, what is the correct value for the comparison in lieu of
 SIZE_MAX? I can't determine what the max is on .NET. Another question is
 what type of compacting happens with large objects like this?

 Neale

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

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

Re: [Mono-dev] Next Release?

2014-06-12 Thread Rodrigo Kumpera

Hi Christian,

We're working on a 64bits installer, but I can't currently share any
timetable for it.

--
Rodrigo



On Wed, Jun 11, 2014 at 4:40 PM, Hüning, Christian 
christian.huen...@haw-hamburg.de wrote:

 Sounds great!
 Another question, 'cause I am curious: would it be too much hassle to
 release a 64 bit version alongside the 32 bit one as well?  I am working on
 a project using edge.js and Mono on OSX and I need to compile a 64 bit
 version of Mono on my own on each machine I want to use that combination.
 (It’s because Node.js is by default delivered as 64bit version on OSX, and
 so Mono needs to match).

 Von: Rodrigo Kumpera kump...@gmail.com
 Datum: Mittwoch, 11. Juni 2014 21:49
 An: Christian Hüning christian.huen...@haw-hamburg.de
 Cc: mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com
 Betreff: Re: [Mono-dev] Next Release?

 We expect it to happen in the next few weeks.


 On Wed, Jun 11, 2014 at 1:07 PM, Hüning, Christian 
 christian.huen...@haw-hamburg.de wrote:

 Is there any schedule for when the next version of Mono will officially
 be released?



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



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

Re: [Mono-dev] Next Release?

2014-06-11 Thread Rodrigo Kumpera

We expect it to happen in the next few weeks.


On Wed, Jun 11, 2014 at 1:07 PM, Hüning, Christian 
christian.huen...@haw-hamburg.de wrote:

 Is there any schedule for when the next version of Mono will officially be
 released?



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


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

Re: [Mono-dev] Ongoing Mono development / Mono roadmap

2014-04-09 Thread Rodrigo Kumpera

Facts tells a lot more gossip.

Mono has been steadily growing since Xamarin started. The size of the core
team working on mono have expanded and the number of external contributors
is growing even faster.





On Wed, Apr 9, 2014 at 3:36 PM, Alex J Lennon ajlen...@dynamicdevices.co.uk
 wrote:

 Hi,

 I became involved in a conversation today on LinkedIn in which a
 commentator was telling me Mono is dead, due to contractual
 constraints imposed on Xamarin by the legal owners of Mono, Attachmate.

 A snippet of the ensuing conversation follows,

 In July 2011, however, Novell - now a subsidiary of Attachmate - and
 Xamarin announced that Novell had granted a perpetual license for Mono,
 MonoTouch and Mono for Android to Xamarin, which formally and legally
 took official stewardship of the project.

 It also says as follows:  ...the future of the project was questioned,
 since MonoTouch and Mono for Android would now be in direct competition
 with the existing commercial offerings owned by Attachmate. It was not
 known at the time how Xamarin would prove they had not illegally used
 technologies previously developed when they were employed by Novell for
 the same work.

 In the Mono project website (www.mono-project.com), you have three main
 offerings, Mono, Xamarin.iOS and Xamarin.Android, and you can find a
 link (at the bottom left corner of the page) to Xamarin's website.

 It is clear that this is a strategy by Xamarin to offer MonoTouch
 developers a migration path to Xamarin tools, and not much more than that.

 To be able to woo Mono developers to Xamarin, Novell (Attachmate) and
 Xamarin cut this deal, because it is of mutual convenience to the two of
 them.

 But from any real perspective of active development of the platform,
 Mono is dead.

 ...

 This doesn't square at all for me with the near-monthly releases I've
 been seeing with functional enhancements I've been needing, such as ARM
 hardfp (great work, thanks).

 Would anybody care to comment on whether there's a kernel of truth here
 or what the roadmap for Mono development currently is?

 Thanks,

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

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

Re: [Mono-dev] (no subject)

2014-03-22 Thread Rodrigo Kumpera

We got a similar issue on our ARM devices.

Alex, has this been fixed?


On Thu, Mar 20, 2014 at 1:36 PM, Greg Young gregoryyou...@gmail.com wrote:

 Just ran with redirected output this is the issue.

 AOT [build] mcs.exe.so
 Mono Ahead of Time compiler - compiling assembly
 /home/greg/mono/mcs/class/lib/build/mcs.exe
 * Assertion at method-to-ir.c:13337, condition `load_opcode !=
 OP_LOADV_MEMBASE' not met

 Stacktrace:


 Native stacktrace:

 /home/greg/mono/mono/mini/mono() [0x4b8668]
 /lib/x86_64-linux-gnu/libpthread.so.0(+0xfbb0) [0x2ab35a4eabb0]
 /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x2ab35a72ef77]
 /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x2ab35a7325e8]
 /home/greg/mono/mono/mini/mono() [0x639385]
 /home/greg/mono/mono/mini/mono() [0x6394c6]
 /home/greg/mono/mono/mini/mono() [0x47974a]
 /home/greg/mono/mono/mini/mono() [0x422d8a]
 /home/greg/mono/mono/mini/mono() [0x49dd42]
 /home/greg/mono/mono/mini/mono() [0x49fb6a]

 Debug info from gdb:

 [New LWP 6528]
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1.
 0x2ab35a4ea757 in __libc_waitpid (pid=pid@entry=6529,
 stat_loc=stat_loc@entry=0x7fffc0f9740c, options=options@entry=0) at
 ../sysdeps/unix/sysv/linux/waitpid.c:40
 40  ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
   Id   Target Id Frame
   2Thread 0x2ab35d6b6700 (LWP 6528) mono sem_wait () at
 ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
 * 1Thread 0x2ab359be6500 (LWP 6519) mono 0x2ab35a4ea757 in
 __libc_waitpid (pid=pid@entry=6529, stat_loc=stat_loc@entry=0x7fffc0f9740c,
 options=options@entry=0) at ../sysdeps/unix/sysv/linux/waitpid.c:40

 Thread 2 (Thread 0x2ab35d6b6700 (LWP 6528)):
 #0  sem_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/sem_wait.S:85
 #1  0x0062fd57 in mono_sem_wait (sem=sem@entry=0x9834c0
 finalizer_sem, alertable=alertable@entry=1) at mono-semaphore.c:119
 #2  0x005ad9ea in finalizer_thread (unused=unused@entry=0x0) at
 gc.c:1073
 #3  0x0058fe0b in start_wrapper_internal (data=0x1401fd0) at
 threads.c:647
 #4  start_wrapper (data=0x1401fd0) at threads.c:692
 #5  0x0063482e in inner_start_thread (arg=0x7fffc0f98cd0) at
 mono-threads-posix.c:94
 #6  0x2ab35a4e2f6e in start_thread (arg=0x2ab35d6b6700) at
 pthread_create.c:311
 #7  0x2ab35a7f29cd in clone () at
 ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

 Thread 1 (Thread 0x2ab359be6500 (LWP 6519)):
 #0  0x2ab35a4ea757 in __libc_waitpid (pid=pid@entry=6529,
 stat_loc=stat_loc@entry=0x7fffc0f9740c, options=options@entry=0) at
 ../sysdeps/unix/sysv/linux/waitpid.c:40
 #1  0x004b86f5 in mono_handle_native_sigsegv (signal=optimized
 out, ctx=optimized out) at mini-exceptions.c:2305
 #2  signal handler called
 #3  0x2ab35a72ef77 in __GI_raise (sig=sig@entry=6) at
 ../nptl/sysdeps/unix/sysv/linux/raise.c:56
 #4  0x2ab35a7325e8 in __GI_abort () at abort.c:90
 #5  0x00639385 in monoeg_g_logv (log_domain=log_domain@entry=0x0,
 log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x641ee8
 * Assertion at %s:%d, condition `%s' not met\n, 
 args=args@entry=0x7fffc0f98338)
 at goutput.c:175
 #6  0x006394c6 in monoeg_assertion_message 
 (format=format@entry=0x641ee8
 * Assertion at %s:%d, condition `%s' not met\n) at goutput.c:195
 #7  0x0047974a in mono_spill_global_vars (cfg=cfg@entry=0x5ff3e90,
 need_local_opts=need_local_opts@entry=0x7fffc0f9877c) at
 method-to-ir.c:13337
 #8  0x00422d8a in mini_method_compile (method=method@entry=0x5788730,
 opts=optimized out, domain=optimized out, flags=flags@entry=JIT_FLAG_AOT,
 parts=parts@entry=0) at mini.c:5610
 #9  0x0049dd42 in compile_method (acfg=acfg@entry=0x1409f10,
 method=0x5788730) at aot-compiler.c:6513
 #10 0x0049fb6a in compile_method (method=optimized out,
 acfg=0x1409f10) at aot-compiler.c:8426
 #11 compile_methods (acfg=optimized out) at aot-compiler.c:8428
 #12 mono_compile_assembly (ass=ass@entry=0x1404dd0, opts=opts@entry=37023,
 aot_options=aot_options@entry=0x7fffc0f9b31a
 bind-to-runtime-version,outfile=./../../class/lib/build//mcs.exe.so) at
 aot-compiler.c:8835
 #13 0x0048dadc in main_thread_handler (user_data=synthetic
 pointer) at driver.c:1045
 #14 mono_main (argc=6, argv=optimized out) at driver.c:2024
 #15 0x2ab35a719de5 in __libc_start_main (main=0x419800 main, argc=6,
 ubp_av=0x7fffc0f990b8, init=optimized out, fini=optimized out,
 rtld_fini=optimized out, stack_end=0x7fffc0f990a8) at libc-start.c:260
 #16 0x00419aac in _start ()

 =
 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.

Re: [Mono-dev] Mono MRE/MDK mac pkg installer

2014-03-19 Thread Rodrigo Kumpera

Appke's pkgbuild does it all.


On Tue, Mar 18, 2014 at 5:37 PM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

  I'm trying to figure out how to build a pkg installer for mac, which
 will prompt user to accept eula, and install some project built with
 monomac or xamarin.mac.  This is exactly how the mono MRE/MDK installer
 behaves.  Can anybody provide any pointers, hints, or instructions?

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


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

Re: [Mono-dev] Library path bug in Makefile?

2014-03-07 Thread Rodrigo Kumpera

On Fri, Mar 7, 2014 at 7:03 AM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

  From: Rodrigo Kumpera [mailto:kump...@gmail.com]
 
  The issue is that we don't want to set RPATH to a value in the dynamic
 linker
  path. This is known to cause all sorts of issues. Setting it
  to, for example, /opt/lib is fine but /usr/lib is not.

 Just to be clear, setting RPATH and RUNPATH simultaneously behaviorally
 means RPATH is not set - only RUNPATH.  Which means, if you want to
 override using LD_LIBRARY_PATH, you can.

 What's the problem if you set it to /usr/lib?  And what are some of the
 other issues you're talking about?

 I have built mono on a couple of systems this way now in the last couple
 of days (using --prefix=/usr/local/mono-3.2.8 and
 RUNPATH=/usr/local/mono-3.2.8/lib) ...  I haven't had any problems with it
 yet, but if there's going to be a problem in the future, I'd like to know
 what to expect before it happens...


Setting RPATH to /usr/lib causes a lot of problems. Specially when you're
migrating between versions. glibc suffered huge pains from this.

OTOH, setting RPATH to /usr/lib and installing to a custom prefix is
probably fine'ish.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Library path bug in Makefile?

2014-03-06 Thread Rodrigo Kumpera

On Wed, Mar 5, 2014 at 10:46 PM, Edward Ned Harvey (mono) 
edward.harvey.m...@clevertrove.com wrote:

  From: mono-devel-list-boun...@lists.ximian.com [mailto:mono-devel-list-
  boun...@lists.ximian.com] On Behalf Of Edward Ned Harvey (mono)
 
  So ...  http://blog.tremily.us/posts/rpath/

 Actually, the answer is right there - Thank you, Trevor and Emily
 (tremily).

 This works perfectly:
 export LDFLAGS=-Wl,-rpath=/usr/local/mono-3.2.8/lib,--enable-new-dtags ;
 ./configure --prefix=/usr/local/mono-3.2.8

 After building  installing with these options:
 * The mono binary simply works.  No need to specify the LD_LIBRARY_PATH
 * It is overridable.  If need to set the LD_LIBRARY_PATH for some reason,
 it overrides the paths inside the binary.
 * Both the RPATH and RUNPATH have been set inside the binary, which
 behaves as tremily described.  (Particularly, the binary simply works, and
 can be overridden with LD_LIBRARY_PATH if desired.)

 As far as I'm concerned, this means there is no bug with the configure
 script or Makefile.  It is only a documentation feature - if you specify
 the --prefix, --exec-prefix, or --libdir, then the documentation should
 suggest specifying LDFLAGS=-Wl,-rpath=EPREFIX/lib,--enable-new-dtags


The issue is that we don't want to set RPATH to a value in the dynamic
linker path. This is known to cause all sorts of issues. Setting it
to, for example, /opt/lib is fine but /usr/lib is not. This is why it can't
be automatically done by the build as it can't know what to expect on the
host
search path.

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

Re: [Mono-dev] Changing the behavior of Process.Create

2014-03-05 Thread Rodrigo Kumpera

Yes, this should probably not change on windows due to .net.




On Tue, Mar 4, 2014 at 3:12 PM, Charlie Poole char...@nunit.com wrote:

 Can I assume this only applies to Linux? In the past, when I used
 Process.Create
 from a Mono app on Windows, the secondary process ran under MS .NET.

 Consequently, in order to work on both platforms, NUnit actually runs mono
 again when it is already running under mono and launches its agent process.

 Charlie

 On Tue, Mar 4, 2014 at 9:21 AM, Rodrigo Kumpera kump...@gmail.com wrote:
  Hey Guys,
 
  I've been looking on how to fix those two bugs:
  https://bugzilla.xamarin.com/show_bug.cgi?id=17831
  https://bugzilla.xamarin.com/show_bug.cgi?id=17820
 
  And one option we're contemplating is to switch the behavior of
  Process.Create
  when launching managed assemblies to first try to use the currently
 running
  runtime
  before delegating to one in PATH.
 
  Currently if you run a program that uses Process.Create with a runtime
 not
  located in path,
  the launched process will use mono from the PATH, which to some sounds
  surprising.
 
  Does anyone know of any app that will break with such change of behavior?
 
  This probably only affects embedders and mono hackers.
 
  --
  Rodrigo
 
  ___
  Mono-devel-list mailing list
  Mono-devel-list@lists.ximian.com
  http://lists.ximian.com/mailman/listinfo/mono-devel-list
 
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

[Mono-dev] Changing the behavior of Process.Create

2014-03-04 Thread Rodrigo Kumpera

Hey Guys,

I've been looking on how to fix those two bugs:
https://bugzilla.xamarin.com/show_bug.cgi?id=17831
https://bugzilla.xamarin.com/show_bug.cgi?id=17820

And one option we're contemplating is to switch the behavior of
Process.Create
when launching managed assemblies to first try to use the currently running
runtime
before delegating to one in PATH.

Currently if you run a program that uses Process.Create with a runtime not
located in path,
the launched process will use mono from the PATH, which to some sounds
surprising.

Does anyone know of any app that will break with such change of behavior?

This probably only affects embedders and mono hackers.

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

Re: [Mono-dev] ms .net source updated and license modified

2014-02-26 Thread Rodrigo Kumpera

Our current take at Xamarin is that we should avoid reading .NET source
code when implementing similar functionality on mono.
Some people have great visual memory, which would still mean us walking a
fine line on their rights. This is specially true for new
code.

What this change is that is enables us is to verify their behavior when
trying to understand compatibility issues, this
is particularly good for binary formats as they are the hardest to reverse
engineer for compatibility.

It's meant to be a next step when exploratory testing/RE can't reveal the
expected behavior.

--
Rodrigo

On Tue, Feb 25, 2014 at 4:59 PM, Martin Thwaites
monofo...@my2cents.co.ukwrote:

I'll caveat this with I'm not a legal expert...

Doing a bit of research, according to Wikipedia, it's the most restrictive
of the Microsoft Shared Source licences.

It seems that it can be used for Reference use. I'd read this to mean
that you cannot reproduce the identical code in mono, but, you could use to
work out how it's doing what it does.

Is this maybe something that has fallen out of the partnership between
Xamarin and Microsoft? something that would allow the Xamarin to better
develop their Android/iOS platform?

I'd love to hear from Xamarin as I'm sure that their legal department
either has an opinion, or helped instigate the change.

Anyway, just my 2 cents.
Martin

On 25 February 2014 18:17, Stephen Shaw ss...@decriptor.com wrote:

I'm curious. What does this actually mean for the mono project?

Cheers,
Stephen

On Tue, Feb 25, 2014 at 11:16 AM, Chris Ball qha...@gmail.com wrote:

Related, I believe:

http://www.hanselman.com/blog/AnnouncingTheNewRoslynpoweredNETFrameworkReferenceSource.aspx

Sent from my iPhone

On 25.02.2014, at 18:50, \Andrés G. Aragoneses\ kno...@gmail.com
wrote:

On 25/02/14 18:11, theUser BL wrote:
»Um die Arbeit mit dem Quellcode noch einfacher zu machen, hat
Microsoft
auch die Lizenzbestimmungen klarer gefasst. Denn bisher mussten
beispielsweise die Entwickler von Open Source-Klonen aufpassen, dass
sie
nur Erkenntnisse aus dem Reverse Engineering verwenden und nicht aus
dem Studium des originalen Quellcodes. Denn in vielen Fällen würde
dann
die Gefahr drohen, dass man sich verschiedener Rechteverletzungen
schuldig macht. Die Microsoft Reference Source License wurde daher nun
so angepasst, dass beispielsweise die Entwickler des Mono-Teams
problemlos die .Net-Sourcen anschauen und das Framework dann unter
Linux
klonen können. «

GoogleTranslate output is:

To make the work with the source code even easier, Microsoft has
also the license terms clarified. Because so far had
For example, the developers of open source clones careful that they
only use insights from the reverse engineering and not from
the study of the original source code. Because in many cases would then
the danger threatening that one different in rights violations
guilty. The Microsoft Reference Source License was therefore now
adapted so that for example, the developer of the mono-teams
easily see the. Net sources and the framework then in Linux
can clone.

If this translation is (kind of) correct, it still is very confusing
because that license (MS-RSL [1]) is not opensource.

[1]

http://en.wikipedia.org/wiki/Shared_source#Microsoft_Reference_Source_License_.28Ms-RSL.29

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

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

Re: [Mono-dev] Point of GC memory allocation in Mono

2014-02-03 Thread Rodrigo Kumpera

SGen generates fast variants of those functions that don't transition to
native code to alloc memory,
you can disable them in sgen-conf.hq


On Mon, Feb 3, 2014 at 1:11 PM, serus fabian.na...@gmail.com wrote:

 Dear Devs,

 I plan to experiment with the garbage collector and, to get me started, I
 wrote a small C# program that allocates a couple of objects and then I
 tried
 to use GDB to find the function calls that allocates memory for these
 objects.

 The function candidates that I identified are: /mono_gc_alloc_obj/ and
 /mono_gc_try_alloc_obj_nolock/ (both in /sgen-alloc.c/).

 When GDB reaches either breakpoint, I tried to identify whether it is the
 correct call by using the function's /size/ parameter and the fields
 /vtable-klass-name/ / /vtable-klass-name_space/.

 However, my approach seems to no work as I cannot find a single qualifying
 call. Could someone please hint me at where my thoughts are wrong and how
 to
 succeed with what I am trying to do.

 Thanks,
 Fabi



 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Point-of-GC-memory-allocation-in-Mono-tp4661839.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] WeakReference problem

2014-01-30 Thread Rodrigo Kumpera

You're right, mono only returns false if the WR has been finalized. Thanks
for taking the
time to find a way to reproduce the issue. I just fixed it on master.


On Thu, Jan 30, 2014 at 12:56 PM, Tobias Käs tobias.k...@gmx.de wrote:

  While trying to write a minimal test case I realized that mono actually
 never (?) returns false from WeakReference.TryGetTarget when the object has
 been collected, so this is pretty easy to reproduce and totally
 deterministic.


 using System;
 using System.Threading;

 static class Program {
 static WeakReferenceobject wr;

 static void Main(string[] args) {
 Allocate();
 GC.Collect();
 GC.WaitForPendingFinalizers();
 GC.Collect();
 Check();
 }

 static void Allocate() {
 wr = new WeakReferenceobject(new object());
 }

 static void Check() {
 object obj;
 if(wr.TryGetTarget(out obj)  obj == null) {
 throw new ApplicationException(assertion failed:
 object has been collected but TryGetTarget returned true);
 }
 }
 }


 Am 29.01.2014 23:41, schrieb Rodrigo Kumpera:

 Please provide a test case that shows this behavior


 On Wed, Jan 29, 2014 at 5:00 PM, Tobias Käs tobias.k...@gmx.de wrote:

 Hi, the generic WeakReferenceT for .NET 4.5 sometimes returns true from
 TryGetTarget even though the target has been collected (the out-value is
 correctly set to null). All my WeakReferences have been initialized with
 non-null values.

 Looking at the source at github I can imagine that there is a race
 between the handle.IsAllocated check and the handle.Target retrieval, but
 I'm no expert. Should I file a bug on that one? I'm not sure what the
 expected behavior is since MSDN documentation of that method isn't so
 great, but if the caller has to check the out-value against null anyways,
 then the return value becomes kinda pointless in my opinion.

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




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

Re: [Mono-dev] WeakReference problem

2014-01-29 Thread Rodrigo Kumpera

Please provide a test case that shows this behavior


On Wed, Jan 29, 2014 at 5:00 PM, Tobias Käs tobias.k...@gmx.de wrote:

 Hi, the generic WeakReferenceT for .NET 4.5 sometimes returns true from
 TryGetTarget even though the target has been collected (the out-value is
 correctly set to null). All my WeakReferences have been initialized with
 non-null values.

 Looking at the source at github I can imagine that there is a race between
 the handle.IsAllocated check and the handle.Target retrieval, but I'm no
 expert. Should I file a bug on that one? I'm not sure what the expected
 behavior is since MSDN documentation of that method isn't so great, but if
 the caller has to check the out-value against null anyways, then the return
 value becomes kinda pointless in my opinion.

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

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

Re: [Mono-dev] llvm issue

2014-01-21 Thread Rodrigo Kumpera

LLVM was never tests on FreeBSD, you'll have to debug it.


On Tue, Jan 21, 2014 at 8:35 AM, Bruno Lauzé brunola...@msn.com wrote:

 When I try to compile mono from git with llvm ; llvm installed from
 github.com/mono/llvm
 I'm on FreeBSD HEAD.
 Everything compiles smoothly but  now the mono-sgen process get stuck in
 umtxn state (kernel lock) on the first usage. (basic-profile-check.exe)
 Whenever i remove --enable-llvm everything is fine again. This was working
 before around october. Any ideas what could have change to cause this?
 Any suggestions where to look?

 Thanks.

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


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

Re: [Mono-dev] Status of http://wrench.mono-project.com

2014-01-15 Thread Rodrigo Kumpera

We have no timetable on when to get those bots back to life.


On Wed, Jan 15, 2014 at 1:00 PM, Grüninger, Andreas (LGL Extern) 
andreas.gruenin...@lgl.bwl.de wrote:

 There are no builds of mono-master since 2013/12/09 for linux (debian,
 opensuse, x86/x64).

 The disk of the build system seems to be full.



 Is there a chance to get the current status of failing tests?

 I would really like to compare the status of my changes for
 solaris/openindiana.



 Thanks



 Andreas



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


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

Re: [Mono-dev] Assert: condition `ret == 0' not met

2014-01-13 Thread Rodrigo Kumpera

Are you trying to build mono/master without any changes? That has not
happen with our bots at xamarin.


On Mon, Jan 13, 2014 at 4:47 PM, Bassam Tabbara bas...@symform.com wrote:

 Hello,

 I’m seeing the following exception while building MCS from the latest in
 master. This is on my mac (OSX 10.9). Any thoughts?

 System.Collections.Concurrent/BlockingCollection.cs(396,9): warning
 CS0219: The variable `index' is assigned but its value is never used
 System.Diagnostics/TraceImpl.cs(44,15): warning CS0649: Field
 `System.Diagnostics.TraceImplSettings.AutoFlush' is never assigned to, and
 will always have its default value `false'
 Compilation succeeded - 5 warning(s)
 * Assertion at gc.c:1216, condition `ret == 0' not met

 Stacktrace:

   at unknown 0x
   at (wrapper managed-to-native) System.Environment.Exit (int) 0x
   at Mono.CSharp.Driver.Main (string[]) 0x002b3
   at (wrapper runtime-invoke) Module.runtime_invoke_int_object
 (object,intptr,intptr,intptr) 0x

 Native stacktrace:

 0   mono0x000109261dfb
 mono_handle_native_sigsegv + 363
 1   libsystem_platform.dylib0x7fff88bf05aa
 _sigtramp + 26
 2   libsystem_c.dylib   0x7fff81b9ed8b
 __sprintf_chk + 153
 3   libsystem_c.dylib   0x7fff81b7abba abort +
 125
 4   mono0x0001093eee11
 monoeg_g_logv + 161
 5   mono0x0001093eef4f
 monoeg_assertion_message + 143
 6   mono0x000109365524
 mono_gc_cleanup + 260
 7   mono0x00010935bc1e
 mono_runtime_cleanup + 14
 8   mono0x0001091d900c
 mini_cleanup + 956
 9   mono0x0001092e6525
 ves_icall_System_Environment_Exit + 37
 10  ??? 0x0001119d2324 0x0 +
 4590478116
 11  mono0x0001091d88f5
 mono_jit_runtime_invoke + 1653
 12  mono0x00010936871b
 mono_runtime_invoke + 107
 13  mono0x00010936e726
 mono_runtime_exec_main + 374
 14  mono0x0001092358d9
 mono_main + 6121
 15  mono0x0001091cc6ec main +
 588
 16  libdyld.dylib   0x7fff8d2195fd start +
 1
 17  ??? 0x001b 0x0 + 27

 Debug info from gdb:

 Process 93570 stopped
 * thread #1: tid = 0x250792, 0x7fff8da88e22
 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop
 reason = signal SIGSTOP
   thread #2: tid = 0x2507a0, 0x7fff8da88e6a
 libsystem_kernel.dylib`__workq_kernreturn + 10
   thread #3: tid = 0x2507a1, 0x7fff8da89662
 libsystem_kernel.dylib`kevent64 + 10, queue = 'com.apple.libdispatch-manager
   thread #4: tid = 0x2507a2, 0x7fff8da88e6a
 libsystem_kernel.dylib`__workq_kernreturn + 10
 (lldb) * thread #1: tid = 0x250792, 0x7fff8da88e22
 libsystem_kernel.dylib`__wait4 + 10, queue = 'com.apple.main-thread, stop
 reason = signal SIGSTOP
 frame #0: 0x7fff8da88e22 libsystem_kernel.dylib`__wait4 + 10
 frame #1: 0x000109261ed4
 mono`mono_handle_native_sigsegv(signal=unavailable, ctx=unavailable) +
 580 at mini-exceptions.c:2299
 frame #2: 0x7fff88bf05aa libsystem_platform.dylib`_sigtramp + 26
 frame #3: 0x7fff8da88867 libsystem_kernel.dylib`__pthread_kill + 11
 frame #4: 0x7fff81b9ed8b libsystem_c.dylib`__sprintf_chk + 153
 frame #5: 0x7fff81b7abba libsystem_c.dylib`abort + 125
 frame #6: 0x0001093eee11
 mono`monoeg_g_logv(log_domain=unavailable, log_level=unavailable,
 format=unavailable, args=unavailable) + 161 at goutput.c:175
 frame #7: 0x0001093eef4f
 mono`monoeg_assertion_message(format=unavailable) + 143 at goutput.c:195
 frame #8: 0x000109365524 mono`mono_gc_cleanup + 260 at gc.c:1216
 frame #9: 0x00010935bc1e
 mono`mono_runtime_cleanup(domain=unavailable) + 14 at appdomain.c:354
 frame #10: 0x0001091d900c
 mono`mini_cleanup(domain=0x7fb070501350) + 956 at mini.c:7626
 frame #11: 0x0001092e6525
 mono`ves_icall_System_Environment_Exit(result=0) + 37 at icall.c:6517
 frame #12: 0x0001119d2324
 frame #13: 0x0001091d88f5
 mono`mono_jit_runtime_invoke(method=unavailable, obj=0x,
 params=unavailable, exc=unavailable) + 1653 at mini.c:6654
 frame #14: 0x00010936871b
 mono`mono_runtime_invoke(method=0x7fb0705025b0, obj=0x,
 params=0x7fff56a33d68, exc=0x) + 107 at object.c:2828
 frame #15: 0x00010936e726
 mono`mono_runtime_exec_main(method=0x7fb0705025b0, args=unavailable,

Re: [Mono-dev] System.ExecutionEngineException: Failed to create shadow copy (CopyFile).

2013-12-27 Thread Rodrigo Kumpera

It depends on what information you're trying to inspect. It should have the
same laziness in resolving type information as .NET.

Where in the inspected type does the missing assembly come into play?

It should be simple to build a test case for that, just delete one assembly
after compilation is done.


On Fri, Dec 27, 2013 at 11:18 AM, Alistair Bush alistair.b...@gmail.comwrote:

 Just wanted to follow up with this here first before I create a bug report.

 I believe I have tracked down the issue here.

 Fubu, the creating app, is setting up an app domain whose private bin
 directory is at another path.   To ensure it can resolve its types is it
 copying a set of Assemblies by
 name x.RequireAssembly(Owin.Extensions); or by containing
 type x.RequireAssemblyContainingTypeIActivator();.

 It is then calling a remote proxy of a class which Fubu itself contains
 (using messaging) which attempts to

 var assemblies = list.SelectMany(x = AssembliesFromPath(x));
 var pool = new TypePool();
 pool.IgnoreExportTypeFailures = true;

 pool.AddAssemblies(assemblies);
 return pool.TypesMatching(x = x.IsConcreteTypeOfIApplicationSource() 
 x.IsConcreteWithDefaultCtor());

 It is at this point that it blows up on inspecting the type.

 I was able to work around this by copying a dependency of Fubu into the
 target bin directory.  The dependency was Selenium's WebDriver dll, which
 as far as I can see is not utilised directly from the code actually
 executing.

 So does mono require all referenced dependencies of a library to be
 available before you can inspect Type information?


 On Tue, Dec 24, 2013 at 10:58 PM, Alistair Bush 
 alistair.b...@gmail.comwrote:

 Small.  Not currently, I will attempt to create one tho.   Also will
 raise a bug report on this as well sometime this week.   Probably not
 tomorrow :)
  On 24/12/2013 7:32 PM, Rodrigo Kumpera kump...@gmail.com wrote:

 Do you have a small test case that shows this behavior? Could you file a
 bug report on this?


 On Mon, Dec 23, 2013 at 6:57 AM, Alistair Bush 
 alistair.b...@gmail.comwrote:

 I have be working to get the fubu (mvc) framework and associated tools
 working on mono/linux.
 I have gotten most of the way to running a basic app but have sadly
 come stuck on the following and am running out of ideas.

 Basically I have setup a 'web' project using fubu new and am attempting
 to run it by calling fubu run.

 Sadly i'm getting the output [1] and as you will be able to see this is
 caused by a ExecutionEngineException when attempting to call
 Type.IsAssignableFrom.

 At this particular point in the code it is my understanding that the
 application is within a separate app domain ( see
 Bottles.Services.Remote.RemoteServicesProxy ).

 This is anything which should be stopping mono from inspecting Type
 information on a Type when within a separate app domain?

 Also it the moment im a little stuck on how to get more information to
 debug this issue.  Any suggestions would be welcomed.   Thanks.



 [1]
 $ fubu run --directory src/fubutest
 Alias is returning '/home/alistair/Projects/fubu/tests/fubutest'
 Alias is returning 'src/fubutest'
 Assembly bin path is bin
 The configuration file is
 /home/alistair/Projects/fubu/tests/fubutest/src/fubutest/Web.config
 Started service Fubu.Running.RemoteFubuMvcBootstrapper
 Trying to start application
 /home/alistair/Projects/fubu/tests/fubutest/src/fubutest with port number
 5500
 FubuMode = Development
 ERROR: System.ExecutionEngineException: Failed to create shadow copy
 (CopyFile).

 Server stack trace:
   at (wrapper managed-to-native) System.Type:type_is_assignable_from
 (System.Type,System.Type)
   at System.Type.IsAssignableFrom (System.Type c) [0x0] in
 filename unknown:0
   at FubuCore.TypeExtensions.IsConcreteTypeOf[IApplicationSource]
 (System.Type pluggedType) [0x0] in filename unknown:0
   at Fubu.Running.ApplicationSourceFinder.Findm__1 (System.Type x)
 [0x0] in filename unknown:0
   at
 System.Linq.Enumerable+CreateWhereIteratorc__Iterator1E`1[System.Type].MoveNext
 () [0x0] in filename unknown:0
   at
 System.Linq.Enumerable+CreateDistinctIteratorc__Iterator3`1[System.Type].MoveNext
 () [0x0] in filename unknown:0
   at System.Linq.Enumerable.Any[Type] (IEnumerable`1 source) [0x0]
 in filename unknown:0
   at Fubu.Running.ApplicationSourceChooser.Find
 (Fubu.Running.StartApplication message, System.Action`1 onFound) [0x0]
 in filename unknown:0
   at Fubu.Running.RemoteFubuMvcBootstrapper.Receive
 (Fubu.Running.StartApplication message) [0x0] in filename unknown:0
   at
 Bottles.Services.Messaging.MessagingHub+c__DisplayClass3`1[Fubu.Running.StartApplication].Sendb__1
 (IListener`1 x) [0x0] in filename unknown:0
   at
 System.Collections.Generic.GenericEnumerableExtensions.Each[IListener`1]
 (IEnumerable`1 values, System.Action`1 eachAction) [0x0] in filename
 unknown:0
   at Bottles.Services.Messaging.MessagingHub.Send[StartApplication

Re: [Mono-dev] System.ExecutionEngineException: Failed to create shadow copy (CopyFile).

2013-12-23 Thread Rodrigo Kumpera

Do you have a small test case that shows this behavior? Could you file a
bug report on this?


On Mon, Dec 23, 2013 at 6:57 AM, Alistair Bush alistair.b...@gmail.comwrote:

 I have be working to get the fubu (mvc) framework and associated tools
 working on mono/linux.
 I have gotten most of the way to running a basic app but have sadly come
 stuck on the following and am running out of ideas.

 Basically I have setup a 'web' project using fubu new and am attempting to
 run it by calling fubu run.

 Sadly i'm getting the output [1] and as you will be able to see this is
 caused by a ExecutionEngineException when attempting to call
 Type.IsAssignableFrom.

 At this particular point in the code it is my understanding that the
 application is within a separate app domain ( see
 Bottles.Services.Remote.RemoteServicesProxy ).

 This is anything which should be stopping mono from inspecting Type
 information on a Type when within a separate app domain?

 Also it the moment im a little stuck on how to get more information to
 debug this issue.  Any suggestions would be welcomed.   Thanks.



 [1]
 $ fubu run --directory src/fubutest
 Alias is returning '/home/alistair/Projects/fubu/tests/fubutest'
 Alias is returning 'src/fubutest'
 Assembly bin path is bin
 The configuration file is
 /home/alistair/Projects/fubu/tests/fubutest/src/fubutest/Web.config
 Started service Fubu.Running.RemoteFubuMvcBootstrapper
 Trying to start application
 /home/alistair/Projects/fubu/tests/fubutest/src/fubutest with port number
 5500
 FubuMode = Development
 ERROR: System.ExecutionEngineException: Failed to create shadow copy
 (CopyFile).

 Server stack trace:
   at (wrapper managed-to-native) System.Type:type_is_assignable_from
 (System.Type,System.Type)
   at System.Type.IsAssignableFrom (System.Type c) [0x0] in filename
 unknown:0
   at FubuCore.TypeExtensions.IsConcreteTypeOf[IApplicationSource]
 (System.Type pluggedType) [0x0] in filename unknown:0
   at Fubu.Running.ApplicationSourceFinder.Findm__1 (System.Type x)
 [0x0] in filename unknown:0
   at
 System.Linq.Enumerable+CreateWhereIteratorc__Iterator1E`1[System.Type].MoveNext
 () [0x0] in filename unknown:0
   at
 System.Linq.Enumerable+CreateDistinctIteratorc__Iterator3`1[System.Type].MoveNext
 () [0x0] in filename unknown:0
   at System.Linq.Enumerable.Any[Type] (IEnumerable`1 source) [0x0] in
 filename unknown:0
   at Fubu.Running.ApplicationSourceChooser.Find
 (Fubu.Running.StartApplication message, System.Action`1 onFound) [0x0]
 in filename unknown:0
   at Fubu.Running.RemoteFubuMvcBootstrapper.Receive
 (Fubu.Running.StartApplication message) [0x0] in filename unknown:0
   at
 Bottles.Services.Messaging.MessagingHub+c__DisplayClass3`1[Fubu.Running.StartApplication].Sendb__1
 (IListener`1 x) [0x0] in filename unknown:0
   at
 System.Collections.Generic.GenericEnumerableExtensions.Each[IListener`1]
 (IEnumerable`1 values, System.Action`1 eachAction) [0x0] in filename
 unknown:0
   at Bottles.Services.Messaging.MessagingHub.Send[StartApplication]
 (Fubu.Running.StartApplication message) [0x0] in filename unknown:0
   at
 Bottles.Services.Messaging.MessagingHub+Sender`1[Fubu.Running.StartApplication].Send
 (System.Object o, Bottles.Services.Messaging.MessagingHub listeners)
 [0x0] in filename unknown:0
   at Bottles.Services.Messaging.MessagingHub.SendJson (System.String json)
 [0x0] in filename unknown:0
   at Bottles.Services.Remote.RemoteServicesProxy.SendJson (System.String
 json) [0x0] in filename unknown:0
   at (wrapper managed-to-native)
 System.Runtime.Remoting.RemotingServices:InternalExecute
 (System.Reflection.MethodBase,object,object[],object[])
   at System.Runtime.Remoting.RemotingServices.InternalExecuteMessage
 (System.MarshalByRefObject target, IMethodCallMessage reqMsg) [0x0] in
 filename unknown:0

 Exception rethrown at [0]:

   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke
 (System.Runtime.Remoting.Proxies.RealProxy rp, IMessage msg,
 System.Exception exc, System.Object[] out_args) [0x0] in filename
 unknown:0
 Shutting down finalizer thread timed out.
 Failed to destroy mutex 0x965988 error code 16 errno 2


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


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

Re: [Mono-dev] Mono.Cairo 4.0 different on Mac and Ubuntu

2013-12-16 Thread Rodrigo Kumpera

It does matter as the cairo bindings were updated during mono 3.0. The 4.0
version you see is for the framework, not the library itself.

Mono.Cairo version is bound to mono's.

Please update to 3.2.


On Mon, Dec 16, 2013 at 1:35 PM, Vassil Vassilev v.g.vassi...@gmail.comwrote:

 Hi,
   I use Mono.Cairo library (saying assembly version 4.0.0.0) on both MacOS
 and Ubuntu. On MacOS it says there is Cairo.Context.SetSource(Cairo.Pattern)
 I can see the IL code of the method, whereas on ubuntu there is no such
 method even if both Mono.Cairo-s say version 4.0. On MacOS my .NET Runtime
 is 3.2.5 and on Ubuntu 2.10.8.1. However that shouldn't matter right? Any
 thoughts what might be happening?
 Cheers,
 Vassil
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] AppDomain Support

2013-12-11 Thread Rodrigo Kumpera

Can you file a bug report with a full test case? This way we can have a way
to fix it?


On Wed, Dec 11, 2013 at 1:49 PM, Christian Smith smith@gmail.comwrote:

 Hi Andres,

 I jumped the gun on thinking it wasn't implemented, don't believe the
 first SO post you read...

 We are having an issue though with type comparison between two domains
 though.

 We have domain A  B, both reference the same assembly with a class
 'MyType'.  Domain A passes MyType to domain B via a generic function.  This
 function in Domain B has a check:

 public override T CreateInstanceT()
 {
 return (T)(CreateInstanceCore(typeof(T)));
 }

 protected object CreateInstanceCore(Type type)
 {
 if (type == typeof(MyType))
 {
 return new BlahBlah();
 }

 This works fine using .Net, but fails with Mono.

 Have you seen anything like this before?


 On 11 December 2013 23:42, Andrés G. Aragoneses kno...@gmail.comwrote:

 On 11/12/13 03:33, Christian Smith wrote:
  I was wondering what the current status of AppDomain support is and what
  the plans for this are?  I.e. is it not implemented?  70% implemented
 etc...

 AFAIK it's fully implemented. Do you see any problems with it?


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



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


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

Re: [Mono-dev] large performance drop between boehm and sgen for a parallel app

2013-12-08 Thread Rodrigo Kumpera

Sure.


On Sat, Dec 7, 2013 at 5:02 PM, Jonathan Shore jonathan.sh...@gmail.comwrote:

 Probably the best thing i can do here is try to scale this problem down so
 that does not depend on external data and post to bugzilla.  Then someone
 can take a look at the pathelogical sgen GC profile.


 On Dec 7, 2013, at 1:15 PM, Rodrigo Kumpera kump...@gmail.com wrote:

 A perf run with sampling profiling and actual traces would be of some use.

 If you have a very large heap, you're probably hitting the limitation of
 on the default serial major collector mono uses.
 You could try to run with the parallel major enabled, but that's
 experimental and has not received enough tunning/testing.


 On Sat, Dec 7, 2013 at 12:38 PM, Jonathan Shore 
 jonathan.sh...@gmail.comwrote:

 Here are the results for a trimmed down version of the problem:

 *Boehm (default settings)*
 Performance counter stats for '/opt/mono-3.0/bin/mono-boehm --llvm
 /home/jonathan/Dev/hf/lib/Debug/FeatureGeneratorCSVFile.exe -info -config
 etc/samples/orderbook-2013-CX-V11.xml -out features-2013-CX.csv':

48579862.522506 task-clock#*9.034* CPUs utilized

188,866,824 context-switches  #0.004 M/sec

 46,500 CPU-migrations#0.000 M/sec

  1,475,427 page-faults   #0.000 M/sec

 140,468,865,368,193 cycles#2.892 GHz

not supported stalled-cycles-frontend
not supported stalled-cycles-backend
 80,012,982,451,027 instructions  #0.57  insns per cycle

 16,967,686,291,478 branches  #  349.274 M/sec

 95,315,728,420 branch-misses #0.56% of all branches


 *5377*.495775794 seconds time elapsed

 *SGen (default settings)*
 Performance counter stats for '/opt/mono-3.0/bin/mono-sgen --llvm
 /home/jonathan/Dev/hf/lib/Debug/FeatureGeneratorCSVFile.exe -info -config
 etc/samples/orderbook-2013-CX-V11.xml -out features-2013-CX.csv':

   108414200.651113 task-clock#*2.049* CPUs utilized

 65,792,604 context-switches  #0.001 M/sec

 30,536 CPU-migrations#0.000 M/sec

309,928,477 page-faults   #0.003 M/sec

 263,506,866,481,917 cycles   #2.431 GHz

not supported stalled-cycles-frontend
not supported stalled-cycles-backend
 130,560,004,191,686 instructions #0.50  insns per cycle

 27,570,367,199,486 branches  #  254.306 M/sec

382,673,241,515 branch-misses #1.39% of all branches


*52912.*358974732 seconds time elapsed

 There is a nearly 10x difference in performance between these.  Both were
 run on 10 cores.   The boehm version achieved a 9 cpu average and the sgen
 achieved a 2 cpu average + more overhead.


 On Dec 5, 2013, at 12:48 PM, Rodrigo Kumpera kump...@gmail.com wrote:

 Are you running boehm in parallel mode? Can you run perf on your
 application and email us the translated results?


 On Thu, Dec 5, 2013 at 11:11 AM, Jonathan Shore jonathan.sh...@gmail.com
  wrote:

 Hi,

 I have a complex parallel application which, when run on 10 threads gets
 very close to 1000% cpu with mono-boehm (linux) consistently (running for
 hours).   With mono-sgen only achieves  200 - 250% cpu.   This is on a 12 /
 24 core machine.   I need to run sgen eventually because run into the 32
 bit limit with boehm from time to time.

 Note that this is with a fairly recent version of mono compiled from git
 sources with llvm enabled.

 It is not an application I can easily box up for analysis on bugzilla
 due to size of data context, though happy to provide an enviroment to the
 mono team if useful.  Wondering whether there is some GC debugging can turn
 on that is useful to the mono team?

 Thanks
 Jonathan

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






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

Re: [Mono-dev] large performance drop between boehm and sgen for a parallel app

2013-12-07 Thread Rodrigo Kumpera

A perf run with sampling profiling and actual traces would be of some use.

If you have a very large heap, you're probably hitting the limitation of on
the default serial major collector mono uses.
You could try to run with the parallel major enabled, but that's
experimental and has not received enough tunning/testing.


On Sat, Dec 7, 2013 at 12:38 PM, Jonathan Shore jonathan.sh...@gmail.comwrote:

 Here are the results for a trimmed down version of the problem:

 *Boehm (default settings)*
 Performance counter stats for '/opt/mono-3.0/bin/mono-boehm --llvm
 /home/jonathan/Dev/hf/lib/Debug/FeatureGeneratorCSVFile.exe -info -config
 etc/samples/orderbook-2013-CX-V11.xml -out features-2013-CX.csv':

48579862.522506 task-clock#*9.034* CPUs utilized

188,866,824 context-switches  #0.004 M/sec

 46,500 CPU-migrations#0.000 M/sec

  1,475,427 page-faults   #0.000 M/sec

 140,468,865,368,193 cycles#2.892 GHz

not supported stalled-cycles-frontend
not supported stalled-cycles-backend
 80,012,982,451,027 instructions  #0.57  insns per cycle

 16,967,686,291,478 branches  #  349.274 M/sec

 95,315,728,420 branch-misses #0.56% of all branches


 *5377*.495775794 seconds time elapsed

 *SGen (default settings)*
 Performance counter stats for '/opt/mono-3.0/bin/mono-sgen --llvm
 /home/jonathan/Dev/hf/lib/Debug/FeatureGeneratorCSVFile.exe -info -config
 etc/samples/orderbook-2013-CX-V11.xml -out features-2013-CX.csv':

   108414200.651113 task-clock#*2.049* CPUs utilized

 65,792,604 context-switches  #0.001 M/sec

 30,536 CPU-migrations#0.000 M/sec

309,928,477 page-faults   #0.003 M/sec

 263,506,866,481,917 cycles   #2.431 GHz

not supported stalled-cycles-frontend
not supported stalled-cycles-backend
 130,560,004,191,686 instructions #0.50  insns per cycle

 27,570,367,199,486 branches  #  254.306 M/sec

382,673,241,515 branch-misses #1.39% of all branches


*52912.*358974732 seconds time elapsed

 There is a nearly 10x difference in performance between these.  Both were
 run on 10 cores.   The boehm version achieved a 9 cpu average and the sgen
 achieved a 2 cpu average + more overhead.


 On Dec 5, 2013, at 12:48 PM, Rodrigo Kumpera kump...@gmail.com wrote:

 Are you running boehm in parallel mode? Can you run perf on your
 application and email us the translated results?


 On Thu, Dec 5, 2013 at 11:11 AM, Jonathan Shore 
 jonathan.sh...@gmail.comwrote:

 Hi,

 I have a complex parallel application which, when run on 10 threads gets
 very close to 1000% cpu with mono-boehm (linux) consistently (running for
 hours).   With mono-sgen only achieves  200 - 250% cpu.   This is on a 12 /
 24 core machine.   I need to run sgen eventually because run into the 32
 bit limit with boehm from time to time.

 Note that this is with a fairly recent version of mono compiled from git
 sources with llvm enabled.

 It is not an application I can easily box up for analysis on bugzilla due
 to size of data context, though happy to provide an enviroment to the mono
 team if useful.  Wondering whether there is some GC debugging can turn on
 that is useful to the mono team?

 Thanks
 Jonathan

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




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

Re: [Mono-dev] large performance drop between boehm and sgen for a parallel app

2013-12-05 Thread Rodrigo Kumpera

Are you running boehm in parallel mode? Can you run perf on your
application and email us the translated results?


On Thu, Dec 5, 2013 at 11:11 AM, Jonathan Shore jonathan.sh...@gmail.comwrote:

 Hi,

 I have a complex parallel application which, when run on 10 threads gets
 very close to 1000% cpu with mono-boehm (linux) consistently (running for
 hours).   With mono-sgen only achieves  200 - 250% cpu.   This is on a 12 /
 24 core machine.   I need to run sgen eventually because run into the 32
 bit limit with boehm from time to time.

 Note that this is with a fairly recent version of mono compiled from git
 sources with llvm enabled.

 It is not an application I can easily box up for analysis on bugzilla due
 to size of data context, though happy to provide an enviroment to the mono
 team if useful.  Wondering whether there is some GC debugging can turn on
 that is useful to the mono team?

 Thanks
 Jonathan

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

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

Re: [Mono-dev] Updated Mono class status pages?

2013-11-26 Thread Rodrigo Kumpera

They are dead, you can use the desktop tool replacement in the mono-tools
repository.


On Thu, Nov 21, 2013 at 1:22 PM, Alexander Köplinger 
alex.koeplin...@outlook.com wrote:

 Are the class status pages on http://go-mono.com/status actively
 maintained or is there another site?

 Most pages there state that the last update was ~2 years ago.



 Regards,

 Alex

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


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

Re: [Mono-dev] EntryPointNotFoundException: CreateZStream

2013-11-24 Thread Rodrigo Kumpera

It's a packaging bug in mono for windows.


On Sun, Nov 24, 2013 at 1:05 PM, Zoltan Varga var...@gmail.com wrote:

 Hi,

 So the problem is that recent mono packages are missing the 
 MonoPosixHelper.dll file for some reason, and the system has an old version 
 lying around in some other package, leading to this error.

  Zoltan



 On Sun, Nov 24, 2013 at 5:43 PM, Marcelo Zabani mzab...@gmail.com wrote:

 It seems like I'm not authorized to view that bug


 On Fri, Nov 22, 2013 at 6:38 PM, Zoltan Varga var...@gmail.com wrote:

 Hi,

   Probably:
 https://bugzilla.xamarin.com/show_bug.cgi?id=15507

Zoltan


 On Fri, Nov 22, 2013 at 8:19 PM, Marcelo Zabani mzab...@gmail.comwrote:

 I'm running into the following exception:

 *System.EntryPointNotFoundException: CreateZStream at (wrapper
 managed-to-native) System.IO.Compression.DeflateStreamNative:CreateZStream
 (System.IO.Compression.CompressionMode,bool,System.IO.Compression.DeflateStreamNative/UnmanagedReadOrWrite,intptr)
 at System.IO.Compression.DeflateStreamNative.Create (System.IO.Stream
 compressedStream, CompressionMode mode, Boolean gzip) [0x0] in
 filename unknown:0 at System.IO.Compression.DeflateStream..ctor
 (System.IO.Stream compressedStream, CompressionMode mode, Boolean
 leaveOpen, Boolean gzip) [0x0] in filename unknown:0 *

 with Mono 3.2.3 on Windows 8.

 I'm running a console project in cmd, just plain old mono app.exe.
 What could this be?

 Thanks,
 Marcelo.

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





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


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

Re: [Mono-dev] Hotcompling while debugging?

2013-11-20 Thread Rodrigo Kumpera

Mono doesn't support editcontinue and we have no plans to support it.

It's too hard and too fragile to be worth it.


On Wed, Nov 20, 2013 at 8:22 AM, Vardar Sahin sakirs...@gmail.com wrote:

 Hello all,

 in Visual Studio you can hot compile your code while debugging C#
 applications.
 By hot compiling I mean that you can alter your source code while
 debugging and the
 altered code will be compiled on the fly. After you resume your debug
 session,
 your code change will affect your application.

 Right now it seems that Xamarin Studio does not support it. I wonder why?
 I think mono should be able to do it, but I am not an expert.

 Are there any plans for this feature?

 Best
 Sahin


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


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

Re: [Mono-dev] Build Error -- Bootstrap compiler: Mono C# compiler version 3.0.12.0 main.c: In function ‘create_file_names’: main.c:306:12: warning: ignoring return value of ‘mkstemp’, declared with a

2013-10-29 Thread Rodrigo Kumpera

Use the commit before that.


On Tue, Oct 29, 2013 at 2:58 PM, Isaac Gouy igo...@yahoo.com wrote:

 Ubuntu 13.10 Linux x86 3.11.0-12-generic

 $ git clone git://github.com/mono/llvm.git
 $ cd llvm
 $ git checkout mono
 $ ./configure --prefix=/usr/local/src/monollvm --enable-optimized
 --enable-targets=x86
 $ make  make install

 $ cd ..
 $ git clone git://github.com/mono/mono
 $ cd mono
 $ export MONO_USE_LLVM=1
 $ PATH=/usr/local/src/monollvm/bin:$PATH
 $ ./autogen.sh --prefix=/usr/local  --enable-llvm=yes
 $ make

 ...

 cd /usr/local/src/mono/mcs  make --no-print-directory -s NO_DIR_CHECK=1
 PROFILES='net_2_0 net_3_5 net_4_0 net_4_5  ' CC='gcc' all-profiles
 mkdir -p -- build/deps
 Bootstrap compiler: Mono C# compiler version 3.0.12.0
 main.c: In function ‘create_file_names’:
 main.c:306:12: warning: ignoring return value of ‘mkstemp’, declared with
 attribute warn_unused_result [-Wunused-result]
  mkstemp(action_file_name);
 ^
 main.c:307:12: warning: ignoring return value of ‘mkstemp’, declared with
 attribute warn_unused_result [-Wunused-result]
  mkstemp(prolog_file_name);
 ^
 main.c:308:12: warning: ignoring return value of ‘mkstemp’, declared with
 attribute warn_unused_result [-Wunused-result]
  mkstemp(local_file_name);
 ^
 ./../jay/jay: 7 shift/reduce conflicts.
 mkdir -p -- ../class/lib/basic/
 MCS [basic] basic.exe
 cs-parser.jay(7041,10): error CS1729: The type `Mono.CSharp.Tokenizer'
 does not contain a constructor that takes `3' arguments
 cs-tokenizer.cs(435,10): (Location of the symbol related to previous error)
 Compilation failed: 1 error(s), 0 warnings
 make[7]: *** [../class/lib/basic/basic.exe] Error 1
 make[6]: *** [do-all] Error 2
 make[5]: *** [all-recursive] Error 1
 make[4]: *** [profile-do--basic--all] Error 2
 make[3]: *** [profiles-do--all] Error 2
 make[2]: *** [all-local] Error 2
 make[2]: Leaving directory `/usr/local/src/mono/runtime'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/usr/local/src/mono'
 make: *** [all] Error 2
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] sgen optimizing

2013-10-28 Thread Rodrigo Kumpera

Increasing the nursery size will reduce the amount of ephemeral garbage
that gets promoted to the old generation. The downside of a larger nursery
is the increased pause times for minor collections.

Sgen has a separate nursery designed to reduce temporal garbage by making
objects age in the nursery before promoting them. You can try it with
MON_GC_PARAMS=minor=split.


On Mon, Oct 28, 2013 at 9:40 AM, Greg Young gregoryyou...@gmail.com wrote:

 sorry for type meant 4mb not 4kb (that would be a really small nursery!)


 On Mon, Oct 28, 2013 at 3:38 PM, Greg Young gregoryyou...@gmail.comwrote:

 We have an application with a fairly common usage pattern. We send many
 messages in memory between a series of components (often with queues in the
 middle). In looking through sgen and defaults etc it would seem that by
 default there is a 4kb nursery. In this case we would have many of these
 small short lived messages getting promoted to the main heap. Is this a
 usage scenario where we might want to increase the size of the nursery to
 prevent the false promotions (aside from the messages we allocate very
 little else).

 Cheers,

 Greg

 --
 Le doute n'est pas une condition agréable, mais la certitude est absurde.




 --
 Le doute n'est pas une condition agréable, mais la certitude est absurde.

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


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

Re: [Mono-dev] sgen optimizing

2013-10-28 Thread Rodrigo Kumpera

On Mon, Oct 28, 2013 at 10:48 AM, Andrés G. Aragoneses
kno...@gmail.comwrote:

 On 28/10/13 15:42, Rodrigo Kumpera wrote:

 The downside of a larger
 nursery is the increased pause times for minor collections.


 The concurrent-garbage-collector announced at the Mono 3.0 release would
 also be an alternative to avoid the pause times, right?


The concurrent collector is only for major collections, it doesn't help
pause times for minor collections.

If yes, is the concurrent-garbage-collector the default for multi-core
 archs? If not, why not?


The concurrent collection remains experimental and under development.
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Removing NET_2_0 define

2013-10-18 Thread Rodrigo Kumpera

It can be removed. It wasn't done out of laziness.


On Wed, Oct 16, 2013 at 10:00 AM, Alexander Köplinger 
alex.koeplin...@outlook.com wrote:

 As far as I understand it, Mono now only supports the 2.0 and later
 profiles.

 ** **

 Wouldn’t it make sense to remove the #if NET_2_0 checks in the codebase as
 those are now unnecessary (every profile is now 2.0 or later)?

 Or are they actually required for something? If not, I’d provide a pull
 request to clean up those checks.

 ** **

 Alex

 ** **

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


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

Re: [Mono-dev] Contributing to Mono

2013-10-13 Thread Rodrigo Kumpera

It depends on what do you want to work on. If just mono, just configure,
make  make install. If you need gtk# and others, it's a bit trickier.


On Sun, Oct 13, 2013 at 3:45 PM, Abhinav Jangda abhijan...@hotmail.comwrote:

 Hello everyone,
 I want to contribute to mono. So, I want to know how I could. I have seen
 projects at http://www.mono-project.com/StudentProjects . I can work on
 some them which haven't been Accepted in this year GSoC. But problem is how
 to setup a development Mono Environment. Like GNOME uses JHBuild, so how to
 compile and install current unstable branch of mono?
 Thank You

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


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

Re: [Mono-dev] Problem building mono from source

2013-09-10 Thread Rodrigo Kumpera

It looks like you're either missing some headers or you misconfigured mono.


On Mon, Sep 9, 2013 at 5:21 PM, Luciano _ ln...@hotmail.com wrote:

 Linux, Debian wheezy x86-64

  --
 Date: Sun, 8 Sep 2013 21:45:52 -0400
 From: kump...@gmail.com
 To: ln...@hotmail.com
 CC: mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] Problem building mono from source


 What target are you trying to compile mono for?


 On Sun, Sep 8, 2013 at 7:59 PM, Luciano _ ln...@hotmail.com wrote:


 Hi, i’m having problems building mono from source. Could someone point me
 to the solution? Thanks.



 Making all in utils
 make[3]: se ingresa al directorio `/root/mono32/mono-3.2.0/mono/utils'
 make  all-am
 make[4]: se ingresa al directorio `/root/mono32/mono-3.2.0/mono/utils'
   CC   mono-md5.lo
   CC   mono-sha1.lo
   CC   mono-logger.lo
   CC   mono-codeman.lo
   CC   dlmalloc.lo
 dlmalloc.c:2515:12: warning: ‘change_mparam’ defined but not used
 [-Wunused-function]
 dlmalloc.c:2847:13: warning: ‘internal_malloc_stats’ defined but not used
 [-Wunused-function]
   CC   mono-counters.lo
   CC   mono-dl.lo
   CC   mono-internal-hash.lo
   CC   mono-io-portability.lo
   CC   monobitset.lo
   CC   mono-filemap.lo
   CC   mono-math.lo
   CC   mono-mmap.lo
   CC   mono-mutex.lo
   CC   mono-networkinterfaces.lo
   CC   mono-proclib.lo
   CC   mono-publib.lo
   CC   mono-time.lo
   CC   strtod.lo
 strtod.c:2448:1: warning: ‘quorem’ defined but not used [-Wunused-function]
 strtod.c:2596:1: warning: ‘nrv_alloc’ defined but not used
 [-Wunused-function]
 strtod.c:2620:1: warning: ‘__freedtoa’ defined but not used
 [-Wunused-function]
   CC   strenc.lo
   CC   mono-uri.lo
   CC   mono-poll.lo
   CC   mono-path.lo
   CC   mono-semaphore.lo
   CC   mono-stdlib.lo
   CC   mono-property-hash.lo
   CC   mono-value-hash.lo
   CC   mono-error.lo
   CC   mach-support.lo
   CC   mono-context.lo
 mono-context.c: In function ‘mono_sigctx_to_monoctx’:
 mono-context.c:47:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EAX’ [-Werror=implicit-function-declaration]
 mono-context.c:47:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EAX’ [-Wnested-externs]
 mono-context.c:48:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EBX’ [-Werror=implicit-function-declaration]
 mono-context.c:48:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EBX’ [-Wnested-externs]
 mono-context.c:49:2: error: implicit declaration of function
 ‘UCONTEXT_REG_ECX’ [-Werror=implicit-function-declaration]
 mono-context.c:49:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_ECX’ [-Wnested-externs]
 mono-context.c:50:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EDX’ [-Werror=implicit-function-declaration]
 mono-context.c:50:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EDX’ [-Wnested-externs]
 mono-context.c:51:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EBP’ [-Werror=implicit-function-declaration]
 mono-context.c:51:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EBP’ [-Wnested-externs]
 mono-context.c:52:2: error: implicit declaration of function
 ‘UCONTEXT_REG_ESP’ [-Werror=implicit-function-declaration]
 mono-context.c:52:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_ESP’ [-Wnested-externs]
 mono-context.c:53:2: error: implicit declaration of function
 ‘UCONTEXT_REG_ESI’ [-Werror=implicit-function-declaration]
 mono-context.c:53:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_ESI’ [-Wnested-externs]
 mono-context.c:54:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EDI’ [-Werror=implicit-function-declaration]
 mono-context.c:54:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EDI’ [-Wnested-externs]
 mono-context.c:55:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EIP’ [-Werror=implicit-function-declaration]
 mono-context.c:55:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EIP’ [-Wnested-externs]
 mono-context.c: In function ‘mono_monoctx_to_sigctx’:
 mono-context.c:79:25: error: lvalue required as left operand of assignment
 mono-context.c:80:25: error: lvalue required as left operand of assignment
 mono-context.c:81:25: error: lvalue required as left operand of assignment
 mono-context.c:82:25: error: lvalue required as left operand of assignment
 mono-context.c:83:25: error: lvalue required as left operand of assignment
 mono-context.c:84:25: error: lvalue required as left operand of assignment
 mono-context.c:85:25: error: lvalue required as left operand of assignment
 mono-context.c:86:25: error: lvalue required as left operand of assignment
 mono-context.c:87:25: error: lvalue required as left operand of assignment
 cc1: some warnings being treated as errors
 make[4]: *** [mono-context.lo] Error 1
 make[4]: se sale del directorio `/root/mono32/mono-3.2.0/mono/utils'
 make[3]: *** [all]

Re: [Mono-dev] Problem building mono from source

2013-09-08 Thread Rodrigo Kumpera

What target are you trying to compile mono for?


On Sun, Sep 8, 2013 at 7:59 PM, Luciano _ ln...@hotmail.com wrote:


 Hi, i’m having problems building mono from source. Could someone point me
 to the solution? Thanks.



 Making all in utils
 make[3]: se ingresa al directorio `/root/mono32/mono-3.2.0/mono/utils'
 make  all-am
 make[4]: se ingresa al directorio `/root/mono32/mono-3.2.0/mono/utils'
   CC   mono-md5.lo
   CC   mono-sha1.lo
   CC   mono-logger.lo
   CC   mono-codeman.lo
   CC   dlmalloc.lo
 dlmalloc.c:2515:12: warning: ‘change_mparam’ defined but not used
 [-Wunused-function]
 dlmalloc.c:2847:13: warning: ‘internal_malloc_stats’ defined but not used
 [-Wunused-function]
   CC   mono-counters.lo
   CC   mono-dl.lo
   CC   mono-internal-hash.lo
   CC   mono-io-portability.lo
   CC   monobitset.lo
   CC   mono-filemap.lo
   CC   mono-math.lo
   CC   mono-mmap.lo
   CC   mono-mutex.lo
   CC   mono-networkinterfaces.lo
   CC   mono-proclib.lo
   CC   mono-publib.lo
   CC   mono-time.lo
   CC   strtod.lo
 strtod.c:2448:1: warning: ‘quorem’ defined but not used [-Wunused-function]
 strtod.c:2596:1: warning: ‘nrv_alloc’ defined but not used
 [-Wunused-function]
 strtod.c:2620:1: warning: ‘__freedtoa’ defined but not used
 [-Wunused-function]
   CC   strenc.lo
   CC   mono-uri.lo
   CC   mono-poll.lo
   CC   mono-path.lo
   CC   mono-semaphore.lo
   CC   mono-stdlib.lo
   CC   mono-property-hash.lo
   CC   mono-value-hash.lo
   CC   mono-error.lo
   CC   mach-support.lo
   CC   mono-context.lo
 mono-context.c: In function ‘mono_sigctx_to_monoctx’:
 mono-context.c:47:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EAX’ [-Werror=implicit-function-declaration]
 mono-context.c:47:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EAX’ [-Wnested-externs]
 mono-context.c:48:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EBX’ [-Werror=implicit-function-declaration]
 mono-context.c:48:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EBX’ [-Wnested-externs]
 mono-context.c:49:2: error: implicit declaration of function
 ‘UCONTEXT_REG_ECX’ [-Werror=implicit-function-declaration]
 mono-context.c:49:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_ECX’ [-Wnested-externs]
 mono-context.c:50:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EDX’ [-Werror=implicit-function-declaration]
 mono-context.c:50:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EDX’ [-Wnested-externs]
 mono-context.c:51:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EBP’ [-Werror=implicit-function-declaration]
 mono-context.c:51:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EBP’ [-Wnested-externs]
 mono-context.c:52:2: error: implicit declaration of function
 ‘UCONTEXT_REG_ESP’ [-Werror=implicit-function-declaration]
 mono-context.c:52:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_ESP’ [-Wnested-externs]
 mono-context.c:53:2: error: implicit declaration of function
 ‘UCONTEXT_REG_ESI’ [-Werror=implicit-function-declaration]
 mono-context.c:53:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_ESI’ [-Wnested-externs]
 mono-context.c:54:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EDI’ [-Werror=implicit-function-declaration]
 mono-context.c:54:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EDI’ [-Wnested-externs]
 mono-context.c:55:2: error: implicit declaration of function
 ‘UCONTEXT_REG_EIP’ [-Werror=implicit-function-declaration]
 mono-context.c:55:2: warning: nested extern declaration of
 ‘UCONTEXT_REG_EIP’ [-Wnested-externs]
 mono-context.c: In function ‘mono_monoctx_to_sigctx’:
 mono-context.c:79:25: error: lvalue required as left operand of assignment
 mono-context.c:80:25: error: lvalue required as left operand of assignment
 mono-context.c:81:25: error: lvalue required as left operand of assignment
 mono-context.c:82:25: error: lvalue required as left operand of assignment
 mono-context.c:83:25: error: lvalue required as left operand of assignment
 mono-context.c:84:25: error: lvalue required as left operand of assignment
 mono-context.c:85:25: error: lvalue required as left operand of assignment
 mono-context.c:86:25: error: lvalue required as left operand of assignment
 mono-context.c:87:25: error: lvalue required as left operand of assignment
 cc1: some warnings being treated as errors
 make[4]: *** [mono-context.lo] Error 1
 make[4]: se sale del directorio `/root/mono32/mono-3.2.0/mono/utils'
 make[3]: *** [all] Error 2
 make[3]: se sale del directorio `/root/mono32/mono-3.2.0/mono/utils'
 make[2]: *** [all-recursive] Error 1
 make[2]: se sale del directorio `/root/mono32/mono-3.2.0/mono'
 make[1]: *** [all-recursive] Error 1
 make[1]: se sale del directorio `/root/mono32/mono-3.2.0'
 make: *** [all] Error 2

 ___
 Mono-devel-list mailing list

Re: [Mono-dev] mono from git will not build on cygwin 32

2013-09-05 Thread Rodrigo Kumpera

This is something we're aware of and we're trying to come up with a decent
solution there.


On Thu, Sep 5, 2013 at 1:21 PM, Bryan Crotaz bryan.cro...@silvercurve.co.uk
 wrote:

 I'm in complete agreement. If I didn't need the bug fix for a project I'd
 have given up by now.

 There are a very large number of windows developers who are experienced
 writing c# and unit tests. If they all fixed just 1 bug that would be a
 great help, right?

 All it needs is a VS2010 project (which can be upgraded to VS2012 by the
 developer) and a pre built runtime. We also need a directory map; put your
 classes here, put your tests here.

 If I had the above starting point I could fix two serialisation bugs that
 are stopping me, in a matter of a few hours.

 Bryan Crotaz
 Silver Curve

 On 5 Sep 2013, at 17:41, Greg Young gregoryyou...@gmail.com wrote:

 As a thought, it might be a good idea to have a simplified system for
 being able to do development on things like class libraries where people
 can get up and running within 2-3 minutes. As of now it seems getting an
 environment setup is a major impediment that prevents a lot of people from
 contributing.

 Cheers,

 Greg


 On Thu, Sep 5, 2013 at 6:22 PM, Mark Lintner mlint...@sinenomine.netwrote:

  I guess there are a few people having issues. I have lost track of who
 is who. I know once you get past these issues that some fixes have gone in
 to fix some build breaks that occur further along. There is still one
 outstanding. Just trying to help though, Cygwin gave me a lot of grief in
 the beginning. Good luck.


  --
 *From:* Bryan Crotaz [bryan.cro...@silvercurve.co.uk]
 *Sent:* Thursday, September 05, 2013 10:03 AM
 *To:* Mark Lintner
 *Cc:* Rafael Teixeira; Mono Development

 *Subject:* Re: [Mono-dev] mono from git will not build on cygwin 32

   Am I Londondev?

  I haven't had a chance to look for a make.bat or similar. Will take
 another look over the weekend.

 Bryan Crotaz
 Silver Curve

 On 5 Sep 2013, at 15:30, Mark Lintner mlint...@sinenomine.net wrote:

   I think think that londendev is the one with the make which does not
 seem to do anything. I was helping him diagnose the issue along the line of
 what your posting. It seems link it could be a batch file that does
 nothing. He was posting back but it doesn't seem to show up in this thread.


  --
 *From:* Rafael Teixeira [mono...@gmail.com]
 *Sent:* Thursday, September 05, 2013 6:22 AM
 *To:* Mark Lintner
 *Cc:* Mono Development
 *Subject:* Re: [Mono-dev] mono from git will not build on cygwin 32

   Mark, did you check your path? seems like you something else called
 make or make.bat in your path before the cygwin installed make and that
 thing is breaking your cygwin environment...

 Rafael Teixeira
 O..:.)


 On Wed, Sep 4, 2013 at 9:25 PM, mlgo mlint...@sinenomine.net wrote:

  Did you find the version and location of make?


  --
  *From:* londondev [via Mono] [ml-node+[hidden 
 email]http://user/SendEmail.jtp?type=nodenode=4660776i=0
 ]
  *Sent:* Wednesday, September 04, 2013 6:21 PM

 *To:* Mark Lintner
 *Subject:* Re: mono from git will not build on cygwin 32

Einstein@Einstein-PC /mono/git/mono
 $ make -d V=1

  Einstein@Einstein-PC /mono/git/mono
 $



 On 5 September 2013 00:04, mlgo [hidden 
 email]https://connect.emailsrvr.com/owa/UrlBlockedError.aspx
  wrote:

  also I think you can try



 make -d V=1
  --
  *From:* londondev [via Mono] [ml-node+[hidden 
 email]http://user/SendEmail.jtp?type=nodenode=4660770i=0
 ]
  *Sent:* Wednesday, September 04, 2013 5:58 PM
 *To:* Mark Lintner
 *Subject:* Re: mono from git will not build on cygwin 32

Result from ./autogen:

  
  Git submodules updated successfully

  mcs source:mcs

 Engine:
 GC:sgen and bundled Boehm GC with typed GC and
 parallel mark
 TLS:   pthread
 SIGALTSTACK:   no
 Engine:Building and using the JIT
 oprofile:  no
 BigArrays: no
 DTrace:no
 LLVM Back End: no (dynamically loaded: no)

 Libraries:
 .NET 2.0/3.5:  yes
 .NET 4.0:  yes
 .NET 4.5:  yes
 MonoDroid: no
 MonoTouch: no
 JNI support:   no
 libgdiplus:assumed to be installed
 zlib:  system zlib


  Now type `make' to compile

  Einstein@Einstein-PC /mono/git/mono
 $ make

  Einstein@Einstein-PC /mono/git/mono
 $


  Huh??


  On 4 September 2013 23:53, Mark Lintner [hidden 
 email]https://connect.emailsrvr.com/owa/UrlBlockedError.aspx
  wrote:

 gee, sorry. that should be prefix not profile

 --prefix=/usr/local

 I rushed because I had to go somewhere and got sloppy. Let me know if
 you still have issues.

 
  From: [hidden

Re: [Mono-dev] mono make on cygwin 32 including atomic.c windows x86 has atomic operations

2013-09-04 Thread Rodrigo Kumpera

I just pushed a fix for that.


On Wed, Sep 4, 2013 at 7:32 PM, Mark Lintner mlint...@sinenomine.netwrote:



 I previously found an issue in mingw/include/ddk/ntapi.h


 /* FIXME: Unknown definitions */


 typedef PVOID POBJECT_TYPE_LIST;

 typedef PVOID PEXECUTION_STATE;

 typedef PVOID PLANGID;


 commenting out as follows:


 /* FIXME: Unknown definitions */


 typedef PVOID POBJECT_TYPE_LIST;

 //typedef PVOID PEXECUTION_STATE;

 typedef PVOID PLANGID;



 Is this a problem for Cygwin or ming?
 --
 went back to the mono directory and

 did make clean
 followed by make

 It looks like a mingw header problem not mono as I thought. It would seem
 like everyone should hit this now that mono must use mingw to do cygwin
 build. I guess this has to be fixed by mingw.




 ---



 Unfortunately build does not complete. There is more. Next stop is here.
 Why is atomic.c even here? I think somehow configure is setting up the
 makefile wrong.



 ogc.a -L../../eglib/src /usr/src/mono/eglib/src/.libs/libeglib.a -lws2_32
 -lpsap
 i -lole32 -lwinmm -loleaut32 -ladvapi32 -lversion
 ../utils/.libs/libmonoutils.a(atomic.o): In function
 `InterlockedCompareExchange
 64':
 /usr/src/mono/mono/utils/atomic.c:240: undefined reference to
 `_imp__pthread_mut
 ex_lock'
 /usr/src/mono/mono/utils/atomic.c:246: undefined reference to
 `_imp__pthread_mut
 ex_unlock'
 collect2: error: ld returned 1 exit status
 Reaping losing child 0x8029f118 PID 6776
 Makefile:1243: recipe for target `pedump.exe' failed
 make[3]: *** [pedump.exe] Error 1
 Removing child 0x8029f118 PID 6776 from chain.
 make[3]: Leaving directory `/usr/src/mono/mono/metadata'
 Reaping losing child 0x800652c0 PID 8344
 Makefile:429: recipe for target `all-recursive' failed
 make[2]: *** [all-recursive] Error 1
 Removing child 0x800652c0 PID 8344 from chain.
 make[2]: Leaving directory `/usr/src/mono/mono'
 Reaping losing child 0x80060de8 PID 8968
 Makefile:510: recipe for target `all-recursive' failed
 make[1]: *** [all-recursive] Error 1
 Removing child 0x80060de8 PID 8968 from chain.
 make[1]: Leaving directory `/usr/src/mono'
 Reaping losing child 0x80088b28 PID 8692
 Makefile:437: recipe for target `all' failed
 make: *** [all] Error 2
 Removing child 0x80088b28 PID 8692 from chain.



 grep tells me this really is not defined



 me@My-PC me@My-PC /usr/src/mono
 $ grep -rl _imp__pthread_mutex_unlock .
 ./mono/utils/.libs/atomic.o
 ./mono/utils/.libs/libmonoutils.a
 ./mono/utils/atomic.o





 So looking at atomic.c



 #if defined (TARGET_MACH)  defined (TARGET_ARM) 
 (defined(__ARM_ARCH_7__) || defined(__ARM_ARCH_7A__) ||
 defined(__ARM_ARCH_7S__))

 gint64 InterlockedCompareExchange64(volatile gint64 *dest, gint64 exch,
 gint64 comp)  __attribute__ ((naked));

 gint64
 InterlockedCompareExchange64(volatile gint64 *dest, gint64 exch, gint64
 comp)
 {
  __asm__ (
  push {r4, r5, r6, r7}\n
  ldr r4, [sp, #16]\n
  dmb\n
 1:\n
  ldrexd r6, r7, [r0]\n
  cmp r7, r4\n
  bne 2f\n
  cmp r6, r3\n
  bne 2f\n
  strexd r5, r1, r2, [r0]\n
  cmp r5, #0\n
  bne 1b\n
 2:\n
  dmb\n
  mov r0, r6\n
  mov r1, r7\n
  pop {r4, r5, r6, r7}\n
  bx lr\n
  );
 }

 #else

 gint64
 InterlockedCompareExchange64(volatile gint64 *dest, gint64 exch, gint64
 comp)
 {
  gint64 old;

  pthread_mutex_lock (spin);

  old = *dest;
  if(old == comp)
   *dest = exch;

  pthread_mutex_unlock (spin);
  return old;
 }






 Windows has interlocked operations. The if statement does not seem to be
 relevant to windows, neither option is correct for windows, I don't believe
 it should be building this file on windows and intel hardware. This all
 built fine a couple of months ago and it builds fine on Centos 6.4 but then
 Centos has pthreads.
  --
 *From:* Zoltan Varga [var...@gmail.com]
 *Sent:* Tuesday, September 03, 2013 11:45 PM
 *To:* Mark Lintner
 *Cc:* mono-devel
 *Subject:* Re: [Mono-dev] mono from git will not build on cygwin 32

   Hi,

Try running with make V=1, that will print more information.

 Zoltan


 On Wed, Sep 4, 2013 at 6:05 AM, mlgo mlint...@sinenomine.net wrote:

 I updated Cygwin and now it no longer supports compilation of mono with
 gcc.
 There is no way to backlevel it. I found Zoltan's suggestion to use this
 configure statement:

 Hi,

   mono master can be built on windows using the mingw cross-compiler gcc,
 i.e. install the mingw-gcc package, and configure using:

 ./autogen.sh --host=i686-pc-mingw32
   Zoltan


 I'm using mono from git. Cygwin has all the recommended packages and I did
 not install the gcc-g++ but installed all mingw packages.  The build now
 always stops here. I have reinstalled Cygwin several times and pulled a
 new
 mono each time. I'm wondering now since there is a 64 bit Cygwin and a I
 have 64 bit machine should I be configuring with

Re: [Mono-dev] SGEN support when cross compiling

2013-08-27 Thread Rodrigo Kumpera

All this means is that the managed allocators won't be used.


On Mon, Aug 26, 2013 at 8:07 PM, Bassam Tabbara bas...@symform.com wrote:

  I tried that and I run into the following error when I run mono:

  sgen is not supported when using --with-tls=pthread

  Looking at the code here:

  https://github.com/mono/mono/blob/master/mono/metadata/sgen-gc.h#L990

  Seems like pthread is only supported on darwin and windows. I'm cross
 compiling to linux with with-tls=pthread.

   From: Rodrigo Kumpera kump...@gmail.com
 Date: Monday, August 26, 2013 5:01 PM

 To: Bassam Tabbara bas...@symform.com
 Cc: mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] SGEN support when cross compiling

   Configure with --thread=pthread


 On Mon, Aug 26, 2013 at 7:36 PM, Bassam Tabbara bas...@symform.comwrote:

  Thanks Rodrigo. Is there a trick then to bypass the __thread check
 during configuration?

  ./configure --host=armv5te-unknown-linux-gnueabi

  Fails with:

  configure: error: cannot run test program while cross compiling

  I worked around it with the following:


 https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51

  Do others not see this?

   From: Rodrigo Kumpera kump...@gmail.com
 Date: Monday, August 26, 2013 4:30 PM
 To: Bassam Tabbara bas...@symform.com
 Cc: mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] SGEN support when cross compiling

   sgen works fine on ARM and so does cross compiling to it.


 On Mon, Aug 26, 2013 at 6:19 PM, Bassam Tabbara bas...@symform.comwrote:

  Hello,

  I'm working in mono master, and it looks like sgen is not support when
 cross compiling. Sgen requiren with-tls=__thread and during configuration a
 check is made if __thread is functioning and that fails with the following
 error when cross compiling:

  configure: error: cannot run test program while cross compiling
 [

  I can work around this but disable the check during configuration, but
 I'm now wondering whether anyone is using sgen on ARM platforms? Are you
 cross compiling for those platforms? I must be missing something simple
 here.

  Thanks!
  Bassam

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




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

Re: [Mono-dev] SGEN support when cross compiling

2013-08-26 Thread Rodrigo Kumpera

sgen works fine on ARM and so does cross compiling to it.


On Mon, Aug 26, 2013 at 6:19 PM, Bassam Tabbara bas...@symform.com wrote:

  Hello,

  I'm working in mono master, and it looks like sgen is not support when
 cross compiling. Sgen requiren with-tls=__thread and during configuration a
 check is made if __thread is functioning and that fails with the following
 error when cross compiling:

   configure: error: cannot run test program while cross compiling
  [

  I can work around this but disable the check during configuration, but
 I'm now wondering whether anyone is using sgen on ARM platforms? Are you
 cross compiling for those platforms? I must be missing something simple
 here.

  Thanks!
 Bassam

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


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

Re: [Mono-dev] SGEN support when cross compiling

2013-08-26 Thread Rodrigo Kumpera

Configure with --thread=pthread


On Mon, Aug 26, 2013 at 7:36 PM, Bassam Tabbara bas...@symform.com wrote:

  Thanks Rodrigo. Is there a trick then to bypass the __thread check
 during configuration?

  ./configure --host=armv5te-unknown-linux-gnueabi

  Fails with:

  configure: error: cannot run test program while cross compiling

  I worked around it with the following:


 https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51

  Do others not see this?

   From: Rodrigo Kumpera kump...@gmail.com
 Date: Monday, August 26, 2013 4:30 PM
 To: Bassam Tabbara bas...@symform.com
 Cc: mono-devel-list@lists.ximian.com mono-devel-list@lists.ximian.com
 Subject: Re: [Mono-dev] SGEN support when cross compiling

   sgen works fine on ARM and so does cross compiling to it.


 On Mon, Aug 26, 2013 at 6:19 PM, Bassam Tabbara bas...@symform.comwrote:

  Hello,

  I'm working in mono master, and it looks like sgen is not support when
 cross compiling. Sgen requiren with-tls=__thread and during configuration a
 check is made if __thread is functioning and that fails with the following
 error when cross compiling:

  configure: error: cannot run test program while cross compiling
 [

  I can work around this but disable the check during configuration, but
 I'm now wondering whether anyone is using sgen on ARM platforms? Are you
 cross compiling for those platforms? I must be missing something simple
 here.

  Thanks!
  Bassam

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



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

Re: [Mono-dev] mono-3.2.1 make check failures sgen assertion

2013-08-19 Thread Rodrigo Kumpera

Those hangs are known limitations of our AOT technology for which we have
no plans on fixing in the near term.


On Mon, Aug 19, 2013 at 10:49 AM, Charles Randall 
charles.rand...@nirvanix.com wrote:

 Continuing this investigation, I ran the following using the mono-3-2
 branch as of a0fc6ba35b7454425b8ec772b2652730b8030a52.

 I couldn't run a top-level make check because of this bug,

 https://bugzilla.xamarin.com/show_bug.cgi?id=14049

 Because of this limitation, I ran make check in the mono directory.

 In 117 failures in 441 iterations (26.5%). Here's the count of the tests
 that failed,

 103 gsharing-valuetype-layout.exe
   8 sgen-bridge.exe|ms-conc
   2 gc-altstack.exe
   1 sgen-weakref-stress.exe|ms-par
   1 sgen-case-23400.exe|ms-par
   1 sgen-bridge.exe|plain
   1 bug-10127.exe

 Looking only at the 103 failures of gsharing-valuetype-layout.exe, in 81
 of the failures were the 120 second test timeout. A successful run of this
 test takes less than a second. In the timeout case, mono simply appears to
 hang.

 Running this manually, when it hangs it stops using CPU and strace reports,

 # strace -fp 4289
 Process 4289 attached with 3 threads
 [pid  4292] futex(0x7f626420, FUTEX_WAIT_PRIVATE, 2, NULL unfinished
 ...
 [pid  4290] futex(0x967340, FUTEX_WAIT_PRIVATE, 0, NULL unfinished ...
 [pid  4289] futex(0x1c84f1c, FUTEX_WAIT_PRIVATE, 3, NULL

 Here's a gstack stack trace,

 http://sprunge.us/CfjX

 This is trivial to reproduce on my system,

 # uname -a
 Linux linux-mono.com 3.7.10-1.1-desktop #1 SMP PREEMPT Thu Feb 28
 15:06:29 UTC 2013 (82d3f21) x86_64 x86_64 x86_64 GNU/Linux

 Running as a VMware virtual machine, 4 CPU, 8 GB RAM.

 I use this simple script to repeatedly run the commands,

 http://sprunge.us/VKTS

 E.g.,

 ./repeat.sh mono gsharing-valuetype-layout.exe

 Filed bug 14073 to track this,

 https://bugzilla.xamarin.com/show_bug.cgi?id=14073

 Looking back at previous failures, I realize that this hang can be worked
 around by disabling AOT using the mono option '-O=-aot. Ugh. Given that,
 this may be the same as bug 7564,

 https://bugzilla.xamarin.com/show_bug.cgi?id=7564

 -Charles

 -Original Message-
 From: Charles Randall
 Sent: Wednesday, August 14, 2013 2:36 PM
 To: mono-devel-list@lists.ximian.com
 Subject: RE: [Mono-dev] mono-3.2.1 make check failures  sgen assertion

 Continuing to dig into these failures, here is what I've found so far.

 The majority of the bug-10127 test failures were due to bug 13604 and now
 resolves the assert in sgen-os-posix.c:60 and is already in the mono 3.2
 branch and should be included in the upcoming mono 3.2.2.

 https://bugzilla.xamarin.com/show_bug.cgi?id=13604

 The failures in sgen-weakref-stress were resolved in this fix which is
 planned to be in the upcoming 3.2.2,


 https://github.com/mono/mono/commit/aef4b77ea79aa0a4c06e10bd5842da9df0d10973

 The majority of delegate2 test failures are due to bug 7564. There is a
 workaround for this listed in the bug report.

 https://bugzilla.xamarin.com/show_bug.cgi?id=7564

 That bug is pretty disturbing. Once you've determined you need the
 workaround, your application has already hung. If your application is
 critical to your business that's a tough lesson to learn.

 The discrepancy between my observed make check failures and the all
 green results of the monkey wrench automated tests appears to be because
 many tests are disabled for monkey wrench. See DISABLED_TESTS_WRENCH in
 mono/tests/Makefile for the details. Notably, bug-10127 is disabled.

 Continuing these tests with the 3.2 branch and the second fix above.

 -Charles


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

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

Re: [Mono-dev] Random deadlocks when spawning via new Process

2013-08-12 Thread Rodrigo Kumpera

I have no idea.  I'd need to reproduce it first


On Sun, Aug 11, 2013 at 7:01 PM, gerber.matthew gerber.matt...@gmail.comwrote:

 Rodrigo Kumpera wrote
  Can you produce a test case that shows this hang? This it will be much
  easier for the moonteam to debug and fix it.

 Rodrigo (and others),

 Do you have any insight into the deadlock situation I described above?

 Cheers,
 Matt




 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Random-deadlocks-when-spawning-via-new-Process-tp4660495p4660511.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

Re: [Mono-dev] Random deadlocks when spawning via new Process

2013-08-12 Thread Rodrigo Kumpera

I filed https://bugzilla.xamarin.com/show_bug.cgi?id=13920 to track this.



On Mon, Aug 12, 2013 at 10:40 AM, Rodrigo Kumpera kump...@gmail.com wrote:

 I have no idea.  I'd need to reproduce it first


 On Sun, Aug 11, 2013 at 7:01 PM, gerber.matthew 
 gerber.matt...@gmail.comwrote:

 Rodrigo Kumpera wrote
  Can you produce a test case that shows this hang? This it will be much
  easier for the moonteam to debug and fix it.

 Rodrigo (and others),

 Do you have any insight into the deadlock situation I described above?

 Cheers,
 Matt




 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Random-deadlocks-when-spawning-via-new-Process-tp4660495p4660511.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com
 http://lists.ximian.com/mailman/listinfo/mono-devel-list



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

Re: [Mono-dev] Random deadlocks when spawning via new Process

2013-08-10 Thread Rodrigo Kumpera

Can you produce a test case that shows this hang? This it will be much
easier for the moonteam to debug and fix it.

On Saturday, August 10, 2013, gerber.matthew wrote:

 greenboxal wrote
  Hi,
 
  That isn't the Process class code, on the frame #3 you can see that the
  thread received a signal, that is SGen trying to stop the world to
 perform
  collection.
  Maybe the deadlock is related to the GC itself as you can be putting it
 at
  pressure by spawning many process.

 Jonathan,

 Thanks for the response. Any ideas about how I might prevent the deadlocks?

 Matt




 --
 View this message in context:
 http://mono.1490590.n4.nabble.com/Random-deadlocks-when-spawning-via-new-Process-tp4660495p4660498.html
 Sent from the Mono - Dev mailing list archive at Nabble.com.
 ___
 Mono-devel-list mailing list
 Mono-devel-list@lists.ximian.com javascript:;
 http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

1 2 3 4 5 6 7 8 >

1 - 100 of 713 matches

Mail list logo