From: Jan Kiszka <jan.kiszka@web.de>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Re: [linux-user] Fixed Qemu crash using Gdbstub
Date: Sat, 13 Dec 2008 13:59:34 +0100 [thread overview]
Message-ID: <4943B1B6.9010707@web.de> (raw)
In-Reply-To: <1229171501.3898.53.camel@cocoduo.atr>
[-- Attachment #1: Type: text/plain, Size: 3009 bytes --]
Lionel Landwerlin wrote:
> Le samedi 13 décembre 2008 à 11:16 +0100, Jan Kiszka a écrit :
>> Lionel Landwerlin wrote:
>>> I just forgot to remove 2 printf ...
>>> Here the good patch :
>>>
>>>
>>>
>>>
>>> >From 2b3fe65ea3f2ee8dd3efbb52b66a2f4e53b788ea Mon Sep 17 00:00:00 2001
>>> From: Lionel Landwerlin <lionel.landwerlin@openwide.fr>
>>> Date: Sat, 13 Dec 2008 00:32:04 +0100
>>> Subject: [PATCH] [linux-user] Fixed Qemu crash using Gdbstub
>>>
>>> When using gdb with qemu (via gdbstub), if your emulated
>>> application is multithreaded and does a segfault then qemu
>>> crashes.
>>>
>>> Qemu crashes because the break/watch points are shared between
>>> cpus. The TAILQ structure which handles the list of break/watch
>>> points is copied inside each CPUState structure. When the last
>>> breakpoint is removed (this happens on a segfault), it is
>>> removed across all cpus but because of the copied TAILQ
>>> structure a same breakpoint can be freed N times with N the
>>> current number of cpus.
>> OK, now I got the problem: user space emulation spawns additional VCPUs
>> to emulate fork. Those VCPUs are cloned via cpu_copy which simply
>> duplicates the CPUState of the parent, including the breakpoint and
>> watchpoint TAILQ headers. This is doomed to fail.
>>
>> But your approach to let the cloned VCPU point to the same TAILQ header
>> as its parent is not correct as well. It will cause troubles to gdbstub
>> which manages breakpoints on all VCPUs by adding duplicate instances on
>> a per-VCPU base. If you inject a breakpoint before a fork and then
>> remove it afterwards, gdbstub will report an error because it will only
>> find the breakpoint once, not n times (n = number of VCPUs).
>>
>> What you have to do is to cleanly duplicate the breakpoint and
>> watchpoint lists on cpu_copy (filter out BP_CPU types for cleanness
>> reasons, although they do not occur in user emulation ATM).
>
> Hello Jan,
>
> Thanks for reviewing my patch.
>
> Duplication of all break/watchpoints will makes the patch bigger,
> because it will required break/watchpoint_copy functions etc...
>
> Another problem is that threads are also emulated by vcpus in user
> emulation. But we also need to share break/watchpoints between threads.
> This explain the way my patch do the thing.
>
> Finally, this makes the modification a lot more complicated than what I
> expected, because breakpoints on emulated forks should not apply.
Sorry, but shouldn't we prefer correct solutions over simpler but broken
ones...?
Before my gdbstub changes, break/watchpoints were per-VCPU and
automatically duplicated on cpu_copy (as they were stored in a static
array inside CPUState). Now they are kept in lists, but still per-VCPU.
All that has to be done now is to fix cpu_copy to take this into
account. If that takes additional simple helpers to clone breakpoints,
so what?
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]
next prev parent reply other threads:[~2008-12-13 13:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-12 23:52 [Qemu-devel] [linux-user] Fixed Qemu crash using Gdbstub Lionel Landwerlin
2008-12-13 0:00 ` Lionel Landwerlin
2008-12-13 8:26 ` [Qemu-devel] " Jan Kiszka
2008-12-13 10:16 ` Jan Kiszka
2008-12-13 12:31 ` Lionel Landwerlin
2008-12-13 12:59 ` Jan Kiszka [this message]
2008-12-13 13:21 ` Lionel Landwerlin
2008-12-13 13:49 ` Jan Kiszka
2008-12-13 17:37 ` Lionel Landwerlin
2008-12-14 14:17 ` Jan Kiszka
2008-12-14 19:34 ` Lionel Landwerlin
2008-12-28 22:21 ` Lionel Landwerlin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4943B1B6.9010707@web.de \
--to=jan.kiszka@web.de \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.