Re: [Mono-dev] mono-2.11.4 on Solaris 11.1

2014-01-14 Thread LGL Extern 
I find 3 of my failing tests in the outputs of build systems. They are known 
but not solved. 

And only one of them occurs  sometimes in mac os.

1) MonoTests.System.Globalization.CultureInfoTest.DefaultThreadCurrentCulture : 
  #6

  Expected: 

  But was:  <>

Sometimes the error disappears, if the test is repeated.

 

The build server has problems: disk full, see here:  
http://wrench.mono-project.com/Wrench/WebServices/Download.aspx?workfile_id=2786814

Since 2013/12/09 all  builds for the linux x86/x64 environment are queued.

 

Thanks

 

Andreas

 

Von: Grüninger, Andreas (LGL Extern) 
Gesendet: Montag, 13. Januar 2014 11:18
An: 'Alan'; Andrés G. Aragoneses
Cc: mono-devel-list
Betreff: AW: [Mono-dev] mono-2.11.4 on Solaris 11.1

 

I started with the master and got a lot of sigsegv.

So I tried first an older version and thought the last release of 2.* would be 
good choice.

 

Yesterday  I applied all patches to the master and compiled it.

I have 7  failing tests.

4 of them have the same problem. The return of Culture.InvariantCulture is 
wrong, UseUserOverride is true and should be false.

All other cultures are correct.

Tests in:  mcs/class/corlib/Test/System.Globalization/CultureInfoTest.cs

Source in: mcs/class/corlib/System.Globalization/CultureInfo.cs

 

Any ideas?

 

Andreas

 

Von: mono-devel-list-boun...@lists.ximian.com 
[mailto:mono-devel-list-boun...@lists.ximian.com] Im Auftrag von Alan
Gesendet: Montag, 13. Januar 2014 11:10
An: Andrés G. Aragoneses
Cc: mono-devel-list
Betreff: Re: [Mono-dev] mono-2.11.4 on Solaris 11.1

 

Before submitting pull requests you should check to see if the issue still 
exists in the latest code. Mono 2.11.4 was released about 18 months ago.

 

Alan

 

On 12 January 2014 01:12, "Andrés G. Aragoneses"  wrote:

On 11/01/14 22:00, Grüninger, Andreas (LGL Extern) wrote:
> Hi all
>
>
>
> I compiled mono-2.11.4 on Solaris 11.1 and after excluding some tests
> the other tests succeeded. Only 2 failures. I prepared an upstream
> branch with the patches at
> https://github.com/grueni/mono/commits/upstream-mono-2.11.4.

Why such an old version and not master?



> Should I
> create pull requests?

Yes.


___
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-14 Thread Andrés G. Aragoneses 
Bassam, I bisected it and I think the culprit is in this commit:

https://github.com/mono/mono/commit/a0afa38296b8a3b0382bf34ce777357d2553c0f0

Can you confirm my finding by trying to build the previous commit to
this one?

Thanks

On 14/01/14 02:55, "Andrés G. Aragoneses" wrote:
> I confirm the problem, I also get it in Linux64bits
> 
> On 14/01/14 00:33, Bassam Tabbara wrote:
>> Yes. This is a clean build from mono/master.
>>
>> On Jan 13, 2014, at 3:07 PM, Rodrigo Kumpera > > wrote:
>>
>>> 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 >> > 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  <0x>
>>>   at (wrapper managed-to-native) System.Environment.Exit (int)
>>> <0x>
>>>   at Mono.CSharp.Driver.Main (string[]) <0x002b3>
>>>   at (wrapper runtime-invoke) .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=,
>>> ctx=) + 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

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

2014-01-14 Thread Bassam Tabbara 
I can confirm that the following commit builds fine:

b71c0d6afc85ec1512d89692ca09dfc1692494cd

I also just pulled that latest from master (with Zoltan’s fix) and it builds 
fine.

Thanks for the quick turnaround!
Bassam

On Jan 14, 2014, at 8:04 AM, Andrés G. Aragoneses 
mailto:kno...@gmail.com>> wrote:

Bassam, I bisected it and I think the culprit is in this commit:

https://github.com/mono/mono/commit/a0afa38296b8a3b0382bf34ce777357d2553c0f0

Can you confirm my finding by trying to build the previous commit to
this one?

Thanks

On 14/01/14 02:55, "Andrés G. Aragoneses" wrote:
I confirm the problem, I also get it in Linux64bits

On 14/01/14 00:33, Bassam Tabbara wrote:
Yes. This is a clean build from mono/master.

On Jan 13, 2014, at 3:07 PM, Rodrigo Kumpera mailto:kump...@gmail.com>> wrote:

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 mailto: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  <0x>
 at (wrapper managed-to-native) System.Environment.Exit (int)
   <0x>
 at Mono.CSharp.Driver.Main (string[]) <0x002b3>
 at (wrapper runtime-invoke) .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=,
   ctx=) + 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=,
   log_level=, format=, args=)
   + 161 at goutput.c:175
   frame #7: 0x0001093eef4f
   mono`monoeg_assertion_message(format=) + 143 at
   goutp