Pavel Dovgalyuk <dovga...@ispras.ru> writes: >> From: Stefan Hajnoczi [mailto:stefa...@gmail.com] >> On Wed, Dec 21, 2016 at 5:57 AM, Pavel Dovgalyuk <dovga...@ispras.ru> wrote: >> >> -----Original Message----- >> >> From: Stefan Hajnoczi [mailto:stefa...@gmail.com] >> >> On Tue, Dec 20, 2016 at 11:10 AM, Pavel Dovgalyuk <dovga...@ispras.ru> >> >> wrote: >> >> >> From: Stefan Hajnoczi [mailto:stefa...@gmail.com] >> >> >> On Tue, Dec 20, 2016 at 10:45:44AM +0300, Pavel Dovgalyuk wrote: >> >> >> > It also fails much earlier when I enable logs with "-d int -D log". >> >> >> > >> >> >> Looks like a heap corruption bug since free() is failing. >> >> > >> >> > Seems to be a race condition. >> >> > When I add logs into invalidate_page_bitmap, the bug disappears. >> >> > It seems that someone tries to free the same page bitmap twice and >> >> > simultaneously. >> >> >> >> Does the following workaround prevent the crashes? >> >> >> >> -global apic-common.vapic=off >> > >> > Yes, this option helps. >> > Thank you. >> >> Good news. This can be fixed in 2.8.1 once someone finds a solution. > > It seems that something still goes wrong. > I'm using this workaround, but there is a kind of deadlock in translation. > call_rcu_thread hangs at some moment in qemu_event_wait. > > As far as I understand, it is used by QHT in translate-all.c. > I can't get more information yet, because logging makes everything too slow.
There are a number of users of RCU bit for QHT I think it only gets activated when it needs to re-size its hash table on insertion of new TranslationBlocks. Can you get a backtrace of all threads when it deadlocks? -- Alex Bennée
