Bug #619981 “mono apps crash on omap4 due to no smp support for ...” : Bugs : mono package : Ubuntu

Revision history for this message

Tobin Davis (gruemaster) wrote on 2010-08-18:

#1

Dependencies.txt Edit (6.6 KiB, text/plain; charset="utf-8")

Revision history for this message

Tobin Davis (gruemaster) wrote on 2010-08-18:

#2

banshee.log Edit (4.7 KiB, text/plain)

Added log from "banshee --debug" output.

Oliver Grawert (ogra) on 2010-08-20

Changed in banshee (Ubuntu Maverick):
milestone:	none → ubuntu-10.10-beta

Revision history for this message

Micheal Harker (mh0) wrote on 2010-08-20:

#3

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

Changed in banshee (Ubuntu Maverick):
status:	New → Confirmed

Revision history for this message

C de-Avillez (hggdh2) wrote on 2010-08-20:

#4

Hi Tobin,

I cannot reproduce your issue. But I see, in the debug log, this:

[1 Warn 18:32:38.518] Service `Banshee.Gui.InterfaceActionService' not started: Extension node not found in path: /Banshee/PlaybackController/ShuffleModes
[1 Warn 18:32:38.519] Caught an exception - System.InvalidOperationException: Extension node not found in path: /Banshee/PlaybackController/ShuffleModes (in `Mono.Addins')

Can you check this addin, and try again?

Changed in banshee (Ubuntu Maverick):
status:	Confirmed → Incomplete

Revision history for this message

Alexander Sack (asac) wrote on 2010-08-21:

#5

This is a bug that might only happen on ARMEL. C de-Avillez, are you trying to reproduce on ARMEL?

Revision history for this message

Alexander Sack (asac) wrote on 2010-08-21:

#6

assigned linaro foundations team; loic said for mono process would be that foundations would have to come up with reduced testcase and then hand over for bug fixing to toolchain WG that would then fix mono jit (if needed).

Changed in banshee (Ubuntu Maverick):
assignee:	nobody → Linaro Foundations (arm-foundations)
importance:	Undecided → High
assignee:	Linaro Foundations (arm-foundations) → nobody
assignee:	nobody → Linaro Foundations (arm-foundations)

Oliver Grawert (ogra) on 2010-08-27

Changed in banshee (Ubuntu Maverick):
milestone:	ubuntu-10.10-beta → ubuntu-10.10

Revision history for this message

Tobin Davis (gruemaster) wrote on 2010-09-10:

#7

Changing back to confirmed, as this appears to affect armel only. I am unable to reproduce this on x86 as well.

Changed in banshee (Ubuntu Maverick):
status:	Incomplete → Confirmed

Oliver Grawert (ogra) on 2010-09-17

Changed in banshee (Ubuntu Maverick):
milestone:	ubuntu-10.10 → none

Revision history for this message

Gabriel Burt (gabaug) wrote on 2010-11-09:

#8

Tobin, that log doesn't show the crash. If you got the log from ~/.config/banshee-1/log, note that it is overwritten every time you launch Banshee. The InterfaceActionService not starting is a huge issue -- there's no chance the app will work with that failing. Can you try running banshee-1 again with --debug and --debug-addins ? Thanks.

Revision history for this message

Michael Casadevall (mcasadevall) wrote on 2010-11-18:

#9

Been looking into this, and discussed with Linaro. Reassigning from Linaro to myself.

This seems to be a general issue with mono on ARM (or at least Thumb2) mode. I've been running through the entire battery of tests for mono and we're getting failures so I suspect its just a matter of correcting these failures as they are in similar areas where I'm seeing crashes (specifically PInvoke).

From the mono test suite:
Testing pinvoke2.exe... failed 256 (1) signal (0).
Testing pinvoke3.exe... failed 256 (1) signal (0).
Testing pinvoke11.exe... failed 768 (3) signal (0).

Will continue to look more indepth.

affects:	banshee (Ubuntu) → mono (Ubuntu)
Changed in mono (Ubuntu):
assignee:	Linaro Foundations (linaro-foundations) → Michael Casadevall (mcasadevall)
Changed in mono (Ubuntu Maverick):
assignee:	Linaro Foundations (linaro-foundations) → Michael Casadevall (mcasadevall)

Alexander Sack (asac) on 2011-01-03

Changed in mono (Ubuntu Natty):
milestone:	none → ubuntu-11.04-beta

Jamie Bennett (jamiebennett) on 2011-01-13

tags:

added: omap4

Revision history for this message

Jani Monoses (jani) wrote on 2011-01-14:

#10

I find it is not crashing with banshee installed on an ubuntu-minimal image.
Once I install gtk2-engines-murrine and rerun it crashes.
So may be a theming related issue.

Revision history for this message

Jani Monoses (jani) wrote on 2011-01-14:

#11

although there may be more than one bug here. I can only reproduce a crash on startup, this is what the arm team has seen recently. So no opportunity for banshee to get to stay idle for a while, as it does not start.

Revision history for this message

Jo Shields (directhex) wrote on 2011-01-14: Re: [Bug 619981] Re: Banshee crashed while sitting idle on omap4

#12

On Fri, 2011-01-14 at 19:59 +0000, Jani Monoses wrote:
> I find it is not crashing with banshee installed on an ubuntu-minimal image.
> Once I install gtk2-engines-murrine and rerun it crashes.
> So may be a theming related issue.

I can believe this - IIRC, not all of the GTK# examples work correctly
on ARM (apt:gtk-sharp2-examples). It would also explain why I haven't
reproduced the issue - my ARM box runs XFCE4, complete with an XFCE4
theme which uses the gtk2-engines-xfce theme engine

Revision history for this message

Gabriel Burt (gabaug) wrote on 2011-01-14: Re: Banshee crashed while sitting idle on omap4

#13

Jani, can you please attach a log that shows the crash?

`banshee-1 --debug > log.txt` should suffice.

Revision history for this message

Gabriel Burt (gabaug) wrote on 2011-01-14:

#14

Jani, actually you should file a new bug, since this issue is about Banshee crashing while sitting idle.

Speaking of this bug, we still don't have a full log showing the problem. Anybody able to reproduce it still?

Revision history for this message

Gabriel Burt (gabaug) wrote on 2011-01-14:

#15

Jani, looks like your bug is already filed: bug #391588 -- unless your crash stack trace is different.

Steve Langasek (vorlon) on 2011-02-15

tags:

added: arm-porting-queue

Revision history for this message

Ricardo Salveti (rsalveti) wrote on 2011-02-16:

#16

banshee-smp-late-crash.txt Edit (17.5 KiB, text/plain)

I tested today and was able to reproduce this issue, but is more related with bug 391588 than I thought. Most of the time when testing on Panda (with 2 CPUs) I was unable to even start it, crashing in many different ways. After finally able to open it without crashing, it crashed when I added music to ~/Music, like described at the attached log.

For me it seems that Banshee and/or Mono is not thread safe in this case.

Tobin Davis (gruemaster) on 2011-02-25

summary:

- Banshee crashed while sitting idle on omap4
+ mono apps crash on omap4 due to no smp support for armel

Revision history for this message

Michael Casadevall (mcasadevall) wrote on 2011-03-02:

#17

This has been fixed in git for mono 2.10 with implementation of OP_MEMORY_BLOCK in the ARM JIT. With this patch, most of the mono test suite passes with only two regressions, but due to issues with the Ubuntu toolchain, mono upstream is requesting that we test against Debian sid to disprove the Ubuntu toolchain as the source of these regressions. Since Ubuntu is shipping 2.6, as are all the support libraries, there is no sane way to test banshee against this version of mono to determine if the regression has been truly passed, but the massive improvement on test suite results is encouraging.

Currently, the in-archive mono is still affected by https://bugs.launchpad.net/ubuntu/+source/gcc-4.5/+bug/721531 - I have not been able to isolate the workaround committed to our version of mono.

Revision history for this message

Jani Monoses (jani) wrote on 2011-03-02:

#18

Would building mono 2.6 on Ubuntu with gcc 4.4 and testing that with banshee bring some new light to the matter?

Revision history for this message

Tobin Davis (gruemaster) wrote on 2011-03-09:

#19

Download full text (8.1 KiB)

Testing Michael's ppa with the mono smp fix backported to 2.6, f-spot & banshee still fail at roughly the same point, but the failure output is different now. See below:

f-spot:
ubuntu@panda21:~$ f-spot
[Info 17:52:15.666] Initializing Mono.Addins
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe00083 (F-Spot)
Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.

(f-spot:10958): Gtk-CRITICAL **: IA__gtk_style_detach: assertion `style->attach_count > 0' failed

(f-spot:10958): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference.

(f-spot:10958): GLib-GObject-CRITICAL **: g_value_get_float: assertion `G_VALUE_HOLDS_FLOAT (value)' failed

(f-s...

Testing Michael's ppa with the mono smp fix backported to 2.6, f-spot & banshee still fail at roughly the same point, but the failure output is different now.  See below:

f-spot:
ubuntu@panda21:~$ f-spot
[Info  17:52:15.666] Initializing Mono.Addins
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0xe00083 (F-Spot)
Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.

(f-spot:10958): Gtk-CRITICAL **: IA__gtk_style_detach: assertion `style->attach_count > 0' failed

(f-spot:10958): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference.

(f-spot:10958): GLib-GObject-CRITICAL **: g_value_get_float: assertion `G_VALUE_HOLDS_FLOAT (value)' failed

(f-spot:10958): GLib-GObject-CRITICAL **: g_value_get_float: assertion `G_VALUE_HOLDS_FLOAT (value)' failed
**
ERROR:class.c:7042:mono_array_element_size: assertion failed: (ac->rank)
Stacktrace:

at (wrapper managed-to-native) object.__icall_wrapper_mono_array_new_specific (intptr,int) <0xffffffff>
  at FSpot.Import.ImportController.DoImport () <0x002ec>
  at FSpot.Import.ImportController.<StartImport>m__25 () <0x0001b>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this__ (object,intptr,intptr,intptr) <0x0006b>

Native stacktrace:

Debug info from gdb:

Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
Segmentation fault (core dumped)
ubuntu@panda21:~$

banshee:
ubuntu@panda21:~$ banshee

[Info  18:16:32.218] Running Banshee 1.9.4: [Ubuntu Natty (development branch) (linux-gnueabi, arm) @ 2011-03-03 17:27:45 UTC]
[Info  18:16:38.821] Updating web proxy from GConf
[Info  18:16:39.147] All services are started 4.807586
Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x340006d (Banshee Me)
Window manager warning: meta_window_activate called by a pager with a 0 timestamp; the pager needs to be fixed.
[Info  18:16:42.177] nereid Client Started
[Info  18:16:42.614] GStreamer version 0.10.32.0, gapless: True, replaygain: False
**
ERROR:object.c:4434:mono_string_new_size: assertion failed: (vtable)
**
ERROR:object.c:4434:mono_string_new_size: assertion failed: (vtable)
Stacktrace:

Stacktrace:

at (wrapper managed-to-native) string.InternalAllocateStr (int) <0xffffffff>
  at (wrapper managed-to-native) string.InternalAllocateStr (int) <0xffffffff>
  at string.CreateString (char[]) <0x0004c>
  at string.CreateString (char[]) <0x0004c>
  at (wrapper managed-to-managed) string..ctor (char[]) <0x00023>
  at (wrapper managed-to-managed) string..ctor (char[]) <0x00023>
  at System.Text.Encoding.GetString (byte[],int,int) <0x0004b>
  at System.Text.Encoding.GetString (byte[],int,int) <0x0004b>
  at System.Text.UTF8Encoding.GetString (byte[],int,int) <0x00033>
  at System.Text.UTF8Encoding.GetString (byte[],int,int) <0x00033>
  at System.Text.Encoding.GetString (byte[]) <0x0003f>
  at System.Text.Encoding.GetString (byte[]) <0x0003f>
  at GLib.Marshaller.Utf8PtrToString (intptr) <0x000a3>
  at GLib.Marshaller.Utf8PtrToString (intptr) <0x000a3>
  at Hyena.SafeUri.FilenameToUri (string) <0x00067>
  at Hyena.SafeUri.FilenameToUri (string) <0x00067>
  at Hyena.SafeUri..ctor (string) <0x00063>
  at Hyena.SafeUri..ctor (string) <0x00063>
  at Banshee.Collection.RescanPipeline.OnFinished (object,System.EventArgs) <0x0006f>
  at Banshee.Collection.RescanPipeline.OnFinished (object,System.EventArgs) <0x0006f>
  at Hyena.Collections.QueuePipeline`1<object>.OnFinished () <0x0003f>
  at Hyena.Collections.QueuePipeline`1<object>.OnFinished () <0x0003f>
  at Hyena.Collections.QueuePipeline`1<object>.OnElementFinished (object,System.EventArgs) <0x00103>
  at Hyena.Collections.QueuePipeline`1<object>.OnElementFinished (object,System.EventArgs) <0x00103>
  at Hyena.Collections.QueuePipelineElement`1<object>.OnFinished () <0x000c7>
  at Hyena.Collections.QueuePipelineElement`1<object>.OnFinished () <0x000c7>
  at Hyena.Collections.QueuePipelineElement`1<object>.Processor (object) <0x00237>
  at Hyena.Collections.QueuePipelineElement`1<object>.Processor (object) <0x00237>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0x00073>
  at (wrapper runtime-invoke) object.runtime_invoke_void__this___object (object,intptr,intptr,intptr) <0x00073>

Native stacktrace:

Debug info from gdb:

**
ERROR:object.c:4434:mono_string_new_size: assertion failed: (vtable)
Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
Could not attach to process.  If your uid matches the uid of the target
process, check the setting of /proc/sys/kernel/yama/ptrace_scope, or try
again as the root user.  For more details, see /etc/sysctl.d/10-ptrace.conf
ptrace: Operation not permitted.
Aborted (core dumped)
ubuntu@panda21:~$

Revision history for this message

Michael Casadevall (mcasadevall) wrote on 2011-03-28:

#20

Download full text (5.3 KiB)

Update on this bug:

After much debugging work with Jani and others on the ARM team, it looks like we're dealing with a race condition somewhere in the ARM JIT code (likely a missing mutex). Mono upstream has not been able to reproduce nor have I been able to successfully isolate the bug. I do however have a workaround patch which forces mono on ARM to run on a single processor which avoids the race condition exposed by banshee and f-spot. While obviously not true fix, this stabilizes mono on multicore ARM systems.

The current patch is as follows:

mcasadevall@daybreak:~/tmp/mono/natty-mono$ bzr diff
=== modified file 'debian/changelog'
--- debian/changelog 2011-02-19 16:59:03 +0000
+++ debian/changelog 2011-03-25 05:39:07 +0000
@@ -1,3 +1,16 @@
+mono (2.6.7-5ubuntu2) natty; urgency=high
+
+ * Backport ARM OP_MEMORY_BARRIER support and GCC workaround from
+ mono 2.10.1. Partial fix forLP: #619981
+ - Following revisions from git:
+ - 7bd422cfeee3622c4ebfe75ba450ca0d664fedbe - Implement
+ mono_memory_barrier () and OP_MEMORY_BARRIER for ARM.
+ - 9c868e2ee43178c8d05161c92489cc9191cc29c7 - Set cfg->uses_rgctx_reg in
+ another code path too on arm, to fix --regression generics.exe.
+ * Disable SMP on ARM by default (Works around LP: #619981)
+
+ -- Michael Casadevall <email address hidden> Tue, 08 Mar 2011 09:56:36 -0800
+
mono (2.6.7-5ubuntu1) natty; urgency=low

* Build packages for ppc64.

=== modified file 'debian/control'
--- debian/control 2011-02-19 16:59:03 +0000
+++ debian/control 2011-03-08 18:08:25 +0000
@@ -1,7 +1,8 @@
Source: mono
Section: cli-mono
Priority: optional
-Maintainer: Debian Mono Group <email address hidden>
+Maintainer: Ubuntu Developers <email address hidden>
+XSBC-Original-Maintainer: Debian Mono Group <email address hidden>
Uploaders: Mirco Bauer <email address hidden>, Sebastian Dröge <email address hidden>, Jo Shields <email address hidden>
Build-Depends: debhelper (>= 7),
dpkg-dev (>= 1.13.19),

=== modified file 'mono/arch/arm/arm-codegen.h'
--- mono/arch/arm/arm-codegen.h 2010-06-06 17:45:35 +0000
+++ mono/arch/arm/arm-codegen.h 2011-03-08 17:40:37 +0000
@@ -1084,6 +1084,16 @@
#define ARM_MOVT_REG_IMM_COND(p, rd, imm16, cond) ARM_EMIT(p, (((cond) << 28) | (3 << 24) | (4 << 20) | ((((guint32)(imm16)) >> 12) << 16) | ((rd) << 12) | (((guint32)(imm16)) & 0xfff)))
#define ARM_MOVT_REG_IMM(p, rd, imm16) ARM_MOVT_REG_IMM_COND ((p), (rd), (imm16), ARMCOND_AL)

+/* MCR */
+#define ARM_DEF_MCR_COND(coproc, opc1, rt, crn, crm, opc2, cond) \
+ ARM_DEF_COND ((cond)) | ((0xe << 24) | (((opc1) & 0x7) << 21) | (0 << 20) | (((crn) & 0xf) << 16) | (((rt) & 0xf) << 12) | (((coproc) & 0xf) << 8) | (((opc2) & 0x7) << 5) | (1 << 4) | (((crm) & 0xf) << 0))
+
+#define ARM_MCR_COND(p, coproc, opc1, rt, crn, crm, opc2, cond) \
+ ARM_EMIT(p, ARM_DEF_MCR_COND ((coproc), (opc1), (rt), (crn), (crm), (opc2), (cond)))
+
+#define ARM_MCR(p, coproc, opc1, rt, crn, crm, opc2) \
+ ARM_MCR_COND ((p), (coproc), (opc1), (rt), (crn), (crm), (opc2), ARMCOND_AL)
+
#ifdef __cplusplus
}
#endif

=== modified file 'mono/mini/cpu-arm.md'
--- mono/mini/cpu-a...

Update on this bug:

After much debugging work with Jani and others on the ARM team, it looks like we're dealing with a race condition somewhere in the ARM JIT code (likely a missing mutex).  Mono upstream has not been able to reproduce nor have I been able to successfully isolate the bug. I do however have a workaround patch which forces mono on ARM to run on a single processor which avoids the race condition exposed by banshee and f-spot. While obviously not true fix, this stabilizes mono on multicore ARM systems.

The current patch is as follows:

mcasadevall@daybreak:~/tmp/mono/natty-mono$ bzr diff
=== modified file 'debian/changelog'
--- debian/changelog	2011-02-19 16:59:03 +0000
+++ debian/changelog	2011-03-25 05:39:07 +0000
@@ -1,3 +1,16 @@
+mono (2.6.7-5ubuntu2) natty; urgency=high
+
+  * Backport ARM OP_MEMORY_BARRIER support and GCC workaround from 
+    mono 2.10.1. Partial fix forLP: #619981
+    - Following revisions from git:
+      - 7bd422cfeee3622c4ebfe75ba450ca0d664fedbe - Implement 
+        mono_memory_barrier () and OP_MEMORY_BARRIER for ARM.
+      - 9c868e2ee43178c8d05161c92489cc9191cc29c7 - Set cfg->uses_rgctx_reg in
+        another code path too on arm, to fix --regression generics.exe.
+  * Disable SMP on ARM by default (Works around LP: #619981)
+
+ -- Michael Casadevall <mcasadevall@ubuntu.com>  Tue, 08 Mar 2011 09:56:36 -0800
+
 mono (2.6.7-5ubuntu1) natty; urgency=low
 
   * Build packages for ppc64.

=== modified file 'debian/control'
--- debian/control	2011-02-19 16:59:03 +0000
+++ debian/control	2011-03-08 18:08:25 +0000
@@ -1,7 +1,8 @@
 Source: mono
 Section: cli-mono
 Priority: optional
-Maintainer: Debian Mono Group <pkg-mono-group@lists.alioth.debian.org>
+Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
+XSBC-Original-Maintainer: Debian Mono Group <pkg-mono-group@lists.alioth.debian.org>
 Uploaders: Mirco Bauer <meebey@debian.org>, Sebastian Dröge <slomo@debian.org>, Jo Shields <directhex@apebox.org>
 Build-Depends: debhelper (>= 7),
 	dpkg-dev (>= 1.13.19),

=== modified file 'mono/arch/arm/arm-codegen.h'
--- mono/arch/arm/arm-codegen.h	2010-06-06 17:45:35 +0000
+++ mono/arch/arm/arm-codegen.h	2011-03-08 17:40:37 +0000
@@ -1084,6 +1084,16 @@
 #define ARM_MOVT_REG_IMM_COND(p, rd, imm16, cond) ARM_EMIT(p, (((cond) << 28) | (3 << 24) | (4 << 20) | ((((guint32)(imm16)) >> 12) << 16) | ((rd) << 12) | (((guint32)(imm16)) & 0xfff)))
 #define ARM_MOVT_REG_IMM(p, rd, imm16) ARM_MOVT_REG_IMM_COND ((p), (rd), (imm16), ARMCOND_AL)
 
+/* MCR */
+#define ARM_DEF_MCR_COND(coproc, opc1, rt, crn, crm, opc2, cond)	\
+	ARM_DEF_COND ((cond)) | ((0xe << 24) | (((opc1) & 0x7) << 21) | (0 << 20) | (((crn) & 0xf) << 16) | (((rt) & 0xf) << 12) | (((coproc) & 0xf) << 8) | (((opc2) & 0x7) << 5) | (1 << 4) | (((crm) & 0xf) << 0))
+
+#define ARM_MCR_COND(p, coproc, opc1, rt, crn, crm, opc2, cond)	\
+	ARM_EMIT(p, ARM_DEF_MCR_COND ((coproc), (opc1), (rt), (crn), (crm), (opc2), (cond)))
+
+#define ARM_MCR(p, coproc, opc1, rt, crn, crm, opc2) \
+	ARM_MCR_COND ((p), (coproc), (opc1), (rt), (crn), (crm), (opc2), ARMCOND_AL)
+
 #ifdef __cplusplus
 }
 #endif

=== modified file 'mono/mini/cpu-arm.md'
--- mono/mini/cpu-arm.md	2010-06-06 17:45:35 +0000
+++ mono/mini/cpu-arm.md	2011-03-08 17:40:37 +0000
@@ -46,7 +46,7 @@
 #
 # See the code in mini-x86.c for more details on how the specifiers are used.
 #
-memory_barrier: len:4
+memory_barrier: len:8 clob:a
 nop: len:4
 relaxed_nop: len:4
 break: len:4

=== modified file 'mono/mini/driver.c'
--- mono/mini/driver.c	2010-06-06 17:45:35 +0000
+++ mono/mini/driver.c	2011-03-25 05:33:36 +0000
@@ -1291,8 +1291,20 @@
 	setlocale (LC_ALL, "");
 
 #if HAVE_SCHED_SETAFFINITY
+
+/**
+ * FIXME: The Mono JIT (mini) is non-SMP safe on ARM currently.
+ *        Force us to be non-SMP unless a we have MONO_FORCE_SMP
+ *        environmental variable set (to allow us to continue to
+ *        debugging efforts
+ **/
+#if defined(__ARM_EABI__)
+	if (!getenv ("MONO_FORCE_SMP")) {
+#else
 	if (getenv ("MONO_NO_SMP")) {
+#endif // __ARM_EABI__
 		unsigned long proc_mask = 1;
+
 #ifdef GLIBC_BEFORE_2_3_4_SCHED_SETAFFINITY
 		sched_setaffinity (getpid(), (gpointer)&proc_mask);
 #else

=== modified file 'mono/mini/mini-arm.c'
--- mono/mini/mini-arm.c	2010-09-14 19:58:16 +0000
+++ mono/mini/mini-arm.c	2011-03-08 17:40:54 +0000
@@ -1055,6 +1055,10 @@
 
 	header = mono_method_get_header (cfg->method);
 
+	/* See mono_arch_get_global_int_regs () */
+	if (cfg->flags & MONO_CFG_HAS_CALLS)
+		cfg->uses_rgctx_reg = TRUE;
+
 	/* 
 	 * We use the frame register also for any method that has
 	 * exception clauses. This way, when the handlers are called,
@@ -2988,6 +2992,8 @@
 
 		switch (ins->opcode) {
 		case OP_MEMORY_BARRIER:
+			ARM_MOV_REG_IMM8 (code, ARMREG_R0, 0);
+			ARM_MCR (code, 15, 0, ARMREG_R0, 7, 10, 5);
 			break;
 		case OP_TLS_GET:
 #ifdef HAVE_AEABI_READ_TP

=== modified file 'mono/utils/mono-membar.h'
--- mono/utils/mono-membar.h	2009-06-14 16:52:28 +0000
+++ mono/utils/mono-membar.h	2011-03-08 17:40:54 +0000
@@ -129,7 +129,7 @@
 #elif defined(__arm__)
 static inline void mono_memory_barrier (void)
 {
-	__asm__ __volatile__ ("" : : : "memory");
+	__asm__ __volatile__ ("mcr p15, 0, %0, c7, c10, 5" : : "r" (0) : "memory");
 }
 
My PPA currently has a new revision of mono with this patch in place, and I'm waiting for independent verification that it properly fixes banshee/f-spot before uploading.

Revision history for this message

Michael Casadevall (mcasadevall) wrote on 2011-03-28:

#21

Jani confirmed this works properly on a clean system. Requesting a beta freeze exception so we get more widespread testing of mono on ARM.

Revision history for this message

Launchpad Janitor (janitor) wrote on 2011-03-28:

#22

This bug was fixed in the package mono - 2.6.7-5ubuntu2

---------------
mono (2.6.7-5ubuntu2) natty; urgency=high

  * Backport ARM OP_MEMORY_BARRIER support and GCC workaround from
    mono 2.10.1. Partial fix forLP: #619981
    - Following revisions from git:
      - 7bd422cfeee3622c4ebfe75ba450ca0d664fedbe - Implement
        mono_memory_barrier () and OP_MEMORY_BARRIER for ARM.
      - 9c868e2ee43178c8d05161c92489cc9191cc29c7 - Set cfg->uses_rgctx_reg in
        another code path too on arm, to fix --regression generics.exe.
  * Disable SMP on ARM by default (Works around LP: #619981)
-- Michael Casadevall <email address hidden> Tue, 08 Mar 2011 09:56:36 -0800

Changed in mono (Ubuntu Natty):
status:	Confirmed → Fix Released

Revision history for this message

Loïc Minier (lool) wrote on 2011-03-28: Re: [Bug 619981] Re: mono apps crash on omap4 due to no smp support for armel

#23

On Mon, Mar 28, 2011, Michael Casadevall wrote:
> --- mono/mini/driver.c 2010-06-06 17:45:35 +0000
> +++ mono/mini/driver.c 2011-03-25 05:33:36 +0000
> @@ -1291,8 +1291,20 @@
> setlocale (LC_ALL, "");
>
> #if HAVE_SCHED_SETAFFINITY
> +
> +/**
> + * FIXME: The Mono JIT (mini) is non-SMP safe on ARM currently.
> + * Force us to be non-SMP unless a we have MONO_FORCE_SMP
> + * environmental variable set (to allow us to continue to
> + * debugging efforts
> + **/
> +#if defined(__ARM_EABI__)
> + if (!getenv ("MONO_FORCE_SMP")) {
> +#else
> if (getenv ("MONO_NO_SMP")) {
> +#endif // __ARM_EABI__
> unsigned long proc_mask = 1;
> +

I didn't find the closing braces for the above new if () { constructs?

--
Loïc Minier

Revision history for this message

Jani Monoses (jani) wrote on 2011-03-28:

#24

There was an if (getenv("MONO_NO_SMP") { there already, the patch only adds another ifdef branch only, the closing } is likely common.

Michael Casadevall (mcasadevall) on 2011-03-28

Changed in mono (Ubuntu Natty):
status:	Fix Released → Confirmed
status:	Confirmed → Fix Released

Tobin Davis (gruemaster) on 2012-02-25

Changed in mono (Ubuntu Maverick):
assignee:	Michael Casadevall (mcasadevall) → nobody
status:	Confirmed → Won't Fix

Ubuntu
mono package

mono apps crash on omap4 due to no smp support for armel

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Affects		Status	Importance	Assigned to	Milestone
	mono (Ubuntu)	Fix Released	High	Michael Casadevall	Ubuntu ubuntu-11.04-beta-1
Nominated for Oneiric by Michael Casadevall
	Maverick	Won't Fix	High	Unassigned
	Natty	Fix Released	High	Michael Casadevall	Ubuntu ubuntu-11.04-beta-1

Ubuntumono package

mono apps crash on omap4 due to no smp support for armel

Bug Description

Related branches

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Ubuntu
mono package