[Mono-dev] build error on latest mono from git

[Venkatesh Mahadev]

Hi,

I pulled the latest sources for mono from git, ran autogen.sh and then
make. I am seeing this build error. I've attached the output from make, and
am hoping someone could help me with this error.

[~/Projects/mono] $ uname -a
Linux minchu 3.9.11-200.fc18.x86_64 #1 SMP Mon Jul 22 21:04:50 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux

-Venkatesh


x
Description: Binary data
___
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 OS X Build on Mountain Lion with threads failure [libmonoruntime_la-threads.lo] Error 1

[Michael Franz]

Rodrigo,

I see the page is updated, I cannot tell the difference between the 32 bit
build and the 64 bit build instructions.  I don't think the 64 bit
instructions needed to be changed.  If the --build is specified for the 64
bit, it should be x86_64-apple-darwin11.2.0 .

Michael


On Thu, Aug 8, 2013 at 11:50 AM, Rodrigo Kumpera  wrote:

> The build instructions have been updated.
>
>
> On Wed, Aug 7, 2013 at 9:37 PM, Michael Franz  wrote:
>
>> Zoltan,
>>
>> Your suggestion worked!  Thank you!
>>
>> How do we get the OS X build instructions updated?  This is the page I
>> was working from.  http://mono-project.com/Compiling_Mono_on_OSX
>>
>> Michael
>>
>>
>> On Wed, Aug 7, 2013 at 3:54 AM, Zoltan Varga  wrote:
>>
>>> Hi,
>>>
>>>  Instead of CFLAGS="-m32", try configure --build=i386-apple-darwin11.2.0
>>> or something.
>>>
>>>  Zoltan
>>>
>>>
>>> On Wed, Aug 7, 2013 at 4:13 AM, Michael Franz  wrote:
>>>
  Hi,

 I download the latest tar file 
 (mono-3.2.1.tar.bz2)
  and
 followed the OS X build instructions.  The 32 bit build is failing, similar
 to this old thread
 http://mono.1490590.n4.nabble.com/mono-io-layer-mono-mutex-h-Errors-in-Current-Master-td3515845.html#a3515916.
   The 64 bit build works just fine.  How do I get more details of the
 exact error?

   $ CC='cc -m32' ./configure --prefix=DIR --enable-nls=no
   $ make

 Making all in metadata
   CC   libmonoruntime_la-threads.lo
 make[3]: *** [libmonoruntime_la-threads.lo] Error 1
 make[2]: *** [all-recursive] Error 1
 make[1]: *** [all-recursive] Error 1
 make: *** [all] Error 2

 I have tried 'make V=1', but that just seems to give me the information
 about the command used to build and not the details on the problem.

 My system detail ares:
 mono-3.2.1$ uname -a
 Darwin MacMini.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May  1
 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64

 mono-3.2.1$ gcc --version
 i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
 5658) (LLVM build 2336.11.00)

 Any help is appreciated.

 Michael

 ___
 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] mono-3.2.1 "make check" failures & sgen assertion

[Charles Randall]

Mono developers,

While trying to track down a mono internal problem related to signals and 
garbage collection, I've been doing some testing with the latest 3.2.1 release.

In an attempt to find a test case that's most interesting to this team, I'm 
running OpenSuse 12.3 and repeatedly unpacking 3.2.1, running "configure", 
"make", and "make check". I let this run for ~24 hours which resulted in 58 
builds/checks. Every one failed one test or another in "make check". This is in 
stark contrast to the status reported by monkey wrench for 
"mono-dist-3.2.1-release" on OpenSuse (all green).

I'm new to OpenSuse, but I just did a fresh install and "zypper -n in -t 
pattern devel_C_C++" to get a development environment. Other than that, I'm 
just running the Makefile appended below over and over again.

My system is,

# cat /etc/SuSE-release
openSUSE 12.3 (x86_64)
VERSION = 12.3
CODENAME = Dartmouth
# uname -a
Linux linux-mono.nirvanix.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

The mono I end up with is,

# mono --version
Mono JIT compiler version 3.2.1 (tarball Tue Aug  6 14:43:27 MDT 2013) 
Copyright (C) 2002-2012 Novell, Inc, Xamarin Inc and Contributors. 
www.mono-project.com
TLS:   __thread
SIGSEGV:   altstack
Notifications: epoll
Architecture:  amd64
Disabled:  none
Misc:  softdebug
LLVM:  supported, not enabled.
GC:sgen

Here's a count of the failures from those runs,

 25 bug-10127.exe
 13 gsharing-valuetype-layout.exe
  4 sgen-weakref-stress.exe|ms-par
  3 sgen-weakref-stress.exe|ms-split
  3 sgen-weakref-stress.exe|ms-conc
  2 sgen-weakref-stress.exe|plain
  2 delegate2.exe
  1 sgen-weakref-stress.exe|ms-split-95
  1 sgen-weakref-stress.exe|ms-conc-split
  1 sgen-bridge.exe|ms-split
  1 appdomain-unload.exe

Note that the total number of test failures is greater than the 58 iterations 
because sometimes more than one test failed per iteration. I didn't dig into 
the failures, but note that bug-10127.exe fails on 43% of the runs (25/58).

I'm most interested in assertion failures in the bug-10127.exe failures as they 
look similar to my application failures on another platform. Specifically, 
here's a manual recompile and run of that test (it doesn't fail every time),

# mcs bug-10127.cs
# mono bug-10127.exe
Starting cache testers
* Assertion at sgen-os-posix.c:60, condition `info->doing_handshake' not met ...
=
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.
=

Here are a few examples of the bug-10127.exe failure stack traces from manual 
runs as described above,

http://sprunge.us/iHFX
http://sprunge.us/cOEU
http://sprunge.us/VKRg

For completeness, the only thing that I can think of that may be different 
about my very simple configuration is that my OpenSuse system is a virtual 
machine (4 core, 4 GB RAM) running on VMware ESXi. I suspect that this is 
subtly altering the timing of execution and exposing latent bugs.

These appears to be related,

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

http://stackoverflow.com/questions/17937222/mono-3-2-0-process-crashes-on-sgen-os-posix-info-handshake-not-met

>From what I've described, am I doing anything wrong? Anyone else seeing 
>something similar?

-Charles

--- snip ---
MONO_VER=3.2.1
MONO_DIST=mono-${MONO_VER}.tar.bz2
MONO_DIR=mono-${MONO_VER}

all: check.done

extract.done:
@echo 
@echo EXTRACT
@echo 
tar jxvf ${MONO_DIST} 2>&1
touch extract.done

configure.done: extract.done
@echo 
@echo CONFIGURE
@echo 
(cd ${MONO_DIR} && ./configure --prefix=/tmp/mono) 2>&1
touch configure.done

build.done: configure.done
@echo 
@echo BUILD
@echo 
make -C ${MONO_DIR} -j 4 2>&1
touch build.done

check.done: build.done
@echo 
@echo CHECK
@echo 
make -C ${MONO_DIR} check 2>&1
touch check.done

.PHONY: clean
clean:
@echo 
@echo CLEAN
@echo 
-rm -f

Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on linux

[Nikita Tsukanov]

I'm unable to reproduce the issue with HttpListener/Sockets alone. It needs
INancyEngine.ProcessReqiest() somewhere in request processing pipeline. So
I'm still investigating, what conditions are needed to repoduce the bug
(and I suspect that it doesn't have to do with I/O at all, since it
reproduces even with my hand-made send/recv sockets backend).


2013/8/7 "Andrés G. Aragoneses" 

> If you're able to reproduce it with 3.3 and not with 2.10.x, you should
> definitely open a bug report for it in http://bugzilla.xamarin.com/stating 
> "[regression]" in the bug summary.
>
> Also, I would open a separate bug report for the segfault you're getting
> when running with MONO_DISABLE_AIO (pasting the backtrace of the segfault,
> with debug symbols installed).
>
>
> On 07/08/13 14:02, Alfred Hall wrote:
>
>> Tried running it with sgen or boehm on 2.10? Worth trying both I think.
>> Also how about 3.3 (master) ?
>>
>> -Original message-
>> *From:* Nikita Tsukanov 
>> *Sent:* Wednesday 7th August 2013 12:54
>> *To:* 
>> mono-devel-list@lists.ximian.**com
>> *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener)
>>
>> locking up on linux
>>
>> I've rewritten my SCGI server to work with TPL directly instead of
>> using async/await to make it run on mono 2.10. Then I've tried to
>> run it with mono 2.10.8.1 and mono 3.2 with System.Net.Sockets
>> backend and to hammer it with jmeter. 500K requests without any
>> lockups on Mono 2.10, lockup at 22164th request on mono 3.2.
>>
>> Server source code is still on GitHub -
>> 
>> https://github.com/kekekeks/**scgi-sharp
>>
>>
>> 2013/8/7 Greg Young > >
>>
>>
>> I believe attaching a debugger changes things like optimizations
>> from occurring (not positive but it does in clr)
>>
>>
>> On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
>>
>> Huh, it doesn't require debugger to be _attched_, just
>> debugging subsystem initialized i. e. if I launch this
>> program as a "debugger" it doesn't lock up.
>>
>> publicstaticvoidMain(string[]**args)
>> {
>> intport=27042;
>> if(args.Length !=0)
>> port=int.Parse(args[0]);
>> while(true)
>> {
>> varvm= Mono.Debugger.Soft.**VirtualMachineManager.Listen(**
>> newIPEndPoint(IPAddress.**Loopback,port));
>> vm.Resume();
>> vm.Detach();
>> }
>> }
>>
>> I'll use running with
>> --debugger-agent=transport=dt_**socket,address=
>> 127.0.0.1:27042
>>  as a temporary workaround since
>>
>> performance doesn't degrade a lot.
>>
>>
>> 2013/8/7 Nikita Tsukanov 
>>
>> I suspect that the problem is actually with thread pool
>> itself. I've created socket layer implementation using
>> libevent (wrapped with Oars) and send/recv that utilizes
>> thread pool for cases when it's unable to complete
>> operation synchronously. It survives longer, but still
>> locks up after a while. Same behavior with debugger -
>> I'm unable to reproduce the issue when running under it.
>> I also unable to grab thread stack traces, it prints
>> "Full thread dump: " and nothing else.
>>
>>
>> 2013/8/7 Greg Young 
>>
>> We will see your test then as it will probably
>> affect us as well
>>
>>
>> On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
>>
>> Greg, I've tried running my server with mono
>> compiled from master (with pull request #703
>> merged in), still freezes after a while.
>>
>>
>> 2013/8/7 Greg Young 
>>
>> Do you have our pull req? We are stable
>> after (and seriously read history of this
>> list)
>>
>>
>> On Tuesday, August 6, 2013, Nikita Tsukanov
>> wrote:
>>
>> 
>> https://github.com/kekekeks/**scgi-sharp-
>> here is my SCGI server with host for
>> NancyFx. If you run Sandbox.exe with
>> --echo-server it will not use nancy
>> infrastructure and will respond
>> directly. It locks up after several
>> thousands of requests under jmeter.
>>
>> Simple nginx configuration:
>>
>> location 

Re: [Mono-dev] Mono 3.2.1 OS X Build on Mountain Lion with threads failure [libmonoruntime_la-threads.lo] Error 1

[Rodrigo Kumpera]

The build instructions have been updated.


On Wed, Aug 7, 2013 at 9:37 PM, Michael Franz  wrote:

> Zoltan,
>
> Your suggestion worked!  Thank you!
>
> How do we get the OS X build instructions updated?  This is the page I was
> working from.  http://mono-project.com/Compiling_Mono_on_OSX
>
> Michael
>
>
> On Wed, Aug 7, 2013 at 3:54 AM, Zoltan Varga  wrote:
>
>> Hi,
>>
>>  Instead of CFLAGS="-m32", try configure --build=i386-apple-darwin11.2.0
>> or something.
>>
>>  Zoltan
>>
>>
>> On Wed, Aug 7, 2013 at 4:13 AM, Michael Franz  wrote:
>>
>>>  Hi,
>>>
>>> I download the latest tar file 
>>> (mono-3.2.1.tar.bz2)
>>>  and
>>> followed the OS X build instructions.  The 32 bit build is failing, similar
>>> to this old thread
>>> http://mono.1490590.n4.nabble.com/mono-io-layer-mono-mutex-h-Errors-in-Current-Master-td3515845.html#a3515916.
>>>   The 64 bit build works just fine.  How do I get more details of the
>>> exact error?
>>>
>>>   $ CC='cc -m32' ./configure --prefix=DIR --enable-nls=no
>>>   $ make
>>>
>>> Making all in metadata
>>>   CC   libmonoruntime_la-threads.lo
>>> make[3]: *** [libmonoruntime_la-threads.lo] Error 1
>>> make[2]: *** [all-recursive] Error 1
>>> make[1]: *** [all-recursive] Error 1
>>> make: *** [all] Error 2
>>>
>>> I have tried 'make V=1', but that just seems to give me the information
>>> about the command used to build and not the details on the problem.
>>>
>>> My system detail ares:
>>> mono-3.2.1$ uname -a
>>> Darwin MacMini.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May  1
>>> 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64
>>>
>>> mono-3.2.1$ gcc --version
>>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
>>> 5658) (LLVM build 2336.11.00)
>>>
>>> Any help is appreciated.
>>>
>>> Michael
>>>
>>> ___
>>> 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] NancyFX self hosting (HttpListener) locking up on linux

[Alfred Hall]

Nikita: Have you filed a bug for this yet? If so please give me the bug number 
so I can follow it.


-Original message-
> From:"Andrés G. Aragoneses"   >
> Sent: Wednesday 7th August 2013 13:15
> To: mono-devel-list@lists.ximian.com 
>  
> Subject: Re: [Mono-dev] NancyFX self hosting (HttpListener) locking up on 
> linux
> 
> If you're able to reproduce it with 3.3 and not with 2.10.x, you should 
> definitely open a bug report for it in http://bugzilla.xamarin.com 
>  / 
> stating "[regression]" in the bug summary.
> 
> Also, I would open a separate bug report for the segfault you're getting 
> when running with MONO_DISABLE_AIO (pasting the backtrace of the 
> segfault, with debug symbols installed).
> 
> On 07/08/13 14:02, Alfred Hall wrote:
> > Tried running it with sgen or boehm on 2.10? Worth trying both I think.
> > Also how about 3.3 (master) ?
> >
> > -Original message-
> > *From:* Nikita Tsukanov mailto:kek...@gmail.com> >
> > *Sent:* Wednesday 7th August 2013 12:54
> > *To:* mono-devel-list@lists.ximian.com 
> >  
> > *Subject:* Re: [Mono-dev] NancyFX self hosting (HttpListener)
> > locking up on linux
> >
> > I've rewritten my SCGI server to work with TPL directly instead of
> > using async/await to make it run on mono 2.10. Then I've tried to
> > run it with mono 2.10.8.1 and mono 3.2 with System.Net.Sockets
> > backend and to hammer it with jmeter. 500K requests without any
> > lockups on Mono 2.10, lockup at 22164th request on mono 3.2.
> >
> > Server source code is still on GitHub -
> > https://github.com/kekekeks/scgi-sharp
> >
> >
> > 2013/8/7 Greg Young  >  
> >  >>
> >
> > I believe attaching a debugger changes things like optimizations
> > from occurring (not positive but it does in clr)
> >
> >
> > On Wednesday, August 7, 2013, Nikita Tsukanov wrote:
> >
> > Huh, it doesn't require debugger to be _attched_, just
> > debugging subsystem initialized i. e. if I launch this
> > program as a "debugger" it doesn't lock up.
> >
> > publicstaticvoidMain(string[]args)
> > {
> > intport=27042;
> > if(args.Length !=0)
> > port=int.Parse(args[0]);
> > while(true)
> > {
> > varvm= 
> > Mono.Debugger.Soft.VirtualMachineManager.Listen(newIPEndPoint(IPAddress.Loopback,port));
> > vm.Resume();
> > vm.Detach();
> > }
> > }
> >
> > I'll use running with
> > --debugger-agent=transport=dt_socket,address=127.0.0.1:27042
> >  as a temporary workaround since
> > performance doesn't degrade a lot.
> >
> >
> > 2013/8/7 Nikita Tsukanov  >  >
> >
> > I suspect that the problem is actually with thread pool
> > itself. I've created socket layer implementation using
> > libevent (wrapped with Oars) and send/recv that utilizes
> > thread pool for cases when it's unable to complete
> > operation synchronously. It survives longer, but still
> > locks up after a while. Same behavior with debugger -
> > I'm unable to reproduce the issue when running under it.
> > I also unable to grab thread stack traces, it prints
> > "Full thread dump: " and nothing else.
> >
> >
> > 2013/8/7 Greg Young  >  >
> >
> > We will see your test then as it will probably
> > affect us as well
> >
> >
> > On Tuesday, August 6, 2013, Nikita Tsukanov wrote:
> >
> > Greg, I've tried running my server with mono
> > compiled from master (with pull request #703
> > merged in), still freezes after a while.
> >
> >
> > 2013/8/7 Greg Young  >  >
> >
> > Do you have our pull req? We are stable
> > after (and seriously read history of this list)
> >
> >
> > On Tuesday, August 6, 2013, Nikita Tsukanov
> > wrote:
> >
> > https://github.com/kekekeks/scgi-sharp -
> > here is my SCGI server with host for
> > NancyFx. If you run Sandbox.exe with
> > --echo-server it will not use nancy
> > infrastructure and wil