[OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI up-call made whilst holding JNI critical lock.
philip.race at oracle.com
Fri Sep 23 16:40:17 UTC 2016
You can't re-use the 9 bug ID in 9. So you will need to create a new bug
that in 9.
But for 8u it can be part of this fix .. it would be weird to knowingly
a problem just so you could fix it separately.
On 9/23/16, 12:13 AM, Jayathirth D V wrote:
> Hi Phil,
> I assumed setjmp/longjmp functions to be internal error handling
> mechanism rather than C standard library functions which provide
> non-local jumps.
> I verified setjmp/longjmp usage in ImageIO JPEG context and we need
> that RELEASE_ARRAYS() call in writeImage() which I have removed.
> Does I have to create a new Bug and add the RELEASE_ARRAY() call in
> writeImage() or I have to check-in this change under JDK-8162461 only?
> After check-in of this modification I will raise new webrev for 8u
> *From:*Philip Race
> *Sent:* Thursday, September 22, 2016 9:51 PM
> *To:* Jayathirth D V
> *Cc:* 2d-dev
> *Subject:* Re: [OpenJDK 2D-Dev] [8u] RFR JDK-8162461: Hang due to JNI
> up-call made whilst holding JNI critical lock.
> I see this is mostly what I approved for JDK9 but I noticed you made a
> after I approved it and I did not see or approve the updated version.
> I am concerned about this comment you posted for the JDK 9 webrev :
> >Regarding "2856 RELEASE_ARRAYS(env, data, (const JOCTET
> >We don't need this RELEASE_ARRAY() call at this place as we have not
> yet pinned any buffer.
> > So I have removed it.
> >Please find updated webrev for review :
> What makes you so sure we have not pinned a buffer by then ?
> setjmp is special. It may return from any point in the writing process.
> In other words that removal looks wrong to me.
> On 9/15/16, 1:29 AM, Jayathirth D V wrote:
> Please review the following backport to JDK-8u from JDK-9 at your
> JDK-9 review thread :
> Bug : https://bugs.openjdk.java.net/browse/JDK-8162461
> JDK-8u Webrev :
> Issue : If we try to perform operations like
> reader.abort()/reader.dispose()/ reader.reset() in any of the
> IIOReadUpdateListener callbacks, JVM will throw deadlock error.
> Root cause : We are making callbacks from native side to Java by
> holding some resources in JNI critical lock.
> Solution : We have to release the JNI critical lock on the
> resources before we call Java function from native side. If we
> have JNI critical lock and we throw an Exception in that case also
> we should release the lock.
> I have verified jtreg, JCK and JPRT in JDK8u-dev also.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the 2d-dev