** Changed in: qemu-linaro
Status: Fix Committed => Fix Released
** Changed in: qemu
Status: Fix Committed => Fix Released
** Changed in: qemu-linaro
Milestone: None => 2013.06
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribe
** Changed in: qemu-linaro
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/668799
Title:
qemu-arm segfaults executing msgmerge (gettext)
Status in QEMU:
** Changed in: qemu-linaro
Status: New => In Progress
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/668799
Title:
qemu-arm segfaults executing msgmerge (gettext)
Status in QEMU:
Fix Commi
Patches have now been committed to QEMU which fix the subset of
"multithreaded guests crash" which this bug covers [ie ones where there
was a race between tb_unlink_cpu() and the cpu thread using or modifying
the TB graph], so I'm closing this bug.
Note that there are still other classes of QEMU b
The test I'm using in LP:1098729 hangs or segfaults nearly every single
run.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/668799
Title:
qemu-arm segfaults executing msgmerge (gettext)
Status in
Just a note.
We still have this issue when building unity on ARM. It crashed when
running msgmerge.
** Also affects: qemu-linaro
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bu
For information, I'm *not* able to reproduce this problem with:
* QEMU user-mode v1.0.1
* host system: Slackware64-current
* guest system: Slackware/ARM 13.37
* build command: gcc -fopenmp 668799.c -o 668799 -static
* run commands:
* ./668799
* OMP_NUM_THREAD
Am Mittwoch, 1. Dezember 2010, 20:40:37 schrieb Peter Maydell:
> On 28 November 2010 11:24, Peter Maydell wrote:
> > 2010/11/28 Brian Harring :
> >> Additional note... it *looks* like the deadlock potential is there
> >> already in 0.13, it's just heavily exacerbated by this patch- out of
> >> abo
On 28 November 2010 11:24, Peter Maydell wrote:
> 2010/11/28 Brian Harring :
>> Additional note... it *looks* like the deadlock potential is there
>> already in 0.13, it's just heavily exacerbated by this patch- out of
>> about 600 builds I've seen 2 lockup in the same fashion (rate was far
>> hig
On 11/28/2010 11:37 AM, Brian Harring wrote:
> Additional note... it *looks* like the deadlock potential is there
> already in 0.13, it's just heavily exacerbated by this patch- out of
> about 600 builds I've seen 2 lockup in the same fashion (rate was far
> higher with the patch on this ticket).
>
2010/11/28 Brian Harring :
> Additional note... it *looks* like the deadlock potential is there
> already in 0.13, it's just heavily exacerbated by this patch- out of
> about 600 builds I've seen 2 lockup in the same fashion (rate was far
> higher with the patch on this ticket).
Thanks for the tes
Additional note... it *looks* like the deadlock potential is there
already in 0.13, it's just heavily exacerbated by this patch- out of
about 600 builds I've seen 2 lockup in the same fashion (rate was far
higher with the patch on this ticket).
--
qemu-arm segfaults executing msgmerge (gettext)
h
@Peter, that patch, against 0.13 results in some odd deadlocks;
specifically a racey deadlock during signal handling best I can tell.
Attached is an strac'ing of the make process- nothing special, just
forking off some children, wait'ing on the results- if you look earlier
in the log you'll see th
The following patch stops the segfault (which happens because
cpu_unlink_tb() is fiddling with the links between tbs without taking
the tb_lock, so another thread can come in via eg tb_add_jump() and
cause corruption of the linked lists). However, there are a number of
comments in the TB handling c
To me it looks like racy/double lockings. We already lock meantime
before some functions up the code-path of cpu_unlink_tb . IMHO the
spinlock in cpu_unlink_tb is now unnecessary - at least in this code-
path. Maybe we exit the cpu before the previous/upper lock is released.
HTH, have phun!
--
qe
See linux-user/main.c function start_exclusive.
--
qemu-arm segfaults executing msgmerge (gettext)
https://bugs.launchpad.net/bugs/668799
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Status in QEMU: New
Bug description:
upstream q
Thanks for the test case. I can confirm that I can reproduce this. (Detail:
compiled with "gcc -fopenmp 668799.c -o 668799 -static" on an Ubuntu maverick
ARM system. qemu-arm-user on x86-64 then segfaults when run with
"OMP_NUM_THREADS=6 ./arm-linux-user/qemu-arm /tmp/668799".) The point when it
Alternative testcase:
compile and "export OMP_NUM_THREADS=6" before running.
/**
* FILE: omp_mm.c
* DESCRIPTION:
* OpenMp Example - Matrix Multiply - C Version
* Demonstrates a matrix multiply using OpenMP. Threads
We always see this in :
exec.c1662:
void cpu_exit(CPUState *env)
{
cpu_unlink_tb(env);
env->exit_request = 1;
}
A quick test with the statement cpu_unlink_tb(env) removed passed the test.
--
qemu-arm segfaults executing msgmerge (gettext)
https://bugs.launchpad.net/bugs/668799
You rec
19 matches
Mail list logo
