From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: segmentation fault in qemu-kvm-0.14.0 Date: Wed, 09 Mar 2011 11:20:05 +0100 Message-ID: <4D775455.10607@web.de> References: <2640D58E-2101-47FA-99B6-28815666651E@dlh.net> <4D772E4C.6020604@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig999A7452C4A5DF0A892EC319" Cc: qemu-devel , kvm@vger.kernel.org To: Peter Lieven Return-path: Received: from fmmailgate03.web.de ([217.72.192.234]:46422 "EHLO fmmailgate03.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757004Ab1CIKUH (ORCPT ); Wed, 9 Mar 2011 05:20:07 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig999A7452C4A5DF0A892EC319 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2011-03-09 11:16, Peter Lieven wrote: >=20 > Am 09.03.2011 um 08:37 schrieb Jan Kiszka: >=20 >> On 2011-03-08 23:53, Peter Lieven wrote: >>> Hi, >>> >>> during testing of qemu-kvm-0.14.0 i can reproduce the following segfa= ult. i have seen similar crash already in 0.13.0, but had no time to debu= g. >>> my guess is that this segfault is related to the threaded vnc server = which was introduced in qemu 0.13.0. the bug is only triggerable if a vnc= >>> client is attached. it might also be connected to a resolution change= in the guest. i have a backtrace attached. the debugger is still running= if someone >>> needs more output >>> >> >> ... >> >>> Thread 1 (Thread 0x7ffff7ff0700 (LWP 29038)): >>> #0 0x0000000000000000 in ?? () >>> No symbol table info available. >>> #1 0x000000000041d669 in main_loop_wait (nonblocking=3D0) >>> at /usr/src/qemu-kvm-0.14.0/vl.c:1388 >> >> So we are calling a IOHandlerRecord::fd_write handler that is NULL. >> Looking at qemu_set_fd_handler2, this may happen if that function is >> called for an existing io-handler entry with non-NULL write handler, >> passing a NULL write and a non-NULL read handler. And all this without= >> the global mutex held. >> >> And there are actually calls in vnc_client_write_plain and >> vnc_client_write_locked (in contrast to vnc_write) that may generate >> this pattern. It's probably worth validating that the iothread lock is= >> always held when qemu_set_fd_handler2 is invoked to confirm this race >> theory, adding something like >> >> assert(pthread_mutex_trylock(&qemu_mutex) !=3D 0); >> (that's for qemu-kvm only) >=20 > qemu_mutex doesn't exists (anymore). i can only find qemu_global_mutex = and qemu_fair_mutex. In qemu-kvm, qemu-kvm.c contains that lock. In upstream, it's qemu_global_mutex, but you will have to enable --enable-io-thread and export it. >=20 > i try with qemu_global_mutex now. if thats not correct please tell. I think we knokw know the call path, so you could also wait for Corentin to send a patch and test that one. Jan --------------enig999A7452C4A5DF0A892EC319 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org/ iEUEARECAAYFAk13VFUACgkQitSsb3rl5xTe5QCXVMb63x0kMjPvJRVKTtecS/LL mQCfbde8R/x12IWAcpS3iPXZ/dKNrWE= =Z0c/ -----END PGP SIGNATURE----- --------------enig999A7452C4A5DF0A892EC319--