qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] linux-user crashing in multi-threaded programs


From: Alexander Graf
Subject: [Qemu-devel] linux-user crashing in multi-threaded programs
Date: Mon, 21 Nov 2011 03:05:07 +0100

Howdy,

In an adventure to find out why yast2-core fails in its testsuite during build 
on ARM for us, I dove into the code for a bit and debugged it down to our old 
friend: multi-threaded TB invalidation.

I have a nice test case at

  http://csgraf.de/tmp/yast2-core.tbz2

which you can easily use to reproduce the race. I run it using the following 
command line:

  qemu-arm -L yast2-core yast2-core/bin/test_thread_log.prg

It breaks pretty much every single time.

Apparently two threads try to modify jmp_next at the same time, rendering the 
whole invalidation racy. The following patch triggers while in normal 
single-threaded worlds it should never appear:

diff --git a/exec.c b/exec.c
index 6b92198..0c48222 100644
--- a/exec.c
+++ b/exec.c
@@ -1356,6 +1356,7 @@ static inline void 
tb_reset_jump_recursive2(TranslationBlock *tb, int n)
             tb1 = (TranslationBlock *)((long)tb1 & ~3);
             if (n1 == 2)
                 break;
+            assert(tb1);
             tb1 = tb1->jmp_next[n1];
         }
         /* we are now sure now that tb jumps to tb1 */


So how do I know it's a race in the chaining code? Well, it only happens with 
threaded code. And it only happens when actually chaining. The following patch 
makes the test case work:

diff --git a/exec-all.h b/exec-all.h
index c211242..c8124e9 100644
--- a/exec-all.h
+++ b/exec-all.h
@@ -259,6 +259,7 @@ static inline void tb_set_jmp_target(TranslationBlock *tb,
 static inline void tb_add_jump(TranslationBlock *tb, int n,
                                TranslationBlock *tb_next)
 {
+    if(1) return;
     /* NOTE: this test is only needed for thread safety */
     if (!tb->jmp_next[n]) {
         /* patch the native jump address */


I would advice against using it as a real fix though, as it effectively 
disables TB chaining, rendering all of QEMU pretty slow.


Does anyone have pending patches, approaches or ideas on how to fix this? It 
seems to be the last big road block towards getting linux-user actually 
workable for us.


Alex




reply via email to

[Prev in Thread] Current Thread [Next in Thread]