qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 1735384] Re: OpenJDK JVM segfaults on qemu-sh4 (re


From: Alex Bennée
Subject: Re: [Qemu-devel] [Bug 1735384] Re: OpenJDK JVM segfaults on qemu-sh4 (regression)
Date: Mon, 04 Dec 2017 09:29:37 +0000
User-agent: mu4e 1.0-alpha2; emacs 26.0.90

Thomas Huth <address@hidden> writes:

> On 01.12.2017 00:25, John Paul Adrian Glaubitz wrote:
>> The offending commit is:
>> 
>> d25f2a72272b9ffe0d06710d6217d1169bc2cc7d is the first bad commit
>> commit d25f2a72272b9ffe0d06710d6217d1169bc2cc7d
>> Author: Alex Bennée <address@hidden>
>> Date:   Mon Nov 13 13:55:27 2017 +0000
>> 
>>     accel/tcg/translate-all: expand cpu_restore_state addr check
>> 
>>     We are still seeing signals during translation time when we walk over
>>     a page protection boundary. This expands the check to ensure the host
>>     PC is inside the code generation buffer. The original suggestion was
>>     to check versus tcg_ctx.code_gen_ptr but as we now segment the
>>     translation buffer we have to settle for just a general check for
>>     being inside.
>> 
>>     I've also fixed up the declaration to make it clear it can deal with
>>     invalid addresses. A later patch will fix up the call sites.
>> 
>>     Signed-off-by: Alex Bennée <address@hidden>
>>     Reported-by: Peter Maydell <address@hidden>
>>     Reviewed-by: Laurent Vivier <address@hidden>
>>     Reviewed-by: Richard Henderson <address@hidden>
>>     Message-id: address@hidden
>>     Suggested-by: Paolo Bonzini <address@hidden>
>>     Cc: Richard Henderson <address@hidden>
>>     Tested-by: Peter Maydell <address@hidden>
>>     Signed-off-by: Peter Maydell <address@hidden>
>> 
>> :040000 040000 da50c4c43089d3ee7d1e9ad50d3c9036114e5f11 
>> cd6a0dcaa1d284fe5439f6f3b61547d4b0662768 M      accel
>> :040000 040000 c294a7c102d27295f8d81cc06b5d4d17357440ad 
>> 5a1268b7634f69f0806f22161ec7d6a1a26c8812 M      include
>> 
>> Reverting the commit resolves the issue.
>> 
>
> Alex, any ideas what might be wrong here?

It's hard to imagine a scenario where taking the tb_lock() for resolving
something that will fail is going to be an improvement. However maybe
there is a subtle difference with sh4's javavm implementation.

A backtrace QEMU after the segv would be useful here.

-- 
Alex Bennée



reply via email to

[Prev in Thread] Current Thread [Next in Thread]