RFR(m): 8074552: SafeFetch32 and SafeFetchN do not work in error handling
Thomas Stüfe
thomas.stuefe at gmail.com
Mon Mar 9 16:30:34 UTC 2015
Hi David,
I see now that only Windows 32bit is broken. I will investigate this.
Thomas
On Mon, Mar 9, 2015 at 4:12 PM, Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:
> Hi David,
>
> I am sorry, but I am unable to reproduce the error. Both slowdebug and
> fastdebug builds on Windows come up and SafeFetch works (also in error
> handling). Are you sure the crash is caused by my change? If yes, could you
> send me an hs-err file or at least the configure line you used for building?
>
> Kind Regards, Thomas
>
> On Mon, Mar 9, 2015 at 7:51 AM, David Holmes <david.holmes at oracle.com>
> wrote:
>
>> On 9/03/2015 4:21 PM, Thomas Stüfe wrote:
>>
>>> Hi David,
>>>
>>> Ouch. The only thing I can think about are the added initialization
>>> tests in stubRoutines.cpp. I will check this.
>>>
>>
>> Ah! It hadn't registered with me that this test code was going to be
>> executed. Seems the likely cause as a clean repo has no problems.
>>
>> David
>>
>> Kind Regards, Thomas
>>>
>>>
>>>
>>> On Mon, Mar 9, 2015 at 6:56 AM, David Holmes <david.holmes at oracle.com
>>> <mailto:david.holmes at oracle.com>> wrote:
>>>
>>> Hi Thomas,
>>>
>>> FYI When I applied this to latest hs-rt forest and ran through JPRT
>>> the Windows fastdebug builds were DOA (instant segfault just running
>>> "java -version"). Can't see how your changes could do this so
>>> running a test on unmodified forest.
>>>
>>> David
>>>
>>>
>>> On 9/03/2015 9:40 AM, David Holmes wrote:
>>>
>>> Hi Thomas,
>>>
>>> Minor nit: in
>>> src/share/vm/runtime/__stubRoutines.cpp::test___safefetchN can
>>> you use UCONST64 macro instead of explicit ULL - thanks.
>>>
>>> Otherwise this seems okay, but we will also need the aarch64
>>> component
>>> (and I'll look into our internal needs).
>>>
>>> Thanks,
>>> David
>>>
>>> On 7/03/2015 2:10 AM, Thomas Stüfe wrote:
>>>
>>> Hi all,
>>>
>>> could someone please review the following fix (I also will
>>> need a
>>> sponsor):
>>>
>>> http://cr.openjdk.java.net/~__stuefe/webrevs/8074552/webrev.
>>> __01/
>>> <http://cr.openjdk.java.net/~stuefe/webrevs/8074552/webrev.
>>> 01/>
>>>
>>> https://bugs.openjdk.java.net/__browse/JDK-8074552
>>>
>>> <https://bugs.openjdk.java.net/browse/JDK-8074552>
>>>
>>> The fix will make SafeFetch[32,N] work in error reporting.
>>>
>>> At SAP, we use SafeFetch a lot in error reporting to poke
>>> around in
>>> potentially invalid memory (e.g. writing hex dumps over
>>> areas which
>>> may be
>>> partly unmapped), and we feel that this could be useful for
>>> the
>>> OpenJDK too.
>>>
>>> Without this fix, SafeFetch will cause a crash, the current
>>> error
>>> reporting
>>> step will be interrupted and error reporting will continue
>>> with the next
>>> step; that is not optimal because the interrupted step may
>>> have shown
>>> valuable information.
>>>
>>> This fix handles SafeFetch faults during error reporting the
>>> same way as
>>> they are handled normally. The changes are:
>>>
>>> - handle safe fetch fault in the various (os_cpu dependend)
>>> secondary
>>> signal handlers
>>>
>>> - provide a function to check if it is safe to use SafeFetch:
>>> CanUseSafeFetch32(). SafeFetch needs stub routines and will
>>> crash when
>>> used
>>> before stub generation.
>>>
>>> - set_context_pc() is added which complements the existing
>>> get_context_pc()
>>> and all instances where the pc in ucontext_t was modified
>>> directly are
>>> changed to use set_context_pc()
>>>
>>> - in stubRoutines.cpp, a small test was added to the already
>>> existing
>>> stub
>>> routines tests which run at VM init
>>>
>>> - in vmError.cpp, a test was added to test SafeFetch during
>>> error
>>> reporting, similar to the tests introduced for 8065895
>>>
>>> - A JTreg test was added
>>>
>>> Thanks and Kind Regards,
>>>
>>> Thomas Stuefe
>>>
>>>
>>>
>
More information about the hotspot-runtime-dev
mailing list