Re: [Mono-dev] Mono on Embedded Platform
On 21 Nov 2014, at 07:05, techi eth techi...@gmail.com wrote: Hey, I have following point to check before start. 1) 1) How can I achieve small footprint from mono. I have followed the below link but it produces install directory which is more than 100 MB with mono 3.10.0. I know nothing about embedded platforms but I do know this. I run a 64 bit Mono run time out of my OS X app bundle. The omits all build tool chain stuff and consists of libmono, mscorlib 4 + 4.5, some configs and the 14 Mono assemblies required by my managed code at runtime. I use the Mono assemblies as is i.e: I don’t tinker with the assemblies to reduce code size. This comes in at 17MB for my usage case minimal Mono runtime environment. My actual application managed code is then additional to this. Jonathan ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Embedded Platform
On Fri, Nov 21, 2014 at 2:05 AM, techi eth techi...@gmail.com wrote: Hey, I am very new to mono. I am looking forward to use this great platform over Linux on ARM target. I have following point to check before start. 1) 1) How can I achieve small footprint from mono. I have followed the below link but it produces install directory which is more than 100 MB with mono 3.10.0. http://www.mono-project.com/docs/compiling-mono/small-footprint/ I would like to know below listed things are manual way of doing or I can do this by using any of the configure option. · Removing unneeded features · Removing unneeded data · Compilation hints · Reducing code in assemblies 2) 2) I will going to write application which is multitasking/multithreading, accessing some device port, talking to Ethernet, running WEB service. Can anyone suggest with mono over Linux what is Flash RAM size I should use. Techi ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list Hi Techi. Wanted to share my experience. We aren't storage constrained, so 100MB+ for us was ok. System with an arm cortex a8 processor, the beaglebone black actually. Found out that for every instance of mono we had running that there was some 17MB of ram overhead. In addition, there is a little bit of a startup time delay, a second or so, before the the runtime is running our code. I had asked here about the ram overhead but there wasn't any response about how to shrink it down or what might be contributing to it a bit. We would have been ok with maybe 5MB per process. Keep in mind that I was testing with a pretty trivial application, it wasn't doing lots of memory allocations, so nothing in the application could explain why 50k of memory allocations translated to 17MB of overhead. We ended up rewriting four or five smallish utility applications from c# into c++ and leaving a single application of high complexity as our sole c# application that will run on the system. This dropped off 17MB * 4 of ram and reduced startup time for these applications to fractions of a second. Chris ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] Mono on Embedded Platform
The final version of Mono includes an entire SDK. You really only need the mono binary, the configuration files (if any) and the DLLs that you need to use. Which should be some 4 megs or so. As for features to disable in the VM, you need to be careful, but the configure command takes a set of parameters for features you can remove. On Fri, Nov 21, 2014 at 2:05 AM, techi eth techi...@gmail.com wrote: Hey, I am very new to mono. I am looking forward to use this great platform over Linux on ARM target. I have following point to check before start. 1) 1) How can I achieve small footprint from mono. I have followed the below link but it produces install directory which is more than 100 MB with mono 3.10.0. http://www.mono-project.com/docs/compiling-mono/small-footprint/ I would like to know below listed things are manual way of doing or I can do this by using any of the configure option. · Removing unneeded features · Removing unneeded data · Compilation hints · Reducing code in assemblies 2) 2) I will going to write application which is multitasking/multithreading, accessing some device port, talking to Ethernet, running WEB service. Can anyone suggest with mono over Linux what is Flash RAM size I should use. Techi ___ 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] .NET and Mono integration, the plans
Follow up. I am wondering if we should submodule the reference source, or just copy the files? The module wont be updated frequently, and it is making the Mono download a lot longer than it needs to be. Miguel On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] .NET and Mono integration, the plans
Hello, We have some test suites for the core that Microsoft has shared with us under a Microsoft/Xamarin agreement, but they are for just a few pieces, not the entire thing that is being open sourced. On Fri, Nov 21, 2014 at 1:35 PM, Miguel de Icaza mig...@xamarin.com wrote: Follow up. I am wondering if we should submodule the reference source, or just copy the files? The module wont be updated frequently, and it is making the Mono download a lot longer than it needs to be. Miguel On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
Re: [Mono-dev] [Mono-list] .NET and Mono integration, the plans
In terms of the mono download, are you referring to a git clone? or the source tarball? In terms of clone, I'd say it's valid to be there, they may not change often but it would be good to see the version history within that fork, rather than having to compare across mono and the fork. However, for the tarball, we could strip out the files that aren't required with some kind of clever script. On 21 November 2014 18:35, Miguel de Icaza mig...@xamarin.com wrote: Follow up. I am wondering if we should submodule the reference source, or just copy the files? The module wont be updated frequently, and it is making the Mono download a lot longer than it needs to be. Miguel On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - mono-l...@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-devel-list mailing list Mono-devel-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-devel-list
[Mono-list] How to install mono using yum on CentOS?
I'm using CentOS 6.6 and add the mono package repository into yum. But I found that the dependence libraries libpng15.so.15 libtiff.so.5 libc.so.6 were not in any of the repositories. I've already add the EPEL repository but the top version of these libraries could not satisfy. the log is below Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libpng15.so.15()(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libtiff.so.5()(64bit) Error: Package: mono-core-3.10.0-2.x86_64 (download.mono-project.com_repo_centos_) Requires: libc.so.6(GLIBC_2.16)(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libc.so.6(GLIBC_2.14)(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libtiff.so.5(LIBTIFF_4.0)(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libpng15.so.15(PNG15_0)(64bit) for example that the glibc library in repository is Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * epel: mirrors.yun-idc.com Installed Packages Name: glibc Arch: x86_64 Version : 2.12 Release : 1.149.el6 Size: 12 M Repo: installed From repo : base So how could I install mono using yum? Or the only way is to compile mono with source code ? -- View this message in context: http://mono.1490590.n4.nabble.com/How-to-install-mono-using-yum-on-CentOS-tp4664746.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] How to install mono using yum on CentOS?
Hello, you are welcome to use my builds, see http://www.pokorra.de/2014/10/mono-3-10-and-monodevelop-5-45-5-for-linux/ For CentOS7, I had to patch libgdiplus: https://build.opensuse.org/package/view_file/home:tpokorra:mono/libgdiplus/libgdiplus-2.10.9-libpng15.patch?expand=1 @Jo: Perhaps that is missing in the Xamarin packages? All the best, Timotheus On 21 November 2014 13:11, terender teren...@hotmail.com wrote: I'm using CentOS 6.6 and add the mono package repository into yum. But I found that the dependence libraries libpng15.so.15 libtiff.so.5 libc.so.6 were not in any of the repositories. I've already add the EPEL repository but the top version of these libraries could not satisfy. the log is below Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libpng15.so.15()(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libtiff.so.5()(64bit) Error: Package: mono-core-3.10.0-2.x86_64 (download.mono-project.com_repo_centos_) Requires: libc.so.6(GLIBC_2.16)(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libc.so.6(GLIBC_2.14)(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libtiff.so.5(LIBTIFF_4.0)(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libpng15.so.15(PNG15_0)(64bit) for example that the glibc library in repository is Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * epel: mirrors.yun-idc.com Installed Packages Name: glibc Arch: x86_64 Version : 2.12 Release : 1.149.el6 Size: 12 M Repo: installed From repo : base So how could I install mono using yum? Or the only way is to compile mono with source code ? -- View this message in context: http://mono.1490590.n4.nabble.com/How-to-install-mono-using-yum-on-CentOS-tp4664746.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Kontaktdaten: in Plauen: 03741 7424995 ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] How to install mono using yum on CentOS?
You guys can take a look at what we're doing with Media Browser on CentOS: https://github.com/MediaBrowser/MediaBrowser.Build We install the epel repository, then mono. You can see the scripts in our link above. On Fri, Nov 21, 2014 at 8:36 AM, Timotheus Pokorra timotheus.poko...@solidcharity.com wrote: Hello, you are welcome to use my builds, see http://www.pokorra.de/2014/10/mono-3-10-and-monodevelop-5-45-5-for-linux/ For CentOS7, I had to patch libgdiplus: https://build.opensuse.org/package/view_file/home:tpokorra:mono/libgdiplus/libgdiplus-2.10.9-libpng15.patch?expand=1 @Jo: Perhaps that is missing in the Xamarin packages? All the best, Timotheus On 21 November 2014 13:11, terender teren...@hotmail.com wrote: I'm using CentOS 6.6 and add the mono package repository into yum. But I found that the dependence libraries libpng15.so.15 libtiff.so.5 libc.so.6 were not in any of the repositories. I've already add the EPEL repository but the top version of these libraries could not satisfy. the log is below Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libpng15.so.15()(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libtiff.so.5()(64bit) Error: Package: mono-core-3.10.0-2.x86_64 (download.mono-project.com_repo_centos_) Requires: libc.so.6(GLIBC_2.16)(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libc.so.6(GLIBC_2.14)(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libtiff.so.5(LIBTIFF_4.0)(64bit) Error: Package: libgdiplus0-3.8-0.x86_64 (download.mono-project.com_repo_centos_) Requires: libpng15.so.15(PNG15_0)(64bit) for example that the glibc library in repository is Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * epel: mirrors.yun-idc.com Installed Packages Name: glibc Arch: x86_64 Version : 2.12 Release : 1.149.el6 Size: 12 M Repo: installed From repo : base So how could I install mono using yum? Or the only way is to compile mono with source code ? -- View this message in context: http://mono.1490590.n4.nabble.com/How-to-install-mono-using-yum-on-CentOS-tp4664746.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Kontaktdaten: in Plauen: 03741 7424995 ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list -- Luke Pulverenti ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] How to install mono using yum on CentOS?
My experience on CentOS is that's a lot better to compile from git, it's
really easy:
$ sudo apt-get install git autoconf libtool automake build-essential
gettext
$ git clone git://github.com/mono/mono.git
$ cd mono
$ ./autogen.sh --prefix=/usr/local
$ make get-monolite-latest
$ make EXTERNAL_MCS=${PWD}/mcs/class/lib/monolite/gmcs.exe
$ make
$ make install
With that you will have the latest mono version up and running.
Cheers.
2014-11-21 13:11 GMT+01:00 terender teren...@hotmail.com:
I'm using CentOS 6.6 and add the mono package repository into yum. But I
found that the dependence libraries libpng15.so.15 libtiff.so.5 libc.so.6
were not in any of the repositories. I've already add the EPEL repository
but the top version of these libraries could not satisfy.
the log is below
Error: Package: libgdiplus0-3.8-0.x86_64
(download.mono-project.com_repo_centos_)
Requires: libpng15.so.15()(64bit)
Error: Package: libgdiplus0-3.8-0.x86_64
(download.mono-project.com_repo_centos_)
Requires: libtiff.so.5()(64bit)
Error: Package: mono-core-3.10.0-2.x86_64
(download.mono-project.com_repo_centos_)
Requires: libc.so.6(GLIBC_2.16)(64bit)
Error: Package: libgdiplus0-3.8-0.x86_64
(download.mono-project.com_repo_centos_)
Requires: libc.so.6(GLIBC_2.14)(64bit)
Error: Package: libgdiplus0-3.8-0.x86_64
(download.mono-project.com_repo_centos_)
Requires: libtiff.so.5(LIBTIFF_4.0)(64bit)
Error: Package: libgdiplus0-3.8-0.x86_64
(download.mono-project.com_repo_centos_)
Requires: libpng15.so.15(PNG15_0)(64bit)
for example that the glibc library in repository is
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
* epel: mirrors.yun-idc.com
Installed Packages
Name: glibc
Arch: x86_64
Version : 2.12
Release : 1.149.el6
Size: 12 M
Repo: installed
From repo : base
So how could I install mono using yum? Or the only way is to compile mono
with source code ?
--
View this message in context:
http://mono.1490590.n4.nabble.com/How-to-install-mono-using-yum-on-CentOS-tp4664746.html
Sent from the Mono - General mailing list archive at Nabble.com.
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] How to install mono using yum on CentOS?
Thank you guys! Finally I compiled from tarball myself. -- View this message in context: http://mono.1490590.n4.nabble.com/How-to-install-mono-using-yum-on-CentOS-tp4664746p4664751.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET and Mono integration, the plans
Hello Miguel, Thanks for sharing your strategy of incorporating or making use of MS' open-source. Your disclosure opens my eye particularly your remarks on CAS in Mono, a fundamental security framework of .Net, and not following the Object disposable pattern faithfully. One thing that is not very clear is: will this effort produces more consistent run time behavior between CLR and Mono whenever possible and where the library are not dealing with platform specific stuff? For example System.Diagnostics.Debug.Assert is not consistent but it should be. I am using Mono as a cross-platform tool and I have run into many inconsistent behavior - some I have work around but others I have no work around or even solution. Has Microsoft provided Mono team a set of testing harness to test the run time? Thanks. MarL -- View this message in context: http://mono.1490590.n4.nabble.com/NET-and-Mono-integration-the-plans-tp4664703p4664752.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
[Mono-list] Problem with sgen
There is a memory problem with mono-sgen on linux. I'm using some pinned byte[] buffers in my project, and there's a randomly crash with signal SIGSEGV, it could happen anywhere at anytime. I guess there's some write oprations out of bound in memory, so I use valgrind to check the program. Then I found that a while after the program start within some alloc oprations, valgrind report a problem in sgen that is: ==6504== Thread 1: ==6504== Conditional jump or move depends on uninitialised value(s) ==6504==at 0x5C4D46: conservatively_pin_objects_from (sgen-gc.c:1200) ==6504==by 0x5C5322: scan_thread_data (sgen-gc.c:3778) ==6504==by 0x5CA7BA: collect_nursery (sgen-gc.c:2298) ==6504==by 0x5CB877: sgen_perform_collection (sgen-gc.c:3196) ==6504==by 0x5E8CCF: mono_gc_alloc_obj_nolock (sgen-alloc.c:315) ==6504==by 0x5E90E3: mono_gc_alloc_obj (sgen-alloc.c:491) ==6504==by 0x40C09E2: ??? ==6504==by 0x4198331: ??? ==6504==by 0x40BBF42: ??? ==6504==by 0x41DE33: mono_jit_runtime_invoke (mini.c:6738) ==6504==by 0x5A252A: mono_runtime_invoke (object.c:2831) ==6504==by 0x5A5DCF: mono_runtime_exec_main (object.c:4096) ==6504== Uninitialised value was created by a stack allocation ==6504==at 0x57D2E0: start_wrapper (threads.c:701) Any read or write oprations right after that would trigger an Invalid write/read error in valgrind and then process got killed. Is that a bug in sgen collect_nursery with pinned objects in nursery heap? I have checked on both mono 3.2.3 and 3.10.0, and I'm using tarball to compile them myself. The enviroment is CentOS 6.6 Kernal 2.6.32-358.6.2.el6.x86_64, GCC version 4.4.7 I could upload the whole log of valgrind for both mono 3.2.3 and 3.10.0 if needed. Btw: the problem does not happen if I use boehm -- View this message in context: http://mono.1490590.n4.nabble.com/Problem-with-sgen-tp4664753.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET and Mono integration, the plans
Follow up. I am wondering if we should submodule the reference source, or just copy the files? The module wont be updated frequently, and it is making the Mono download a lot longer than it needs to be. Miguel On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET and Mono integration, the plans
Hello, We have some test suites for the core that Microsoft has shared with us under a Microsoft/Xamarin agreement, but they are for just a few pieces, not the entire thing that is being open sourced. On Fri, Nov 21, 2014 at 1:35 PM, Miguel de Icaza mig...@xamarin.com wrote: Follow up. I am wondering if we should submodule the reference source, or just copy the files? The module wont be updated frequently, and it is making the Mono download a lot longer than it needs to be. Miguel On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] .NET and Mono integration, the plans
In terms of the mono download, are you referring to a git clone? or the source tarball? In terms of clone, I'd say it's valid to be there, they may not change often but it would be good to see the version history within that fork, rather than having to compare across mono and the fork. However, for the tarball, we could strip out the files that aren't required with some kind of clever script. On 21 November 2014 18:35, Miguel de Icaza mig...@xamarin.com wrote: Follow up. I am wondering if we should submodule the reference source, or just copy the files? The module wont be updated frequently, and it is making the Mono download a lot longer than it needs to be. Miguel On Wed, Nov 19, 2014 at 12:48 PM, Miguel de Icaza mig...@xamarin.com wrote: Hey guys, As promised, the plans: http://www.mono-project.com/docs/about-mono/dotnet-integration/ If you start work on something, please notify the list, and update the Trello board: https://trello.com/b/vRPTMfdz/net-framework-integration-into-mono Miguel ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Problem with sgen
That's a false positive. sgen conservatively scans the stack and this does trip valgrind. On Fri, Nov 21, 2014 at 10:29 AM, terender teren...@hotmail.com wrote: There is a memory problem with mono-sgen on linux. I'm using some pinned byte[] buffers in my project, and there's a randomly crash with signal SIGSEGV, it could happen anywhere at anytime. I guess there's some write oprations out of bound in memory, so I use valgrind to check the program. Then I found that a while after the program start within some alloc oprations, valgrind report a problem in sgen that is: ==6504== Thread 1: ==6504== Conditional jump or move depends on uninitialised value(s) ==6504==at 0x5C4D46: conservatively_pin_objects_from (sgen-gc.c:1200) ==6504==by 0x5C5322: scan_thread_data (sgen-gc.c:3778) ==6504==by 0x5CA7BA: collect_nursery (sgen-gc.c:2298) ==6504==by 0x5CB877: sgen_perform_collection (sgen-gc.c:3196) ==6504==by 0x5E8CCF: mono_gc_alloc_obj_nolock (sgen-alloc.c:315) ==6504==by 0x5E90E3: mono_gc_alloc_obj (sgen-alloc.c:491) ==6504==by 0x40C09E2: ??? ==6504==by 0x4198331: ??? ==6504==by 0x40BBF42: ??? ==6504==by 0x41DE33: mono_jit_runtime_invoke (mini.c:6738) ==6504==by 0x5A252A: mono_runtime_invoke (object.c:2831) ==6504==by 0x5A5DCF: mono_runtime_exec_main (object.c:4096) ==6504== Uninitialised value was created by a stack allocation ==6504==at 0x57D2E0: start_wrapper (threads.c:701) Any read or write oprations right after that would trigger an Invalid write/read error in valgrind and then process got killed. Is that a bug in sgen collect_nursery with pinned objects in nursery heap? I have checked on both mono 3.2.3 and 3.10.0, and I'm using tarball to compile them myself. The enviroment is CentOS 6.6 Kernal 2.6.32-358.6.2.el6.x86_64, GCC version 4.4.7 I could upload the whole log of valgrind for both mono 3.2.3 and 3.10.0 if needed. Btw: the problem does not happen if I use boehm -- View this message in context: http://mono.1490590.n4.nabble.com/Problem-with-sgen-tp4664753.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Debug.Assert - a cross-platform issue
Hello, I have to thank Microsoft to open-source the .Net library allowing me to read their code to get to the bottom of Microsoft's treatment (even I have already asserted the value at runtime) of default values for the System.Diagnostics.DefaultTraceListener. For those interested in reading this can find it here: DefaultTraceListener.cs https://github.com/Microsoft/referencesource/blob/9da503f9ef21e8d1f2905c78d4e3e5cbb3d6f85a/System/compmod/system/diagnostics/DefaultTraceListener.cs . The default value of property that determines the reaction of Debug.Assert is set here: assertuienabled https://github.com/Microsoft/referencesource/blob/9da503f9ef21e8d1f2905c78d4e3e5cbb3d6f85a/System/compmod/system/diagnostics/AssertSection.cs . It is not true that Mono does not create an instance of DefaultTraceListener on start up otherwise code like this: DefaultTraceListener defListener = Debug.Listeners[Default] as DefaultTraceListener; will produce a null value for defListener. It will be good if these classes and assemblies from Microsoft open-sources are incorporated verbatim into Mono to replace its inconsistent code. In this thread some one had pointed out to me that because I admitted routinely disassembling Microsoft's assemblies, in accordance to Mono's contribution rule http://www.mono-project.com/Contributing#Important_Rules , I cannot contribute. With Microsoft now open-sourcing their .Net library, what will happen to this contribution rule? MarL -- View this message in context: http://mono.1490590.n4.nabble.com/Debug-Assert-a-cross-platform-issue-tp4662174p4664765.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Debug.Assert - a cross-platform issue
(This is my personal opinion, I'm not a collaborator) This is also a question that is better for the dev list. My personal opinion is that if it's a verbatim port from the referencesource on github, that you shouldn't be precluded from contributing. Anything beyond that would be questionable I would imagine. You have to remember that the referencesource isn't the same decompiled source from previous versions. I'm not sure where the patent promise would sit in that instance. I know a few people who fell under this same rule, so I would like to see some clarity too. Thanks, Martin On 22 November 2014 00:25, MarLOne infoseeker...@gmail.com wrote: Hello, I have to thank Microsoft to open-source the .Net library allowing me to read their code to get to the bottom of Microsoft's treatment (even I have already asserted the value at runtime) of default values for the System.Diagnostics.DefaultTraceListener. For those interested in reading this can find it here: DefaultTraceListener.cs https://github.com/Microsoft/referencesource/blob/9da503f9ef21e8d1f2905c78d4e3e5cbb3d6f85a/System/compmod/system/diagnostics/DefaultTraceListener.cs . The default value of property that determines the reaction of Debug.Assert is set here: assertuienabled https://github.com/Microsoft/referencesource/blob/9da503f9ef21e8d1f2905c78d4e3e5cbb3d6f85a/System/compmod/system/diagnostics/AssertSection.cs . It is not true that Mono does not create an instance of DefaultTraceListener on start up otherwise code like this: DefaultTraceListener defListener = Debug.Listeners[Default] as DefaultTraceListener; will produce a null value for defListener. It will be good if these classes and assemblies from Microsoft open-sources are incorporated verbatim into Mono to replace its inconsistent code. In this thread some one had pointed out to me that because I admitted routinely disassembling Microsoft's assemblies, in accordance to Mono's contribution rule http://www.mono-project.com/Contributing#Important_Rules , I cannot contribute. With Microsoft now open-sourcing their .Net library, what will happen to this contribution rule? MarL -- View this message in context: http://mono.1490590.n4.nabble.com/Debug-Assert-a-cross-platform-issue-tp4662174p4664765.html Sent from the Mono - General mailing list archive at Nabble.com. ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list ___ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list
Re: [Mono-list] Problem with sgen
But why there will be an invalid read/write right after that and crash the process? I'm using a native library (libuv) that directly read and write into the memory of the pinned object, when run under valgrind, any r/w opration fails and cause an error. Below is the valgrind output : --27495-- memcheck GC: 1000 nodes, 1 survivors ( 0.1%) --27495-- memcheck GC: 1000 nodes, 1 survivors ( 0.1%) --27495-- memcheck GC: 1000 nodes, 2 survivors ( 0.2%) ==27495== Conditional jump or move depends on uninitialised value(s) ==27495==at 0x5C7D06: conservatively_pin_objects_from (sgen-gc.c:1476) ==27495==by 0x5C83EC: scan_thread_data (sgen-gc.c:4022) ==27495==by 0x5CEAF3: collect_nursery (sgen-gc.c:2566) ==27495==by 0x5CF6CD: sgen_perform_collection (sgen-gc.c:3445) ==27495==by 0x5E73B7: mono_gc_alloc_obj_nolock (sgen-alloc.c:288) ==27495==by 0x5E77BB: mono_gc_alloc_obj (sgen-alloc.c:465) ==27495==by 0x40C4E5E: ??? ==27495==by 0x419D171: ??? ==27495==by 0x40BCE32: ??? ==27495==by 0x41D807: mono_jit_runtime_invoke (mini.c:6473) ==27495==by 0x5A41FA: mono_runtime_invoke (object.c:2827) ==27495==by 0x5A7FD2: mono_runtime_exec_main (object.c:4062) ==27495== Uninitialised value was created by a stack allocation ==27495==at 0x57CCF0: start_wrapper (threads.c:647) ==27495== ==27495== Invalid read of size 1 ==27495==at 0x41A2774: ??? ==27495==by 0x9: ??? ==27495==by 0xE1670FF: ??? ==27495==by 0x: ??? ==27495==by 0xF06604E: uv__read (stream.c:957) ==27495==by 0xF06706B: uv__stream_io (stream.c:1121) ==27495==by 0xF06B8AA: uv__io_poll (linux-core.c:263) ==27495==by 0xF05F5AB: uv_run (core.c:317) ==27495==by 0x41946A1: ??? ==27495==by 0x40BCE32: ??? ==27495==by 0x41D807: mono_jit_runtime_invoke (mini.c:6473) ==27495==by 0x5A41FA: mono_runtime_invoke (object.c:2827) ==27495== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==27495== ==27495== Thread 1 return signal frame corrupted. Killing process. ==27495== ==27495== Process terminating with default action of signal 11 (SIGSEGV) ==27495== General Protection Fault ==27495==at 0x54CE717: ??? (in /lib64/libpthread-2.12.so) ==27495==by 0x54CE70F: ??? (in /lib64/libpthread-2.12.so) ==27495==by 0x4FC16F: ??? (exceptions-amd64.c:838) ==27495==by 0x41A2773: ??? --27495-- Discarding syms at 0xbd031f0-0xbd0b648 in /lib64/libnss_files-2.12.so due to munmap() ==27495== ==27495== HEAP SUMMARY: ==27495== in use at exit: 3,216,798 bytes in 25,274 blocks ==27495== total heap usage: 133,643 allocs, 108,369 frees, 75,932,995 bytes allocated The SIGSEGV not only happen in uv__read. Is this a mistake made by valgrind? And also the boehm seems to have the same problem with sgen. Rodrigo Kumpera wrote That's a false positive. sgen conservatively scans the stack and this does trip valgrind. On Fri, Nov 21, 2014 at 10:29 AM, terender lt; terender@ gt; wrote: There is a memory problem with mono-sgen on linux. I'm using some pinned byte[] buffers in my project, and there's a randomly crash with signal SIGSEGV, it could happen anywhere at anytime. I guess there's some write oprations out of bound in memory, so I use valgrind to check the program. Then I found that a while after the program start within some alloc oprations, valgrind report a problem in sgen that is: ==6504== Thread 1: ==6504== Conditional jump or move depends on uninitialised value(s) ==6504==at 0x5C4D46: conservatively_pin_objects_from (sgen-gc.c:1200) ==6504==by 0x5C5322: scan_thread_data (sgen-gc.c:3778) ==6504==by 0x5CA7BA: collect_nursery (sgen-gc.c:2298) ==6504==by 0x5CB877: sgen_perform_collection (sgen-gc.c:3196) ==6504==by 0x5E8CCF: mono_gc_alloc_obj_nolock (sgen-alloc.c:315) ==6504==by 0x5E90E3: mono_gc_alloc_obj (sgen-alloc.c:491) ==6504==by 0x40C09E2: ??? ==6504==by 0x4198331: ??? ==6504==by 0x40BBF42: ??? ==6504==by 0x41DE33: mono_jit_runtime_invoke (mini.c:6738) ==6504==by 0x5A252A: mono_runtime_invoke (object.c:2831) ==6504==by 0x5A5DCF: mono_runtime_exec_main (object.c:4096) ==6504== Uninitialised value was created by a stack allocation ==6504==at 0x57D2E0: start_wrapper (threads.c:701) Any read or write oprations right after that would trigger an Invalid write/read error in valgrind and then process got killed. Is that a bug in sgen collect_nursery with pinned objects in nursery heap? I have checked on both mono 3.2.3 and 3.10.0, and I'm using tarball to compile them myself. The enviroment is CentOS 6.6 Kernal 2.6.32-358.6.2.el6.x86_64, GCC version 4.4.7 I could upload the whole log of valgrind for both mono 3.2.3 and 3.10.0 if needed. Btw: the problem does not happen if I use boehm -- View this message in context: http://mono.1490590.n4.nabble.com/Problem-with-sgen-tp4664753.html Sent from the Mono - General mailing list archive at Nabble.com.
Re: [Mono-list] Debug.Assert - a cross-platform issue
On Nov 21, 2014, at 7:25 PM, MarLOne infoseeker...@gmail.com wrote:
It will be good if these classes and assemblies from Microsoft open-sources
are incorporated verbatim into Mono to replace its inconsistent code.
This will not be possible, for (at least) three reasons:
1. That code is also shared by Xamarin.Android, Xamarin.iOS, and Xamarin.Mac,
all of which lack System.Configuration.dll, and the .NET DefaultTraceListener
relies upon System.Configuration (via DiagnosticsConfiguration).
2. There are several CAS demands, which don't make sense on Mono.
3. The default code to write messages is useless outside of Windows, as no
other platform has OutputDebugString():
https://github.com/Microsoft/referencesource/blob/9da503f9ef21e8d1f2905c78d4e3e5cbb3d6f85a/System/compmod/system/diagnostics/DefaultTraceListener.cs#L182-191
This doesn't mean that the .NET source can't be taken *and modified* for use
off Windows, but it can't be used as-is.
I have to thank Microsoft to open-source the .Net library allowing me to read
... default values for the System.Diagnostics.DefaultTraceListener.
The default value of property that determines the reaction of Debug.Assert is
set here: assertuienabled
The hilarious thing is that AssertUiEnabled does not alone control actual
runtime behavior!
https://github.com/Microsoft/referencesource/blob/9da503f9ef21e8d1f2905c78d4e3e5cbb3d6f85a/System/compmod/system/diagnostics/DefaultTraceListener.cs#L105-107
The behavior of DefaultTraceListener.Fail() depends on *both*
DefaultTraceListener.AssertUiEnabled *and* DefaultTraceListener.UiPermission,
which is a private property that demands the UIPermissionWindow.SafeSubWindows
CAS permission:
try {
new
UIPermission(UIPermissionWindow.SafeSubWindows).Demand();
return true;
}
catch {
return false;
}
This explains how they can sanely have a non-GUI Windows service use
Debug.Assert() and have it not hang when there's no Window Station: just have
the startup code set security permissions which denies
UIPermissionWindow.SafeSubWindows...
This doesn't at all answer how things should work off Windows. You can
reasonably argue that DefaultTraceListener.AssertUiEnabled should default to
`true` off Windows, even if/when a GUI is never shown, because
DefaultTraceListener.AssertUiEnabled is in fact meaningless (it's not the sole
control over whether a GUI is shown).
Which really means the docs are misleading. :-)
http://msdn.microsoft.com/en-us/library/system.diagnostics.defaulttracelistener.assertuienabled(v=vs.110).aspx
It's entirely possible, as we can now see, for user interface mode to be
enabled, yet still not actually display a GUI when Fail() is invoked. This
possibility is not noted at all in the documentation, afaict.
- Jon
___
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
