On 11/30/2016 10:12 AM, Alex Bennée wrote: > > Richard Henderson <r...@twiddle.net> writes: > >> On 11/30/2016 08:55 AM, Alex Bennée wrote: >>> >>> Nikunj A Dadhania <nik...@linux.vnet.ibm.com> writes: >>> >>>> Hi, >>>> >>>> I was writing one instruction and hit following issue: >>>> >>>> [snip]/qemu/tcg/tcg.c:2039: tcg fatal error >>>> qemu-ppc64le: [snip]/qemu/translate-all.c:175: tb_lock: Assertion >>>> `!have_tb_lock' failed. >>>> Segmentation fault (core dumped) >>> >>> This is confusing because something is trying to take the tb_lock while >>> you are in code generation. tb_lock is held for code generation to >>> ensure serialisation of generation. >> >> Yes, I've seen this myself. I never got around to reporting the "problem" >> properly. It's a confusing side effect of a SIGSEGV arriving during tcg code >> generation. The signal handler longjmps back with unexpected locks >> held. > > So this is a SEGV which belongs to the translation code rather than the > guest?
Yes. > There are places in the cpu loop where we exit that should reset the > locks on a restart - see tb_lock_reset() so I'm not quite sure what has > happened here. It should be easy enough to force a segv from within the compile step to reproduce this. r~
