Re: [Mono-dev] Array.Copy endian issue?

[Bassam Tabbara]

A little more details. If I remove the FastCopy call in Array.Copy I am unable 
to reproduce this.

// if (FastCopy (sourceArray, sourceIndex, 
destinationArray, destinationIndex, length))
//   return;

Attached is a test case but it needs to be run on a ARM device with the same 
version of Linux. Happy to provide access to a box if needed.

I’ll open a Xamarin bug too.



Thanks!
Bassam

On Jan 29, 2014, at 3:53 PM, Bassam Tabbara  wrote:

> Hello,
>
> I’m chasing a bug while parsing the machine.config XML file, and I’ve 
> narrowed it down to Array.Copy performing the wrong copy. Here’s an example:
>
> before copy ' after copy '< edcsirt'
>
> The buffer is altered after its copied. This seems to happen only on newer 
> versions of linux (3.4.6) on an armv5tel device. When running linux 2.6 I 
> don’t see this.
>
> Any thoughts on what might be causing this?
>
> Thanks!
> Bassam
> ___
> Mono-devel-list mailing list
> Mono-devel-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list



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

[Mono-dev] Array.Copy endian issue?

[Bassam Tabbara]

Hello,

I’m chasing a bug while parsing the machine.config XML file, and I’ve narrowed 
it down to Array.Copy performing the wrong copy. Here’s an example:

before copy 'http://lists.ximian.com/mailman/listinfo/mono-devel-list

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

[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

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

[Bassam Tabbara]

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 goutput.c:195
frame #8: 0x000109365524 mono`mono_gc_cleanup + 260 at gc.c:1216
frame #9: 0x00010935bc1e 
mono`mono_runtime_cleanup(domain=) + 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=, obj=0x, 
params=, exc=) + 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=0x7fb0705025b

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

[Bassam Tabbara]

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 goutput.c:195
frame #8: 0x000109365524 mono`mono_gc_cleanup + 260 at gc.c:1216
frame #9: 0x00010935bc1e 
mono`mono_runtime_cleanup(domain=) + 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=, obj=0x, 
params=, exc=) + 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=, 
exc=0x) + 374 at object.c:4053
frame #16: 0x0001092358d9 mono`mono_main [inlined] main_thread_handler 
+ 6121 at driver.c:1066
frame #17: 0x0001092358a2 mono`mono_main(argc=24, argv=) + 
6066 at driver.c:2014
frame #18: 0x0001091cc6ec mono`main [inlined] 
mono_main_with_options(argv=, argc=) + 549 at 
main.c:98
frame #19: 0x0001091cc4c7 mono`ma

Re: [Mono-dev] Help w/ deadlock on shutdown

[Bassam Tabbara]

Jonathan, thanks for the info.

The native thread (#4) does not know about mono nor is it linked with the mono 
libraries, it would be hard to call mono_thread_detach from it. Is there a 
different solution to this?

Out of curiosity why does mono not detach a thread once a managed call is 
complete from a native thread.

On Dec 13, 2013, at 12:55 PM, Jonathan Chambers 
mailto:jonc...@gmail.com>> wrote:

If the native thread calls into managed code it is automatically 'attached' to 
the mono runtime and the gc for tracking. It does not automatically unattached 
upon return of the call into managed code. Then at shutdown the native thread 
is part of the list of threads that are expected to exit before the runtime can 
shut down properly.

Try to call mono_thread_detach() in thread #4 before entering the wait for 
shutdown.

- Jonathan


On Fri, Dec 13, 2013 at 1:09 PM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
Hello,

I’m seeing a deadlock on shutdown of latest mono form master when using our own 
native background thread. Here are backtraces:

* thread #1: tid = 0xd83c3, 0x7fff91412716 
libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread, 
stop reason = signal SIGSTOP
frame #0: 0x7fff91412716 libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x7fff86b20c3b libsystem_pthread.dylib`_pthread_cond_wait + 
727
frame #2: 0x00010919a892 
mono`_wapi_handle_timedwait_signal_handle(handle=, 
timeout=, alertable=1, poll=) + 514 at handles.c:1588
frame #3: 0x0001091ab95b mono`WaitForMultipleObjectsEx(numobjects=7, 
handles=0x7fff56c6f2f0, waitall=1, timeout=4294967295, alertable=1) + 1419 
at wait.c:668
frame #4: 0x000109112a2f mono`wait_for_tids(wait=0x7fff56c6f2f0, 
timeout=) + 47 at threads.c:2809
frame #5: 0x000109112626 mono`mono_thread_manage + 694 at threads.c:3095
frame #6: 0x000108ffc9fd mono`mono_main(argc=11, argv=) + 
6301 at driver.c:2015
frame #7: 0x000108f92a0c mono`main [inlined] 
mono_main_with_options(argv=, argc=) + 549 at 
main.c:98
frame #8: 0x000108f927e7 mono`main(argc=, 
argv=) + 39 at main.c:133
frame #9: 0x7fff8d7875fd libdyld.dylib`start + 1

  thread #2: tid = 0xd83c5, 0x7fff9140ea56 
libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #0: 0x7fff9140ea56 libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #1: 0x0001091b8d38 mono`mono_sem_wait(sem=0x00010930ad78, 
alertable=) + 24 at mono-semaphore.c:121
frame #2: 0x000109136017 mono`finalizer_thread(unused=) + 
103 at gc.c:1073
frame #3: 0x00010910d743 mono`start_wrapper [inlined] 
start_wrapper_internal + 456 at threads.c:609
frame #4: 0x00010910d57b mono`start_wrapper(data=) + 43 at 
threads.c:654
frame #5: 0x0001091acd50 
mono`thread_start_routine(args=0x7f930981cbf8) + 144 at wthreads.c:294
frame #6: 0x0001091bdffa mono`inner_start_thread(arg=) + 
58 at mono-threads-posix.c:49
frame #7: 0x7fff86b1e899 libsystem_pthread.dylib`_pthread_body + 138
frame #8: 0x7fff86b1e72a libsystem_pthread.dylib`_pthread_start + 137
frame #9: 0x7fff86b22fc9 libsystem_pthread.dylib`thread_start + 13

  thread #3: tid = 0xd83c9, 0x7fff91413662 libsystem_kernel.dylib`kevent64 
+ 10, queue = 'com.apple.libdispatch-manager
frame #0: 0x7fff91413662 libsystem_kernel.dylib`kevent64 + 10
frame #1: 0x7fff8e0ac43d libdispatch.dylib`_dispatch_mgr_invoke + 239
frame #2: 0x7fff8e0ac152 libdispatch.dylib`_dispatch_mgr_thread + 52

  thread #4: tid = 0xda1fc, 0x7fff9141364a libsystem_kernel.dylib`kevent + 
10
frame #0: 0x7fff9141364a libsystem_kernel.dylib`kevent + 10
frame #1: 0x00010fa22712 
libsymformutp.dylib`kq_dispatch(base=0x7f930b564890, tv=) + 
706 at kqueue.c:301
frame #2: 0x00010fa17429 
libsymformutp.dylib`event_base_loop(base=0x7f930b564890, 
flags=) + 873 at event.c:1826
frame #3: 0x00010f9fe657 
libsymformutp.dylib`UTPEvents::Run(e=0x7f930b566180) + 23 at 
utp_event.cpp:81
frame #4: 0x7fff86b1e899 libsystem_pthread.dylib`_pthread_body + 138
frame #5: 0x7fff86b1e72a libsystem_pthread.dylib`_pthread_start + 137
frame #6: 0x7fff86b22fc9 libsystem_pthread.dylib`thread_start + 13

thread #4 is out native thread that will be shutdown when a managed SafeHandle 
is released. This thread is likely to have called managed code at some point. 
thread #1 seems to be waiting on all threads to exit including thread #4, but 
until finalization is complete on thread #2 this is not going to happen, and 
hence the deadlock.

Does this seem likely? Why does mono runtime wait for threads to exit that it 
did not create? Should finalization happen before waiting for all threads to 
exit?

Thanks in advance for the help.
Bassam
___
Mono-devel-list mailing list
Mono-devel-list@lists.x

[Mono-dev] Help w/ deadlock on shutdown

[Bassam Tabbara]

Hello,

I’m seeing a deadlock on shutdown of latest mono form master when using our own 
native background thread. Here are backtraces:

* thread #1: tid = 0xd83c3, 0x7fff91412716 
libsystem_kernel.dylib`__psynch_cvwait + 10, queue = 'com.apple.main-thread, 
stop reason = signal SIGSTOP
frame #0: 0x7fff91412716 libsystem_kernel.dylib`__psynch_cvwait + 10
frame #1: 0x7fff86b20c3b libsystem_pthread.dylib`_pthread_cond_wait + 
727
frame #2: 0x00010919a892 
mono`_wapi_handle_timedwait_signal_handle(handle=, 
timeout=, alertable=1, poll=) + 514 at handles.c:1588
frame #3: 0x0001091ab95b mono`WaitForMultipleObjectsEx(numobjects=7, 
handles=0x7fff56c6f2f0, waitall=1, timeout=4294967295, alertable=1) + 1419 
at wait.c:668
frame #4: 0x000109112a2f mono`wait_for_tids(wait=0x7fff56c6f2f0, 
timeout=) + 47 at threads.c:2809
frame #5: 0x000109112626 mono`mono_thread_manage + 694 at threads.c:3095
frame #6: 0x000108ffc9fd mono`mono_main(argc=11, argv=) + 
6301 at driver.c:2015
frame #7: 0x000108f92a0c mono`main [inlined] 
mono_main_with_options(argv=, argc=) + 549 at 
main.c:98
frame #8: 0x000108f927e7 mono`main(argc=, 
argv=) + 39 at main.c:133
frame #9: 0x7fff8d7875fd libdyld.dylib`start + 1

  thread #2: tid = 0xd83c5, 0x7fff9140ea56 
libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #0: 0x7fff9140ea56 libsystem_kernel.dylib`semaphore_wait_trap + 10
frame #1: 0x0001091b8d38 mono`mono_sem_wait(sem=0x00010930ad78, 
alertable=) + 24 at mono-semaphore.c:121
frame #2: 0x000109136017 mono`finalizer_thread(unused=) + 
103 at gc.c:1073
frame #3: 0x00010910d743 mono`start_wrapper [inlined] 
start_wrapper_internal + 456 at threads.c:609
frame #4: 0x00010910d57b mono`start_wrapper(data=) + 43 at 
threads.c:654
frame #5: 0x0001091acd50 
mono`thread_start_routine(args=0x7f930981cbf8) + 144 at wthreads.c:294
frame #6: 0x0001091bdffa mono`inner_start_thread(arg=) + 
58 at mono-threads-posix.c:49
frame #7: 0x7fff86b1e899 libsystem_pthread.dylib`_pthread_body + 138
frame #8: 0x7fff86b1e72a libsystem_pthread.dylib`_pthread_start + 137
frame #9: 0x7fff86b22fc9 libsystem_pthread.dylib`thread_start + 13

  thread #3: tid = 0xd83c9, 0x7fff91413662 libsystem_kernel.dylib`kevent64 
+ 10, queue = 'com.apple.libdispatch-manager
frame #0: 0x7fff91413662 libsystem_kernel.dylib`kevent64 + 10
frame #1: 0x7fff8e0ac43d libdispatch.dylib`_dispatch_mgr_invoke + 239
frame #2: 0x7fff8e0ac152 libdispatch.dylib`_dispatch_mgr_thread + 52

  thread #4: tid = 0xda1fc, 0x7fff9141364a libsystem_kernel.dylib`kevent + 
10
frame #0: 0x7fff9141364a libsystem_kernel.dylib`kevent + 10
frame #1: 0x00010fa22712 
libsymformutp.dylib`kq_dispatch(base=0x7f930b564890, tv=) + 
706 at kqueue.c:301
frame #2: 0x00010fa17429 
libsymformutp.dylib`event_base_loop(base=0x7f930b564890, 
flags=) + 873 at event.c:1826
frame #3: 0x00010f9fe657 
libsymformutp.dylib`UTPEvents::Run(e=0x7f930b566180) + 23 at 
utp_event.cpp:81
frame #4: 0x7fff86b1e899 libsystem_pthread.dylib`_pthread_body + 138
frame #5: 0x7fff86b1e72a libsystem_pthread.dylib`_pthread_start + 137
frame #6: 0x7fff86b22fc9 libsystem_pthread.dylib`thread_start + 13

thread #4 is out native thread that will be shutdown when a managed SafeHandle 
is released. This thread is likely to have called managed code at some point. 
thread #1 seems to be waiting on all threads to exit including thread #4, but 
until finalization is complete on thread #2 this is not going to happen, and 
hence the deadlock.

Does this seem likely? Why does mono runtime wait for threads to exit that it 
did not create? Should finalization happen before waiting for all threads to 
exit?

Thanks in advance for the help.
Bassam
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list

Re: [Mono-dev] Compiling for i586 Linux target on an i686 Linux machine

[Bassam Tabbara]

Chris,

Try:

./configure --host=i585-unknown-linux-gnu

Thanks!
Bassam

On Sep 16, 2013, at 2:49 PM, Chris Tacke 
mailto:cta...@opennetcf.com>> wrote:

I need to get a 32-bit i586 build of the latest version of Mono to run on an 
embedded target.

For a build machine I’m using Ubuntu 12 on 32-bit i686 VM.

I have successfully pulled the Mono sources and built them using the default 
configuration, and the resulting Mono binaries work just fine ion an i686 
machine.  When I attempt to run on an i586 machine, I get an error that simply 
says “Illegal instruction”

I assume that I need to cross-compile for i586, but I can’t find a --target 
setting that works

I’ve tried a few things:

./configure --target=i586
./configure --target=i586-linux
./configure --target=i586-linux-gcc

And I always get an error along these lines (the target name changes with what 
I send in):

Configure: error: Cross compiling is not supported for target i586-pc-linux-gcc

Is there a known-good –target flag that I can send in to get a cross-compiled 
i586 output?


-Chris

___
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] _wapi_connect errors

[Bassam Tabbara]

Who is the appropriate contact for this one? Gonzalo?

On Sep 11, 2013, at 5:19 PM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:

Hello,

We're seeing these errors frequently as part of our application:


_wapi_connect: error looking up socket handle 0x3fd
_wapi_connect: error looking up socket handle 0x6db
_wapi_connect: error looking up socket handle 0x25f
_wapi_connect: error looking up socket handle 0x413
_wapi_connect: error looking up socket handle 0x314
_wapi_connect: error looking up socket handle 0x2d
_wapi_connect: error looking up socket handle 0x395
_wapi_connect: error looking up socket handle 0x2b3
_wapi_connect: error looking up socket handle 0x1fb
_wapi_connect: error looking up socket handle 0x2fd (error 10038)
_wapi_connect: error looking up socket handle 0x2ab (error 10038)
_wapi_connect: error looking up socket handle 0x27c
_wapi_connect: error looking up socket handle 0x1de (error 10038)
_wapi_connect: error looking up socket handle 0x2c4 (error 10038)
_wapi_connect: error looking up socket handle 0x235 (error 10038)

In code they are marked as warnings. These all look like race conditions where 
one thread closes a socket while another is trying to do some work on it. 
Should I be concerned about these? If not should these logs be silenced?

Thanks!
Bassam
___
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

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

[Mono-dev] _wapi_connect errors

[Bassam Tabbara]

Hello,

We're seeing these errors frequently as part of our application:


_wapi_connect: error looking up socket handle 0x3fd
_wapi_connect: error looking up socket handle 0x6db
_wapi_connect: error looking up socket handle 0x25f
_wapi_connect: error looking up socket handle 0x413
_wapi_connect: error looking up socket handle 0x314
_wapi_connect: error looking up socket handle 0x2d
_wapi_connect: error looking up socket handle 0x395
_wapi_connect: error looking up socket handle 0x2b3
_wapi_connect: error looking up socket handle 0x1fb
_wapi_connect: error looking up socket handle 0x2fd (error 10038)
_wapi_connect: error looking up socket handle 0x2ab (error 10038)
_wapi_connect: error looking up socket handle 0x27c
_wapi_connect: error looking up socket handle 0x1de (error 10038)
_wapi_connect: error looking up socket handle 0x2c4 (error 10038)
_wapi_connect: error looking up socket handle 0x235 (error 10038)

In code they are marked as warnings. These all look like race conditions where 
one thread closes a socket while another is trying to do some work on it. 
Should I be concerned about these? If not should these logs be silenced?

Thanks!
Bassam
___
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

[Bassam Tabbara]

Should it be a warning then? The runtime aborts after this error. The only 
workaround I've found so far is:

https://github.com/symform/mono/commit/fe5c582a1a2d241f368c86081b3cb7ea53994f51

And sgen is running well now with a cross compiled mono.

From: Rodrigo Kumpera mailto:kump...@gmail.com>>
Date: Tuesday, August 27, 2013 8:58 AM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] SGEN support when cross compiling

All this means is that the managed allocators won't be used.


On Mon, Aug 26, 2013 at 8:07 PM, Bassam Tabbara 
mailto: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 mailto:kump...@gmail.com>>
Date: Monday, August 26, 2013 5:01 PM

To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto: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 
mailto: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 mailto:kump...@gmail.com>>
Date: Monday, August 26, 2013 4:30 PM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto: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 
mailto: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<mailto: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

[Bassam Tabbara]

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 mailto:kump...@gmail.com>>
Date: Monday, August 26, 2013 5:01 PM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto: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 
mailto: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 mailto:kump...@gmail.com>>
Date: Monday, August 26, 2013 4:30 PM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto: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 
mailto: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<mailto: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

[Bassam Tabbara]

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 mailto:kump...@gmail.com>>
Date: Monday, August 26, 2013 4:30 PM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto: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 
mailto: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<mailto: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] SGEN support when cross compiling

[Bassam Tabbara]

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

Re: [Mono-dev] Non-sensical stack trace (possible issue with generic sharing?)

[Bassam Tabbara]

I don’t see this problem when running with –O=-gshared. The application seems 
to runs slower however. Is there any other information I can provide to help 
resolve this? It only seems to be happening on ARM for me.

From: Zoltan Varga mailto:var...@gmail.com>>
Date: Wednesday, August 14, 2013 4:54 PM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Non-sensical stack trace (possible issue with generic 
sharing?)

Hi,

  Try running with -O=-gshared to see whenever this is a generic sharing 
problem. The stack trace might be missing the List.Add () method for some 
reason.

  Zoltan


On Thu, Aug 15, 2013 at 1:29 AM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
On an armv5tel with latest mono from master I see the following exception 
frequently in our automated test runs:

System.ArgumentOutOfRangeException: Value has to be >= 0.
Parameter name: destinationIndex
  at System.Array.Copy (System.Array sourceArray, Int32 sourceIndex, 
System.Array destinationArray, Int32 destinationIndex, Int32 length) [0x00207] 
in /root/build-thirdparty/mono/mcs/class/corlib/System/Array.cs:1016
  at 
System.Collections.Generic.List`1[Symform.Control.Common.Placement.NodeEndPoint].CopyTo
 (Symform.Control.Common.Placement.NodeEndPoint[] array, Int32 arrayIndex) 
[0x0] in 
/root/build-thirdparty/mono/mcs/class/corlib/System.Collections.Generic/List.cs:203
  at Newtonsoft.Json.Utilities.CollectionWrapper`1[System.Object].Add 
(System.Object item) [0x0] in :0
  at 
Newtonsoft.Json.Utilities.CollectionWrapper`1[System.Object].System.Collections.IList.Add
 (System.Object value) [0x0] in :0
  at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateList 
(IWrappedCollection wrappedList, Newtonsoft.Json.JsonReader reader, 
Newtonsoft.Json.Serialization.JsonArrayContract contract, 
Newtonsoft.Json.Serialization.JsonProperty containerProperty, System.String id) 
[0x0] in :0

Whats odd about this stack trace is that 
JsonSerializeInternalReader.PopulateList does not call CollectionWrapper`1.Add, 
nor does Add call List`1.CopyTo. See 
http://json.codeplex.com/SourceControl/latest#trunk/Src/Newtonsoft.Json/Utilities/CollectionWrapper.cs.

Is it possible that the stack trace is mangled, or is this a generic sharing 
problem?

Note I do not see this issue on x86 or amd64, and did not see this with 
mono-2-10 on all platforms.

Thanks!
Bassam

___
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


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

[Mono-dev] Non-sensical stack trace (possible issue with generic sharing?)

[Bassam Tabbara]

On an armv5tel with latest mono from master I see the following exception 
frequently in our automated test runs:

System.ArgumentOutOfRangeException: Value has to be >= 0.
Parameter name: destinationIndex
  at System.Array.Copy (System.Array sourceArray, Int32 sourceIndex, 
System.Array destinationArray, Int32 destinationIndex, Int32 length) [0x00207] 
in /root/build-thirdparty/mono/mcs/class/corlib/System/Array.cs:1016
  at 
System.Collections.Generic.List`1[Symform.Control.Common.Placement.NodeEndPoint].CopyTo
 (Symform.Control.Common.Placement.NodeEndPoint[] array, Int32 arrayIndex) 
[0x0] in 
/root/build-thirdparty/mono/mcs/class/corlib/System.Collections.Generic/List.cs:203
  at Newtonsoft.Json.Utilities.CollectionWrapper`1[System.Object].Add 
(System.Object item) [0x0] in :0
  at 
Newtonsoft.Json.Utilities.CollectionWrapper`1[System.Object].System.Collections.IList.Add
 (System.Object value) [0x0] in :0
  at Newtonsoft.Json.Serialization.JsonSerializerInternalReader.PopulateList 
(IWrappedCollection wrappedList, Newtonsoft.Json.JsonReader reader, 
Newtonsoft.Json.Serialization.JsonArrayContract contract, 
Newtonsoft.Json.Serialization.JsonProperty containerProperty, System.String id) 
[0x0] in :0

Whats odd about this stack trace is that 
JsonSerializeInternalReader.PopulateList does not call CollectionWrapper`1.Add, 
nor does Add call List`1.CopyTo. See 
http://json.codeplex.com/SourceControl/latest#trunk/Src/Newtonsoft.Json/Utilities/CollectionWrapper.cs.

Is it possible that the stack trace is mangled, or is this a generic sharing 
problem?

Note I do not see this issue on x86 or amd64, and did not see this with 
mono-2-10 on all platforms.

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

Re: [Mono-dev] Assert in mini-arm.c

[Bassam Tabbara]

If I disable the assert the application continues to work and completes:

https://github.com/symform/mono/commit/859aa7fcd0fcb9017f45d8bfb59cfe8907f413d3

If I understand things correctly if the patching fails on the call-site the 
trampoline will remain in place and the code will have to get JITed again on 
the next invocation. This seems like a better outcome than asserting.

Does this seem like a reasonable workaround until you find the root cause here?

From: Bassam Tabbara mailto:bas...@symform.com>>
Date: Wednesday, August 14, 2013 1:07 PM
To: Zoltan Varga mailto:var...@gmail.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Assert in mini-arm.c

I tried increasing MIN_PAGES in mono-codeman.c to 32 and still didn't help.

Is there another workaround that could help here?

From: Bassam Tabbara mailto:bas...@symform.com>>
Date: Wednesday, August 14, 2013 12:26 AM
To: Zoltan Varga mailto:var...@gmail.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Assert in mini-arm.c

Here it is. Note that this run was compiled with BIND_ROOM set to 4 as you 
recommended.

#2  0x00172c44 in arm_patch (code=0x407b05c8 
"\357\376\377\353\367\377\377\352\340A-\351\004\320M\342",  target=0x5da1ebe0 
"\r\300\240\341\360_-\351(\320M\342$\311\377\353") at mini-arm.c:3530

(gdb) x/10i code
   0x407b05c8:  bl  0x407b018c
   0x407b05cc:  b   0x407b05b0
   0x407b05d0:  push{r5, r6, r7, r8, lr}
   0x407b05d4:  sub sp, sp, #4
   0x407b05d8:  mov r5, r0
   0x407b05dc:  mov r6, r1
   0x407b05e0:  mov r7, r2
   0x407b05e4:  orr r0, r5, r6
   0x407b05e8:  and r0, r0, #3
   0x407b05ec:  cmp r0, #0

(gdb) x/10i target
   0x5da1ebe0:  mov r12, sp
   0x5da1ebe4:  push{r4, r5, r6, r7, r8, r9, r10, r11, r12, lr}
   0x5da1ebe8:  sub sp, sp, #40 ; 0x28
   0x5da1ebec:  bl  0x5da11084
   0x5da1ebf0:  add r1, sp, #0
   0x5da1ebf4:  str r0, [r1, #4]
   0x5da1ebf8:  ldr r12, [r0]
   0x5da1ebfc:  str r12, [r1]
   0x5da1ec00:  str r1, [r0]
   0x5da1ec04:  str sp, [r1, #12]

Let me know if there is anything else I can provide.

From: Zoltan Varga mailto:var...@gmail.com>>
Date: Tuesday, August 13, 2013 5:15 PM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Assert in mini-arm.c

I meant frame #2, i.e.
#2  0x00172ca8 in arm_patch

  Zoltan


On Wed, Aug 14, 2013 at 2:14 AM, Zoltan Varga 
mailto:var...@gmail.com>> wrote:
Hi,

Can you see whats at 'code' and 'target' at frame #3, i.e.
x/10i code
x/10i target

 Zoltan


On Wed, Aug 14, 2013 at 1:48 AM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
Unfortunately that did not help. Still seeing the problem. I'm still working on 
a test case but I'm not having much luck so far in getting an isolated repro.

I was able to get a debugger attached to the process right when handle_thunk 
asserts, and there were 6 threads with the following call stack:

Thread 5 (Thread 0x558ff460 (LWP 9201)):
#0  handle_thunk (method=0x0, domain=0x4ce44e58, absolute=1, code=0x427f8f08 
"Q\364\377\353\367\377\377\352",
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353", 
dyn_code_mp=0x0) at mini-arm.c:3373
#1  0x00172764 in arm_patch_general (method=0x0, domain=0x0, code=0x427f8f08 
"Q\364\377\353\367\377\377\352",
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353", 
dyn_code_mp=0x0) at mini-arm.c:3425
#2  0x00172ca8 in arm_patch (code=0x427f8f08 "Q\364\377\353\367\377\377\352", 
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353") at 
mini-arm.c:3536
#3  0x001830bc in mono_arch_patch_callsite (method_start=0x427f8e90 
"\r\300\240\341\360_-\351(\320M\342", code_ptr=0x427f8f0c "\367\377\377\352",
addr=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353") at 
tramp-arm.c:87
#4  0x0012c5c8 in common_call_trampoline (regs=0x558fd090, code=0x427f8f0c 
"\367\377\377\352", m=0x2a08a000, tramp=0x2e4bcd80 "x\320\217U", vt=0x0, 
vtable_slot=0x0,
need_rgctx_tramp=0) at mini-trampolines.c:673
#5  0x0012c67c in mono_magic_trampoline (regs=0x558fd090, code=0x427f8f0c 
"\367\377\377\352", arg=0x2a08a000, tramp=0x2e4bcd80 "x\320\217U") at 
mini-trampolines.c:690
#6  0x403f5060 in ?? ()
#7  0x403f5060 in ?? ()

All 6 threads where in a trampoline. The method in frame 4 was 
"mono_thread_interruption_checkpoint" for all six thread

Re: [Mono-dev] Assert in mini-arm.c

[Bassam Tabbara]

I tried increasing MIN_PAGES in mono-codeman.c to 32 and still didn't help.

Is there another workaround that could help here?

From: Bassam Tabbara mailto:bas...@symform.com>>
Date: Wednesday, August 14, 2013 12:26 AM
To: Zoltan Varga mailto:var...@gmail.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Assert in mini-arm.c

Here it is. Note that this run was compiled with BIND_ROOM set to 4 as you 
recommended.

#2  0x00172c44 in arm_patch (code=0x407b05c8 
"\357\376\377\353\367\377\377\352\340A-\351\004\320M\342",  target=0x5da1ebe0 
"\r\300\240\341\360_-\351(\320M\342$\311\377\353") at mini-arm.c:3530

(gdb) x/10i code
   0x407b05c8:  bl  0x407b018c
   0x407b05cc:  b   0x407b05b0
   0x407b05d0:  push{r5, r6, r7, r8, lr}
   0x407b05d4:  sub sp, sp, #4
   0x407b05d8:  mov r5, r0
   0x407b05dc:  mov r6, r1
   0x407b05e0:  mov r7, r2
   0x407b05e4:  orr r0, r5, r6
   0x407b05e8:  and r0, r0, #3
   0x407b05ec:  cmp r0, #0

(gdb) x/10i target
   0x5da1ebe0:  mov r12, sp
   0x5da1ebe4:  push{r4, r5, r6, r7, r8, r9, r10, r11, r12, lr}
   0x5da1ebe8:  sub sp, sp, #40 ; 0x28
   0x5da1ebec:  bl  0x5da11084
   0x5da1ebf0:  add r1, sp, #0
   0x5da1ebf4:  str r0, [r1, #4]
   0x5da1ebf8:  ldr r12, [r0]
   0x5da1ebfc:  str r12, [r1]
   0x5da1ec00:  str r1, [r0]
   0x5da1ec04:  str sp, [r1, #12]

Let me know if there is anything else I can provide.

From: Zoltan Varga mailto:var...@gmail.com>>
Date: Tuesday, August 13, 2013 5:15 PM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Assert in mini-arm.c

I meant frame #2, i.e.
#2  0x00172ca8 in arm_patch

  Zoltan


On Wed, Aug 14, 2013 at 2:14 AM, Zoltan Varga 
mailto:var...@gmail.com>> wrote:
Hi,

Can you see whats at 'code' and 'target' at frame #3, i.e.
x/10i code
x/10i target

 Zoltan


On Wed, Aug 14, 2013 at 1:48 AM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
Unfortunately that did not help. Still seeing the problem. I'm still working on 
a test case but I'm not having much luck so far in getting an isolated repro.

I was able to get a debugger attached to the process right when handle_thunk 
asserts, and there were 6 threads with the following call stack:

Thread 5 (Thread 0x558ff460 (LWP 9201)):
#0  handle_thunk (method=0x0, domain=0x4ce44e58, absolute=1, code=0x427f8f08 
"Q\364\377\353\367\377\377\352",
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353", 
dyn_code_mp=0x0) at mini-arm.c:3373
#1  0x00172764 in arm_patch_general (method=0x0, domain=0x0, code=0x427f8f08 
"Q\364\377\353\367\377\377\352",
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353", 
dyn_code_mp=0x0) at mini-arm.c:3425
#2  0x00172ca8 in arm_patch (code=0x427f8f08 "Q\364\377\353\367\377\377\352", 
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353") at 
mini-arm.c:3536
#3  0x001830bc in mono_arch_patch_callsite (method_start=0x427f8e90 
"\r\300\240\341\360_-\351(\320M\342", code_ptr=0x427f8f0c "\367\377\377\352",
addr=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353") at 
tramp-arm.c:87
#4  0x0012c5c8 in common_call_trampoline (regs=0x558fd090, code=0x427f8f0c 
"\367\377\377\352", m=0x2a08a000, tramp=0x2e4bcd80 "x\320\217U", vt=0x0, 
vtable_slot=0x0,
need_rgctx_tramp=0) at mini-trampolines.c:673
#5  0x0012c67c in mono_magic_trampoline (regs=0x558fd090, code=0x427f8f0c 
"\367\377\377\352", arg=0x2a08a000, tramp=0x2e4bcd80 "x\320\217U") at 
mini-trampolines.c:690
#6  0x403f5060 in ?? ()
#7  0x403f5060 in ?? ()

All 6 threads where in a trampoline. The method in frame 4 was 
"mono_thread_interruption_checkpoint" for all six threads.

Does this give you any more clues into what is going on?

This is blocking our upgrade to mono-3-0 unfortunately. Any help will be 
greatly appreciated.

From: Zoltan Varga mailto:var...@gmail.com>>
Date: Tuesday, August 13, 2013 3:20 AM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Assert in mini-arm.c

Hi,

  This is a JIT problem, it will be hard to track down without a testcase. You 
can try changing this line in mono/utils/mono-codeman.c:

#define BIND_ROOM 8

to

#define BIND_ROOM 4

It might fix the issue.

   Zoltan


On Tue, Aug 13, 2013 at 7:44 AM, Bassam Tabbara 
mailto:bas...@symform.co

Re: [Mono-dev] Assert in mini-arm.c

[Bassam Tabbara]

Here it is. Note that this run was compiled with BIND_ROOM set to 4 as you 
recommended.

#2  0x00172c44 in arm_patch (code=0x407b05c8 
"\357\376\377\353\367\377\377\352\340A-\351\004\320M\342",  target=0x5da1ebe0 
"\r\300\240\341\360_-\351(\320M\342$\311\377\353") at mini-arm.c:3530

(gdb) x/10i code
   0x407b05c8:  bl  0x407b018c
   0x407b05cc:  b   0x407b05b0
   0x407b05d0:  push{r5, r6, r7, r8, lr}
   0x407b05d4:  sub sp, sp, #4
   0x407b05d8:  mov r5, r0
   0x407b05dc:  mov r6, r1
   0x407b05e0:  mov r7, r2
   0x407b05e4:  orr r0, r5, r6
   0x407b05e8:  and r0, r0, #3
   0x407b05ec:  cmp r0, #0

(gdb) x/10i target
   0x5da1ebe0:  mov r12, sp
   0x5da1ebe4:  push{r4, r5, r6, r7, r8, r9, r10, r11, r12, lr}
   0x5da1ebe8:  sub sp, sp, #40 ; 0x28
   0x5da1ebec:  bl  0x5da11084
   0x5da1ebf0:  add r1, sp, #0
   0x5da1ebf4:  str r0, [r1, #4]
   0x5da1ebf8:  ldr r12, [r0]
   0x5da1ebfc:  str r12, [r1]
   0x5da1ec00:  str r1, [r0]
   0x5da1ec04:  str sp, [r1, #12]

Let me know if there is anything else I can provide.

From: Zoltan Varga mailto:var...@gmail.com>>
Date: Tuesday, August 13, 2013 5:15 PM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Assert in mini-arm.c

I meant frame #2, i.e.
#2  0x00172ca8 in arm_patch

  Zoltan


On Wed, Aug 14, 2013 at 2:14 AM, Zoltan Varga 
mailto:var...@gmail.com>> wrote:
Hi,

Can you see whats at 'code' and 'target' at frame #3, i.e.
x/10i code
x/10i target

 Zoltan


On Wed, Aug 14, 2013 at 1:48 AM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
Unfortunately that did not help. Still seeing the problem. I'm still working on 
a test case but I'm not having much luck so far in getting an isolated repro.

I was able to get a debugger attached to the process right when handle_thunk 
asserts, and there were 6 threads with the following call stack:

Thread 5 (Thread 0x558ff460 (LWP 9201)):
#0  handle_thunk (method=0x0, domain=0x4ce44e58, absolute=1, code=0x427f8f08 
"Q\364\377\353\367\377\377\352",
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353", 
dyn_code_mp=0x0) at mini-arm.c:3373
#1  0x00172764 in arm_patch_general (method=0x0, domain=0x0, code=0x427f8f08 
"Q\364\377\353\367\377\377\352",
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353", 
dyn_code_mp=0x0) at mini-arm.c:3425
#2  0x00172ca8 in arm_patch (code=0x427f8f08 "Q\364\377\353\367\377\377\352", 
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353") at 
mini-arm.c:3536
#3  0x001830bc in mono_arch_patch_callsite (method_start=0x427f8e90 
"\r\300\240\341\360_-\351(\320M\342", code_ptr=0x427f8f0c "\367\377\377\352",
addr=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353") at 
tramp-arm.c:87
#4  0x0012c5c8 in common_call_trampoline (regs=0x558fd090, code=0x427f8f0c 
"\367\377\377\352", m=0x2a08a000, tramp=0x2e4bcd80 "x\320\217U", vt=0x0, 
vtable_slot=0x0,
need_rgctx_tramp=0) at mini-trampolines.c:673
#5  0x0012c67c in mono_magic_trampoline (regs=0x558fd090, code=0x427f8f0c 
"\367\377\377\352", arg=0x2a08a000, tramp=0x2e4bcd80 "x\320\217U") at 
mini-trampolines.c:690
#6  0x403f5060 in ?? ()
#7  0x403f5060 in ?? ()

All 6 threads where in a trampoline. The method in frame 4 was 
"mono_thread_interruption_checkpoint" for all six threads.

Does this give you any more clues into what is going on?

This is blocking our upgrade to mono-3-0 unfortunately. Any help will be 
greatly appreciated.

From: Zoltan Varga mailto:var...@gmail.com>>
Date: Tuesday, August 13, 2013 3:20 AM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Assert in mini-arm.c

Hi,

  This is a JIT problem, it will be hard to track down without a testcase. You 
can try changing this line in mono/utils/mono-codeman.c:

#define BIND_ROOM 8

to

#define BIND_ROOM 4

It might fix the issue.

   Zoltan


On Tue, Aug 13, 2013 at 7:44 AM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
Folks,

Any insights into why the assert would trigger? Is this a resource exhaustion 
issue, or is specific to certain code that is being JITed? I need someone to 
point me in the right direction. I'm able to reproduce this but only in the 
context of our application. This did not happen with the mono-2-10 branch.

Thanks!
Bassam

From: Bassam Tabbara mailto:bas...@symform.com>>
Date: Friday, August 9, 2013 10:36 AM
To: "mono-devel

Re: [Mono-dev] Assert in mini-arm.c

[Bassam Tabbara]

Unfortunately that did not help. Still seeing the problem. I'm still working on 
a test case but I'm not having much luck so far in getting an isolated repro.

I was able to get a debugger attached to the process right when handle_thunk 
asserts, and there were 6 threads with the following call stack:

Thread 5 (Thread 0x558ff460 (LWP 9201)):
#0  handle_thunk (method=0x0, domain=0x4ce44e58, absolute=1, code=0x427f8f08 
"Q\364\377\353\367\377\377\352",
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353", 
dyn_code_mp=0x0) at mini-arm.c:3373
#1  0x00172764 in arm_patch_general (method=0x0, domain=0x0, code=0x427f8f08 
"Q\364\377\353\367\377\377\352",
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353", 
dyn_code_mp=0x0) at mini-arm.c:3425
#2  0x00172ca8 in arm_patch (code=0x427f8f08 "Q\364\377\353\367\377\377\352", 
target=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353") at 
mini-arm.c:3536
#3  0x001830bc in mono_arch_patch_callsite (method_start=0x427f8e90 
"\r\300\240\341\360_-\351(\320M\342", code_ptr=0x427f8f0c "\367\377\377\352",
addr=0x511f02a0 "\r\300\240\341\360_-\351(\320M\342k\323\377\353") at 
tramp-arm.c:87
#4  0x0012c5c8 in common_call_trampoline (regs=0x558fd090, code=0x427f8f0c 
"\367\377\377\352", m=0x2a08a000, tramp=0x2e4bcd80 "x\320\217U", vt=0x0, 
vtable_slot=0x0,
need_rgctx_tramp=0) at mini-trampolines.c:673
#5  0x0012c67c in mono_magic_trampoline (regs=0x558fd090, code=0x427f8f0c 
"\367\377\377\352", arg=0x2a08a000, tramp=0x2e4bcd80 "x\320\217U") at 
mini-trampolines.c:690
#6  0x403f5060 in ?? ()
#7  0x403f5060 in ?? ()

All 6 threads where in a trampoline. The method in frame 4 was 
"mono_thread_interruption_checkpoint" for all six threads.

Does this give you any more clues into what is going on?

This is blocking our upgrade to mono-3-0 unfortunately. Any help will be 
greatly appreciated.

From: Zoltan Varga mailto:var...@gmail.com>>
Date: Tuesday, August 13, 2013 3:20 AM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] Assert in mini-arm.c

Hi,

  This is a JIT problem, it will be hard to track down without a testcase. You 
can try changing this line in mono/utils/mono-codeman.c:

#define BIND_ROOM 8

to

#define BIND_ROOM 4

It might fix the issue.

   Zoltan


On Tue, Aug 13, 2013 at 7:44 AM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
Folks,

Any insights into why the assert would trigger? Is this a resource exhaustion 
issue, or is specific to certain code that is being JITed? I need someone to 
point me in the right direction. I'm able to reproduce this but only in the 
context of our application. This did not happen with the mono-2-10 branch.

Thanks!
Bassam

From: Bassam Tabbara mailto:bas...@symform.com>>
Date: Friday, August 9, 2013 10:36 AM
To: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: [Mono-dev] Assert in mini-arm.c

Hello,

I'm seeing the following assert on an armv5tel using latest from master:

http://pastebin.com/raw.php?i=CLDXxiPy

I'm trying to get an isolated repro but it proving to be elusive. In our full 
test runs we see this all the time.

Any tips on how to debug this further?

Thanks!
Bassam

___
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


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

Re: [Mono-dev] Assert in mini-arm.c

[Bassam Tabbara]

Folks,

Any insights into why the assert would trigger? Is this a resource exhaustion 
issue, or is specific to certain code that is being JITed? I need someone to 
point me in the right direction. I'm able to reproduce this but only in the 
context of our application. This did not happen with the mono-2-10 branch.

Thanks!
Bassam

From: Bassam Tabbara mailto:bas...@symform.com>>
Date: Friday, August 9, 2013 10:36 AM
To: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: [Mono-dev] Assert in mini-arm.c

Hello,

I'm seeing the following assert on an armv5tel using latest from master:

http://pastebin.com/raw.php?i=CLDXxiPy

I'm trying to get an isolated repro but it proving to be elusive. In our full 
test runs we see this all the time.

Any tips on how to debug this further?

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

[Mono-dev] Assert in mini-arm.c

[Bassam Tabbara]

Hello,

I'm seeing the following assert on an armv5tel using latest from master:

http://pastebin.com/raw.php?i=CLDXxiPy

I'm trying to get an isolated repro but it proving to be elusive. In our full 
test runs we see this all the time.

Any tips on how to debug this further?

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

Re: [Mono-dev] System.Net.Http.Formatting and JSON.NET

[Bassam Tabbara]

Thanks Miguel. You're right that System.Net.Http.Formatting is a copy of MSFT's 
open sourced stack.

However, it currently includes a private version of JSON.NET in it. See bottom 
of 
https://github.com/mono/mono/blob/master/mcs/class/System.Net.Http.Formatting/System.Net.Http.Formatting.dll.sources.

That is quite different from MSFT's version, and causes issues when an assembly 
has a dependency on both Http.Formatting and JSON.Net.

There was more discussion on this topic here:

https://github.com/mono/mono/commit/0d5bb49660a3898d16300db2dd37e357f645b0f3#commitcomment-3384184

From: Miguel de Icaza mailto:mig...@xamarin.com>>
Date: Wednesday, June 19, 2013 6:31 PM
To: Bassam Tabbara mailto:bas...@symform.com>>
Cc: "mono-devel-list@lists.ximian.com<mailto:mono-devel-list@lists.ximian.com>" 
mailto:mono-devel-list@lists.ximian.com>>
Subject: Re: [Mono-dev] System.Net.Http.Formatting and JSON.NET

Mono's System.Net.Http.Formatting is just a copy of Microsoft's open sourced 
stack.

The dependency comes directly from Microsoft's open sourced stack.


On Sat, Jun 8, 2013 at 1:31 PM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
Why does mono bundle JSON.NET<http://JSON.NET> into System.Net.Http.Formatting? 
This is quite different from how MSFT ships System.Net.Http.Formatting.

Thanks!
Bassam

___
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


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

[Mono-dev] System.Net.Http.Formatting and JSON.NET

[Bassam Tabbara]

Why does mono bundle JSON.NET into System.Net.Http.Formatting? This is quite 
different from how MSFT ships System.Net.Http.Formatting.

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

Re: [Mono-dev] Boehm GC reaching max_map_count

[Bassam Tabbara]

We are seeing the same issue. Mono is mapping a lot of memory:

> cat /proc//maps | wc -l
21880

And it then reaches he max_map_count limit and dies:

Program terminated with signal 6, Aborted.
#0  0x7f69c02f51b5 in *__GI_raise (sig=) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
in ../nptl/sysdeps/unix/sysv/linux/raise.c
#0  0x7f69c02f51b5 in *__GI_raise (sig=) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x7f69c02f7fc0 in *__GI_abort () at abort.c:92
#2  0x00493859 in mono_handle_native_sigsegv (signal=-1944970304, 
ctx=) at mini-exceptions.c:2223
#3  
#4  0x7f69c02f51b5 in *__GI_raise (sig=) at 
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#5  0x7f69c02f7fc0 in *__GI_abort () at abort.c:92
#6  0x005f8171 in GC_abort (msg=0x6b4bb1 "mmap(...PROT_NONE...) 
failed") at misc.c:1099
#7  0x005ea028 in GC_unmap (start=0x7f69956e6000 "\350x\211\002", 
bytes=8192) at os_dep.c:2040
#8  0x005f9049 in GC_unmap_old () at allchblk.c:383
#9  0x005e73ce in GC_finish_collection () at alloc.c:776
#10 0x005e69ef in GC_try_to_collect_inner (stop_func=0x5e631c 
) at alloc.c:393
#11 0x005e7ae8 in GC_collect_or_expand (needed_blocks=1, 
ignore_off_page=0) at alloc.c:1045
#12 0x005f6978 in GC_alloc_large (lw=260, k=0, flags=0) at malloc.c:60
#13 0x005f6d65 in GC_generic_malloc (lb=2080, k=0) at malloc.c:204
#14 0x005f6f4e in GC_malloc_atomic (lb=2080) at malloc.c:270
#15 0x005e81db in GC_local_malloc_atomic (bytes=2080) at 
pthread_support.c:380

mmap returns ENOMEM.

We are going to increase the max_map_count limit, but 
http://www.novell.com/support/viewContent.do?externalId=7000830&sliceId=1 warns 
against this (especially that it seems that 128 bytes are allocated in the 
kernel). For small mmaps like 4K or 8K that we see, this seems quite 
inefficient.

Any help here appreciated.

Thanks!
Bassam

-Original Message-
From: mono-devel-list-boun...@lists.ximian.com 
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of 
pablosantosl...@terra.es
Sent: Tuesday, February 23, 2010 3:42 AM
To: mono-devel-list@lists.ximian.com
Cc: Dick Porter; Miguel de Icaza; Jesús Manuel González
Subject: [Mono-dev] Boehm GC reaching max_map_count

Hi there,

We're experiencing problems with a server running on a 64bits box with plenty 
of RAM.

After a few hours it crashed and the problem was that it was reaching the 
max_map_count limit.

We raised it to two times the default (64k) but it also crashed.

The problem is the following: normally the process has a number close to
100 or 200 mappings, but then, in less than a second, it grows beyond the limit 
and crashes.

The process is not allocating memory (it stays stable although quite
high) at this point, so we think it must be related to BoehmGC doing some 
collection or something.

The process is heavily multithreaded.

Mono is built with --with-large-heap and runs on a 64 bits box (where the 
pointer guessing issues with BoehmGC don't hit us so strongly as it happens on 
32 bit systems).

Well, anyone has any idea why this is happening?

Thanks,

pablo
___
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] Post-mortem debugging

[Bassam Tabbara]

Hello,

I'm debugging a core file with gdb and I'm not able to find mono managed 
symbols:

(gdb) where
#0  0x7f93c9096ed5 in raise () from /lib/libc.so.6
#1  0x7f93c90983f3 in abort () from /lib/libc.so.6
#2  0x004933d0 in mono_handle_native_sigsegv (signal=-907561328, 
ctx=) at mini-exceptions.c:2246
#3  0x004e6c9d in mono_arch_handle_altstack_exception 
(sigctx=0x7f93c9e7bc40, fault_addr=, stack_ovf=0) at 
exceptions-amd64.c:957
#4  0x004176e4 in mono_sigsegv_signal_handler (_dummy=11, 
info=0x7f93c9e7bd70, context=0x7f93c9e7bc40) at mini.c:5882
#5  
#6  0x7f93c9d18cc0 in ?? ()
#7  0x413fb199 in ?? ()
#8  0x0025 in ?? ()
#9  0x7f93c9cb6a90 in ?? ()
#10 0x7f93c3cff150 in ?? ()
#11 0x in ?? ()

(gdb) p mono_pmip(0x7f93c9d18cc0)
You can't do that without a process to debug.

I looked at http://www.mono-project.com/Debugging and I can't tell if this is 
supposed to work on core dumps or not. How do you guys do it? What's your 
secret?

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

[Mono-dev] Assertion at mini-arm.c:5559, condition `IS_LDR_PC (code_ptr [0])' not met

[Bassam Tabbara]

Hello,

We are seeing the following on ARM devices. Running mono built from the 2-10 
branch. Any ideas for where to start here?

invalid code stream, instruction before IMT value is not a LDC in 
mono_arch_find_imt_method() (code 0x40be8868 value 0: 0xe1a06000 -1: 0xe591f028 
-2: 0xe1a0e00f)
* Assertion at mini-arm.c:5559, condition `IS_LDR_PC (code_ptr [0])' not met

Stacktrace:

  at System.StringComparer.GetHashCode (object) <0x00067>
  at System.Collections.Hashtable.GetHash (object) <0x00033>
  at System.Collections.Hashtable.get_Item (object) <0x00057>
  at 
System.Collections.Specialized.NameObjectCollectionBase.FindFirstMatchedItem 
(string) <0x00033>
  at System.Collections.Specialized.NameObjectCollectionBase.BaseGet (string) 
<0x0001b>
  at System.Configuration.PropertyInformationCollection.get_Item (string) 
<0x0001b>
  at System.Configuration.ConfigurationElement.get_Item (string) <0x00033>
  at Foo.Bar.NodeSettings.get_ServerAddress () <0x0001f>
  at Foo.Bar.Storage.ContributionHost.Start (System.Action) <0x000c7>
  at (wrapper remoting-invoke-with-check) 
Foo.Bar.Storage.ContributionHost.Start (System.Action) <0x>
  at Symform.Storage.Node.Contribution.ContributionService.OnStart (string[]) 
<0x00113>
  at (wrapper runtime-invoke) .runtime_invoke_void__this___object 
(object,intptr,intptr,intptr) <0x>
  at System.Reflection.MonoMethod.Invoke 
(object,System.Reflection.BindingFlags,System.Reflection.Binder,object[],System.Globalization.CultureInfo)
 <0x00197>
  at System.Reflection.MethodBase.Invoke (object,object[]) <0x00047>
  at MonoServiceRunner.call (object,string,object[]) <0x00087>
  at MonoServiceRunner.MainLoop (System.ServiceProcess.ServiceBase[]) <0x005af>
  at System.ServiceProcess.ServiceBase.Run 
(System.ServiceProcess.ServiceBase[]) <0x0004f>
  at System.ServiceProcess.ServiceBase.Run (System.ServiceProcess.ServiceBase) 
<0x00047>
  at Symform.Storage.Node.Program.Main (string[]) <0x00383>
  at (wrapper runtime-invoke) .runtime_invoke_int_object 
(object,intptr,intptr,intptr) <0x>
  at System.AppDomain.ExecuteAssemblyInternal 
(System.Reflection.Assembly,string[]) <0x0003b>
  at System.AppDomain.ExecuteAssembly 
(string,System.Security.Policy.Evidence,string[]) <0x00033>
  at (wrapper remoting-invoke-with-check) System.AppDomain.ExecuteAssembly 
(string,System.Security.Policy.Evidence,string[]) <0x>
  at MonoServiceRunner.StartService () <0x0040f>
  at (wrapper runtime-invoke) .runtime_invoke_int__this__ 
(object,intptr,intptr,intptr) <0x>
  at System.Runtime.Remoting.RemotingServices.InternalExecuteMessage 
(System.MarshalByRefObject,System.Runtime.Remoting.Messaging.IMethodCallMessage)
 <0x0022f>
  at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage 
(System.Runtime.Remoting.Messaging.IMessage) <0x000e3>
  at 
System.Runtime.Remoting.Messaging.ServerObjectTerminatorSink.SyncProcessMessage 
(System.Runtime.Remoting.Messaging.IMessage) <0x0008f>
  at System.Runtime.Remoting.Lifetime.LeaseSink.SyncProcessMessage 
(System.Runtime.Remoting.Messaging.IMessage) <0x0003b>
  at System.Runtime.Remoting.ClientActivatedIdentity.SyncObjectProcessMessage 
(System.Runtime.Remoting.Messaging.IMessage) <0x00097>
  at 
System.Runtime.Remoting.Messaging.ServerContextTerminatorSink.SyncProcessMessage
 (System.Runtime.Remoting.Messaging.IMessage) <0x001c3>
  at System.Runtime.Remoting.Contexts.CrossContextChannel.SyncProcessMessage 
(System.Runtime.Remoting.Messaging.IMessage) <0x0010b>
  at System.Runtime.Remoting.Channels.ChannelServices.SyncDispatchMessage 
(System.Runtime.Remoting.Messaging.IMessage) <0x0004f>
  at System.AppDomain.ProcessMessageInDomain 
(byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[]&,System.Runtime.Remoting.Messaging.CADMethodReturnMessage&)
 <0x00097>
  at (wrapper remoting-invoke-with-check) 
System.AppDomain.ProcessMessageInDomain 
(byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage,byte[]&,System.Runtime.Remoting.Messaging.CADMethodReturnMessage&)
 <0x>
  at System.Runtime.Remoting.Channels.CrossAppDomainSink.ProcessMessageInDomain 
(byte[],System.Runtime.Remoting.Messaging.CADMethodCallMessage) <0x0007b>
  at (wrapper runtime-invoke) 
.runtime_invoke_CrossAppDomainSink/ProcessMessageRes_object_object 
(object,intptr,intptr,intptr) <0x>
  at System.AppDomain.InvokeInDomainByID 
(int,System.Reflection.MethodInfo,object,object[]) <0x000a7>
  at System.Runtime.Remoting.Channels.CrossAppDomainSink.SyncProcessMessage 
(System.Runtime.Remoting.Messaging.IMessage) <0x00127>
  at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke 
(System.Runtime.Remoting.Messaging.IMessage) <0x0040f>
  at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke 
(System.Runtime.Remoting.Proxies.RealProxy,System.Runtime.Remoting.Messaging.IMessage,System.Exception&,object[]&)
 <0x0042b>
  at (wrapper runtime-invoke) 
.runtime_invoke_object_object_object_Exception&_object[]& 
(object,

Re: [Mono-dev] JIT'er bug?

[Bassam Tabbara]

Thanks Rodrigo. We will open a ticket with an isolated repro.

From: Rodrigo Kumpera [mailto:kump...@gmail.com]
Sent: Tuesday, December 20, 2011 5:10 PM
To: Bassam Tabbara
Cc: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] JIT'er bug?

It does look like a runtime error. Mind  filing a bug report with a test case?


On Tue, Dec 20, 2011 at 5:43 PM, Bassam Tabbara 
mailto:bas...@symform.com>> wrote:
Hello,

We are seeing the following stack trace frequently on startup of our 
application. Seems to happen on both OSX and Linux. We build mono from the 2-10 
branch.  Any ideas?

Stacktrace:

  at System.Collections.Generic.InternalStringComparer.GetHashCode (string) 
<0x0001d>
  at System.Collections.Generic.Dictionary`2.Add (string,int) 
<0x00029>
  at System.Security.Cryptography.Oid.GetName (string) <0x001a3>
  at System.Security.Cryptography.Oid..ctor (string) <0x0001f>
  at System.Security.Cryptography.AsnEncodedData..ctor (string,byte[]) <0x00027>
  at 
System.Security.Cryptography.X509Certificates.X509ExtensionCollection..ctor 
(Mono.Security.X509.X509Certificate) <0x0018b>
  at 
System.Security.Cryptography.X509Certificates.X509Certificate2.get_Extensions 
() <0x0003f>
  at 
System.Security.Cryptography.X509Certificates.X509Certificate2Collection.Find 
(System.Security.Cryptography.X509Certificates.X509FindType,object,bool) 
<0x00b3f>
  at System.Security.Cryptography.X509Certificates.X509Chain.FindParent 
(System.Security.Cryptography.X509Certificates.X509Certificate2) <0x0008b>
  at System.Security.Cryptography.X509Certificates.X509Chain.BuildChainFrom 
(System.Security.Cryptography.X509Certificates.X509Certificate2) <0x00033>
  at System.Security.Cryptography.X509Certificates.X509Chain.Build 
(System.Security.Cryptography.X509Certificates.X509Certificate2) <0x00057>
  at System.Net.ServicePointManager/ChainValidationHelper.ValidateChain 
(Mono.Security.X509.X509CertificateCollection) <0x00267>
  at Mono.Security.Protocol.Tls.SslClientStream.OnRemoteCertificateValidation2 
(Mono.Security.X509.X509CertificateCollection) <0x0001c>
  at Mono.Security.Protocol.Tls.SslStreamBase.RaiseRemoteCertificateValidation2 
(Mono.Security.X509.X509CertificateCollection) <0x00019>
  at 
Mono.Security.Protocol.Tls.SslClientStream.RaiseServerCertificateValidation2 
(Mono.Security.X509.X509CertificateCollection) <0x00013>
  at 
Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.validateCertificates
 (Mono.Security.X509.X509CertificateCollection) <0x000ac>
  at 
Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.ProcessAsTls1 
() <0x000cf>
  at Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () <0x0004d>
  at (wrapper remoting-invoke-with-check) 
Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () <0x>
  at Mono.Security.Protocol.Tls.ClientRecordProtocol.ProcessHandshakeMessage 
(Mono.Security.Protocol.Tls.TlsStream) <0x00087>
  at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback 
(System.IAsyncResult) <0x00243>
  at (wrapper runtime-invoke) .runtime_invoke_void__this___object 
(object,intptr,intptr,intptr) <0x>

Native stacktrace:

0   someapp  0x000d4ef6 
mono_handle_native_sigsegv + 376
1   someapp  0xfc3c 
mono_sigsegv_signal_handler + 322
2   libsystem_c.dylib   0x9a0a059b _sigtramp + 
43
3   ??? 0x 0x0 + 
4294967295
4   libsystem_c.dylib   0x9a008f4b bsearch + 47
5   someapp  0x0014cd58 
mono_class_interface_offset + 67
6   someapp  0x0014cdb2 
mono_class_interface_offset_with_variance + 24
7   someapp  0x000d5d35 
mono_convert_imt_slot_to_vtable_slot + 138
8   someapp  0x000d61a3 
common_call_trampoline + 357
9   someapp  0x000d6e37 
mono_vcall_trampoline + 388
10  ??? 0x00492c74 0x0 + 4795508
11  ??? 0x016f1dca 0x0 + 
24059338
12  ??? 0x0262d7e4 0x0 + 
40032228
13  ??? 0x0262d5f0 0x0 + 
40031728
14  ??? 0x0262d598 0x0 + 
40031640
15  ??? 0x0262d374 0x0 + 
40031092
16  ??? 0x0262d1a8 0x0 + 
40030632
17  ??? 0x0262c418 0x0 + 
40027160
18  ??? 0x02628eb4 0x0 + 
40013492
  

[Mono-dev] JIT'er bug?

[Bassam Tabbara]

Hello,

We are seeing the following stack trace frequently on startup of our 
application. Seems to happen on both OSX and Linux. We build mono from the 2-10 
branch.  Any ideas?

Stacktrace:

  at System.Collections.Generic.InternalStringComparer.GetHashCode (string) 
<0x0001d>
  at System.Collections.Generic.Dictionary`2.Add (string,int) 
<0x00029>
  at System.Security.Cryptography.Oid.GetName (string) <0x001a3>
  at System.Security.Cryptography.Oid..ctor (string) <0x0001f>
  at System.Security.Cryptography.AsnEncodedData..ctor (string,byte[]) <0x00027>
  at 
System.Security.Cryptography.X509Certificates.X509ExtensionCollection..ctor 
(Mono.Security.X509.X509Certificate) <0x0018b>
  at 
System.Security.Cryptography.X509Certificates.X509Certificate2.get_Extensions 
() <0x0003f>
  at 
System.Security.Cryptography.X509Certificates.X509Certificate2Collection.Find 
(System.Security.Cryptography.X509Certificates.X509FindType,object,bool) 
<0x00b3f>
  at System.Security.Cryptography.X509Certificates.X509Chain.FindParent 
(System.Security.Cryptography.X509Certificates.X509Certificate2) <0x0008b>
  at System.Security.Cryptography.X509Certificates.X509Chain.BuildChainFrom 
(System.Security.Cryptography.X509Certificates.X509Certificate2) <0x00033>
  at System.Security.Cryptography.X509Certificates.X509Chain.Build 
(System.Security.Cryptography.X509Certificates.X509Certificate2) <0x00057>
  at System.Net.ServicePointManager/ChainValidationHelper.ValidateChain 
(Mono.Security.X509.X509CertificateCollection) <0x00267>
  at Mono.Security.Protocol.Tls.SslClientStream.OnRemoteCertificateValidation2 
(Mono.Security.X509.X509CertificateCollection) <0x0001c>
  at Mono.Security.Protocol.Tls.SslStreamBase.RaiseRemoteCertificateValidation2 
(Mono.Security.X509.X509CertificateCollection) <0x00019>
  at 
Mono.Security.Protocol.Tls.SslClientStream.RaiseServerCertificateValidation2 
(Mono.Security.X509.X509CertificateCollection) <0x00013>
  at 
Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.validateCertificates
 (Mono.Security.X509.X509CertificateCollection) <0x000ac>
  at 
Mono.Security.Protocol.Tls.Handshake.Client.TlsServerCertificate.ProcessAsTls1 
() <0x000cf>
  at Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () <0x0004d>
  at (wrapper remoting-invoke-with-check) 
Mono.Security.Protocol.Tls.Handshake.HandshakeMessage.Process () <0x>
  at Mono.Security.Protocol.Tls.ClientRecordProtocol.ProcessHandshakeMessage 
(Mono.Security.Protocol.Tls.TlsStream) <0x00087>
  at Mono.Security.Protocol.Tls.RecordProtocol.InternalReceiveRecordCallback 
(System.IAsyncResult) <0x00243>
  at (wrapper runtime-invoke) .runtime_invoke_void__this___object 
(object,intptr,intptr,intptr) <0x>

Native stacktrace:

0   someapp  0x000d4ef6 
mono_handle_native_sigsegv + 376
1   someapp  0xfc3c 
mono_sigsegv_signal_handler + 322
2   libsystem_c.dylib   0x9a0a059b _sigtramp + 
43
3   ??? 0x 0x0 + 
4294967295
4   libsystem_c.dylib   0x9a008f4b bsearch + 47
5   someapp  0x0014cd58 
mono_class_interface_offset + 67
6   someapp  0x0014cdb2 
mono_class_interface_offset_with_variance + 24
7   someapp  0x000d5d35 
mono_convert_imt_slot_to_vtable_slot + 138
8   someapp  0x000d61a3 
common_call_trampoline + 357
9   someapp  0x000d6e37 
mono_vcall_trampoline + 388
10  ??? 0x00492c74 0x0 + 4795508
11  ??? 0x016f1dca 0x0 + 
24059338
12  ??? 0x0262d7e4 0x0 + 
40032228
13  ??? 0x0262d5f0 0x0 + 
40031728
14  ??? 0x0262d598 0x0 + 
40031640
15  ??? 0x0262d374 0x0 + 
40031092
16  ??? 0x0262d1a8 0x0 + 
40030632
17  ??? 0x0262c418 0x0 + 
40027160
18  ??? 0x02628eb4 0x0 + 
40013492
19  ??? 0x02628904 0x0 + 
40012036
20  ??? 0x026281d0 0x0 + 
40010192
21  ??? 0x026237f8 0x0 + 
39991288
22  ??? 0x0262357d 0x0 + 
39990653
23  ??? 0x0262355a 0x0 + 
39990618
24  ??? 0x0262352c 0x0 + 
39990572
25  ??? 0x02622e7d 0

[Mono-dev] /dev/crypto and mono

[Bassam Tabbara]

Hello,

Has anyone attempted to have mono use cryptodev modules in Linux 
(http://www.logix.cz/michal/devel/cryptodev/) instead of the managed 
implementations? What about on OSX?

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

[Mono-dev] Exception on ASP.NET startup

[Bassam Tabbara]

Hello,

We see the following exception every other day on our front end servers:

System.ArgumentException: Key duplication when adding: sessionState
  at System.Collections.Hashtable.PutImpl (System.Object key, System.Object 
value, Boolean overwrite) [0x0] in :0
  at System.Collections.Hashtable.Add (System.Object key, System.Object value) 
[0x0] in :0
  at System.Collections.Specialized.NameObjectCollectionBase.BaseAdd 
(System.String name, System.Object value) [0x0] in :0
  at System.Collections.Specialized.NameObjectCollectionBase.BaseSet 
(System.String name, System.Object value) [0x0] in :0
  at System.Configuration.ConfigurationSectionCollection.get_Item 
(System.String name) [0x0] in :0
  at System.Configuration.Configuration.GetSection (System.String path) 
[0x0] in :0
  at System.Web.Configuration.WebConfigurationManager.GetSection (System.String 
sectionName, System.String path, System.Web.HttpContext context) [0x0] in 
:0
  at System.Web.Configuration.WebConfigurationManager.GetSection (System.String 
sectionName) [0x0] in :0
  at System.Web.SessionState.SessionStateModule.Init 
(System.Web.HttpApplication app) [0x0] in :0
  at System.Web.Configuration.HttpModulesSection.LoadModules 
(System.Web.HttpApplication app) [0x0] in :0
  at System.Web.HttpApplication.InitOnce (Boolean full_init) [0x0] in 
:0

Seems like there is a race with ASP.NET startup on multi-core machines. We are 
running 2-10 bits.

Anyone seen this before?

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

Re: [Mono-dev] Native stack trace in mono-2-10

[Bassam Tabbara]

Thanks Andres. 

We build out of the mono-2-10 branch directly (no tags).

The part that is puzzling to me is why monoeg_g_hash_table_lookup calls 
mono_magic_trampoline (it doesn't).  Also frame #12 looks very suspiciously 
close in value to the key parameter of monoeg_g_hash_table_lookup (they are 
0x30 apart).

#10 0x004977cd in mono_magic_trampoline (regs=0x600311, code=0x600311 
"__icall_wrapper_", arg=0x5f, tramp=0x8 ) at 
mini-trampolines.c:590
#11 0x41d5116a in ?? ()
#12 0x7fe15cd65158 in ?? ()
#13 0x005e2d2b in monoeg_g_hash_table_lookup (hash=0x178c180, 
key=0x7fe15cd653e8) at ghashtable.c:280
#14 0x41ff0290 in ?? ()
#15 0x in ?? ()

Any pointers on how to proceed here would be appreciated. How do folks on the 
mono team debug stack corruption like this?

Thanks!
Bassam

-Original Message-
From: mono-devel-list-boun...@lists.ximian.com 
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Andres G. 
Aragoneses
Sent: Monday, September 12, 2011 9:57 AM
To: mono-devel-list@lists.ximian.com
Subject: Re: [Mono-dev] Native stack trace in mono-2-10

On 09/11/2011 09:42 AM, Bassam Tabbara wrote:
> Hello,
>
> We are seeing the following crash quite frequently on our test servers:
>
> #0 0x7fe188725165 in raise () from /lib/libc.so.6
>
> #1 0x7fe188727f70 in abort () from /lib/libc.so.6
>
> #2 0x00493298 in mono_handle_native_sigsegv (signal=2086645120,
> ctx=) at mini-exceptions.c:2245
>
> #3 0x004e6c8d in mono_arch_handle_altstack_exception
> (sigctx=0x7fe18390fac0, fault_addr=,
>
> stack_ovf=0) at exceptions-amd64.c:956
>
> #4 0x00417704 in mono_sigsegv_signal_handler (_dummy=11,
> info=0x7fe18390fbf0, context=0x7fe18390fac0) at mini.c:5881
>
> #5 
>
> #6 0x7fe1887fbc0b in ?? () from /lib/libc.so.6
>
> #7 0x0041e751 in mono_jit_compile_method_with_opt
> (method=0x178c180, opt=51472895, ex=0x7fe15cd65040) at mini.c:5342
>
> #8 0x0041eefe in mono_jit_compile_method (method=0x600311) at
> mini.c:5403
>
> #9 0x00496eaf in common_call_trampoline (regs=0x7fe15cd652f0,
> code=0x41ff0290 "\353", ,
>
> m=0x178c180, tramp=, vt=0x0, vtable_slot=0x0,
> need_rgctx_tramp=0) at mini-trampolines.c:488
>
> #10 0x004977cd in mono_magic_trampoline (regs=0x600311,
> code=0x600311 "__icall_wrapper_", arg=0x5f,
>
> tramp=0x8 ) at mini-trampolines.c:590
>
> #11 0x41d5116a in ?? ()
>
> #12 0x7fe15cd65158 in ?? ()
>
> #13 0x005e2d2b in monoeg_g_hash_table_lookup (hash=0x178c180,
> key=0x7fe15cd653e8) at ghashtable.c:280
>
> #14 0x41ff0290 in ?? ()
>
> #15 0x in ?? ()
>
> The servers is an x64 running Debian Linux 6.
>
> The back trace looks odd in that g_hash_table_lookup is calling a
> trampoline. Is this memory corruption? Any ideas on how to debug this?


Have you read http://www.mono-project.com/Gdb ?

Also, mono-2-10 is a branch, are you using the branch or particular 
tag/version? (I recall seeing a bug about trampolines and g_hash_tables 
being already fixed upstream a while ago.)

   Andres

-- 

___
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] Native stack trace in mono-2-10

[Bassam Tabbara]

Hello,

We are seeing the following crash quite frequently on our test servers:

#0  0x7fe188725165 in raise () from /lib/libc.so.6
#1  0x7fe188727f70 in abort () from /lib/libc.so.6
#2  0x00493298 in mono_handle_native_sigsegv (signal=2086645120, 
ctx=) at mini-exceptions.c:2245
#3  0x004e6c8d in mono_arch_handle_altstack_exception 
(sigctx=0x7fe18390fac0, fault_addr=,
stack_ovf=0) at exceptions-amd64.c:956
#4  0x00417704 in mono_sigsegv_signal_handler (_dummy=11, 
info=0x7fe18390fbf0, context=0x7fe18390fac0) at mini.c:5881
#5  
#6  0x7fe1887fbc0b in ?? () from /lib/libc.so.6
#7  0x0041e751 in mono_jit_compile_method_with_opt (method=0x178c180, 
opt=51472895, ex=0x7fe15cd65040) at mini.c:5342
#8  0x0041eefe in mono_jit_compile_method (method=0x600311) at 
mini.c:5403
#9  0x00496eaf in common_call_trampoline (regs=0x7fe15cd652f0, 
code=0x41ff0290 "\353", ,
m=0x178c180, tramp=, vt=0x0, vtable_slot=0x0, 
need_rgctx_tramp=0) at mini-trampolines.c:488
#10 0x004977cd in mono_magic_trampoline (regs=0x600311, code=0x600311 
"__icall_wrapper_", arg=0x5f,
tramp=0x8 ) at mini-trampolines.c:590
#11 0x41d5116a in ?? ()
#12 0x7fe15cd65158 in ?? ()
#13 0x005e2d2b in monoeg_g_hash_table_lookup (hash=0x178c180, 
key=0x7fe15cd653e8) at ghashtable.c:280
#14 0x41ff0290 in ?? ()
#15 0x in ?? ()

The servers is an x64 running Debian Linux 6.

The back trace looks odd in that g_hash_table_lookup is calling a trampoline. 
Is this memory corruption? Any ideas on how to debug this?

Thanks!
Bassam

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

Re: [Mono-dev] Help with heap profilers

[Bassam Tabbara]

Any help with this would be appreciated? What tools are folks using to find 
leaks / fragmentation issues on mono?

From: mono-devel-list-boun...@lists.ximian.com 
[mailto:mono-devel-list-boun...@lists.ximian.com] On Behalf Of Bassam Tabbara
Sent: Thursday, October 21, 2010 11:20 PM
To: mono-devel-list@lists.ximian.com
Subject: [Mono-dev] Help with heap profilers

I suspect I'm seeing a low grade leak with ASP.NET, and I'm having a hard time 
getting any of the heap profilers to run correctly. Which is the recommended 
heap profiler? I assume it's the logging profiler. I run it with the following 
options:

--profile=logging:gc,as,output=/mnt/profile/frontend.$$.mprofile

And it seems to hang my process frequently both while running and during 
shutdown. Also even when it does not hang, I'm unable to get mprof-decoder to 
parse its output, I see the following exception quite frequently:

Unhandled Exception: System.OverflowException: Number overflow.
  at Mono.Profiler.BlockData.DecodeHeaderBlockCounterDelta (System.Byte[] 
header) [0x0] in :0
  at Mono.Profiler.SyncLogFileReader.ReadBlock () [0x0] in :0
  at Mono.Profiler.ConsoleDecoder.Main (System.String[] argv) [0x0] in 
:0

Any help would be appreciated. I'm using mono built from mono-2-6 branch.

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

[Mono-dev] Help with heap profilers

[Bassam Tabbara]

I suspect I'm seeing a low grade leak with ASP.NET, and I'm having a hard time 
getting any of the heap profilers to run correctly. Which is the recommended 
heap profiler? I assume it's the logging profiler. I run it with the following 
options:

--profile=logging:gc,as,output=/mnt/profile/frontend.$$.mprofile

And it seems to hang my process frequently both while running and during 
shutdown. Also even when it does not hang, I'm unable to get mprof-decoder to 
parse its output, I see the following exception quite frequently:

Unhandled Exception: System.OverflowException: Number overflow.
  at Mono.Profiler.BlockData.DecodeHeaderBlockCounterDelta (System.Byte[] 
header) [0x0] in :0
  at Mono.Profiler.SyncLogFileReader.ReadBlock () [0x0] in :0
  at Mono.Profiler.ConsoleDecoder.Main (System.String[] argv) [0x0] in 
:0

Any help would be appreciated. I'm using mono built from mono-2-6 branch.

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

[Mono-dev] [PATCH] Make mono on OSX relocatable

[Bassam Tabbara]

Attached is a patched that makes mono on OSX relocatable as with Linux, Windows 
and Solaris. It would be great if this can be committed to the mono-2-6 branch.

Thanks!
Bassam



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

[Mono-dev] Scripts to create the Mac OS X dmg packages

[Bassam Tabbara]

I'm looking for the scripts to generate the Mac OS X dmg packages that are on:

http://www.go-mono.com/mono-downloads/download.html

Are those available anywhere?

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

[Mono-dev] [Patch] Fix bug where HttpWebRequest.BeginResponse never completes

[Bassam Tabbara]

We are seeing a case where HttpWebRequest.BeginResponse never completes even 
through there is a response outstanding on the connection. We see this with 
mono 2.6.7. I've traces this down to the HttpWebRequest.SetResponseData method. 
Attached is a patch that fixes the problem.

Thanks!
Bassam



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

[Mono-dev] MVC 2 support

[Bassam Tabbara]

Hello,

Which version of mono support MVC 2 ?

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

[Mono-dev] Support for System.Net.ServicePoint.SetTcpKeepAlive

[Bassam Tabbara]

.NET FX 3.5 SP1 (and .NET 2.0 SP2) seems to have added a useful function to the 
System.Net.ServicePoint class - SetTcpKeepAlive. Which version of Mono would 
this be aligned to? Are there any plans to add similar support?

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

[Mono-dev] Bug in System.Core Lookup

[Bassam Tabbara]

I'm running Mono 2.0-1 on Linux. The implementation of Lookup extension method 
on IEnumerable does not seem to handle a case insensitive comparer correctly. 
The code does the following:

public static Lookup ToLookup (this 
IEnumerable source,
   Func keySelector, Func 
elementSelector, IEqualityComparer comparer)
   {
   if (source == null || keySelector == null || 
elementSelector == null)
   throw new ArgumentNullException ();

   Dictionary> dictionary = new 
Dictionary> (comparer ?? EqualityComparer.Default);
   foreach (TSource element in source) {
   TKey key = keySelector (element);
   if (key == null)
  throw new ArgumentNullException ();
   if (!dictionary.ContainsKey (key))
  dictionary.Add (key, new List 
());
   dictionary [key].Add (elementSelector (element));
   }
   return new Lookup (dictionary);
   }

The last line of the this method does not pass the comparer to the 
Lookup class and hence all comparisons are done with the wrong 
comparer.

Please let me know if you'd like me to test a patch.

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

[Mono-dev] Asynchronous sockets

[Bassam Tabbara]

>From what I can see, Mono does not seem to use asynchronous sockets (even when 
>using System.Net.Socket.Begin/End) on a Windows platform. Is this correct? Any 
>plans to add this support?

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

[Mono-dev] eglib and cygwin

[Bassam Tabbara]

Hello,

 

I'm unable to compile eglib in a cygwin/mingw environment. I've tried the
following:

 

cd eglib

./autogen.sh

cp winconfig.h config.h

[modified Makefile and src/Makefile to use -mno-cygwin -g options to gcc]

make

 

I get the following errors:

make[2]: Entering directory `/usr/local/src/mono/mono/eglib/src'

/bin/sh ../libtool --tag=CC   --mode=compile gcc -mno-cygwin -g
-DHAVE_CONFIG_H

-I. -I.. -I.  -I/usr/local/src/mono/deps/include  -Wall -D_FORTIFY_SOURCE=2
-g

O0 -D_GNU_SOURCE -MT libeglib_la-gfile.lo -MD -MP -MF
.deps/libeglib_la-gfile.T

o -c -o libeglib_la-gfile.lo `test -f 'gfile.c' || echo './'`gfile.c

 gcc -mno-cygwin -g -DHAVE_CONFIG_H -I. -I.. -I.
-I/usr/local/src/mono/deps/inc

ude -Wall -D_FORTIFY_SOURCE=2 -g -O0 -D_GNU_SOURCE -MT libeglib_la-gfile.lo
-MD

-MP -MF .deps/libeglib_la-gfile.Tpo -c gfile.c  -DDLL_EXPORT -DPIC -o
.libs/lib

glib_la-gfile.o

gfile.c:40:1: warning: "S_ISREG" redefined

In file included from gfile.c:34:

/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/include/sys/s
tat

h:72:1: warning: this is the location of the previous definition

gfile.c:41:1: warning: "S_ISDIR" redefined

/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/include/sys/s
tat

h:68:1: warning: this is the location of the previous definition

 

Is there a recommended way to buld eglib in a cygwin/mingw environment?

 

Thanks in advance!

Bassam

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