JDK-8261646 : Crash in MTLBlitLoops when Metal API Validation enabled
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: internal
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: os_x
  • CPU: generic
  • Submitted: 2021-02-12
  • Updated: 2021-02-19
  • Resolved: 2021-02-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
internalFixed
Related Reports
Relates :  
JDK-8261620 - Running metal with API validation crashes immediately
Description
If we enable Metal API Validation and launch J2DDemo.
Jump between tabs for sometime(Dont click on Clipping tab for that we have open bug : https://bugs.openjdk.java.net/browse/JDK-8261638)

J2DTrace enabled fastdebug logs :
MTLBlitLoops_IsoBlit [tx=1, xf=0, AC=SRC_OVER]: src=0x7fd526990400 [tex=0x7fd527d89950, 5x3, O=0], dst=0x7fd52728a480 [tex=0x7fd528309860, 1702x1158, O=0] | (0, 0, 5, 3)->(10.00, 28.00, 20.00, 34.00)[V]  [via sampling]
[V] MTLContext : commandBuffer is NULL
[V] MTLRenderQueue_flushBuffer: opcode=31, rem=156
MTLBlitLoops_IsoBlit [tx=1, xf=0, AC=SRC_OVER]: src=0x7fd526975b50 [tex=0x7fd527d8f570, 5x1, O=0], dst=0x7fd52728a480 [tex=0x7fd528309860, 1702x1158, O=0] | (0, 0, 5, 1)->(10.00, 34.00, 20.00, 348.00)[V]  [via sampling]
[V] MTLRenderQueue_flushBuffer: opcode=31, rem=84
MTLBlitLoops_IsoBlit [tx=1, xf=0, AC=SRC_OVER]: src=0x7fd526975bf0 [tex=0x7fd5269d2910, 5x3, O=0], dst=0x7fd52728a480 [tex=0x7fd528309860, 1702x1158, O=0] | (0, 0, 5, 3)->(10.00, 348.00, 20.00, 354.00)[V]  [via sampling]
[V] MTLRenderQueue_flushBuffer: opcode=90, rem=12
[V] MTLRenderQueue_flushBuffer: opcode=71, rem=8
[V]   desired texture dimensions: w=50 h=50 max=16384
[V] MTLSurfaceData_initTexture: w=50 h=50 bp=0x7fd52a34aa00 [tex=0x7fd529462cf0] opaque=0 rtt=0
[I] MTLRenderQueue_flushBuffer: limit=88
[V] MTLRenderQueue_flushBuffer: opcode=90, rem=84
[V] MTLRenderQueue_flushBuffer: opcode=71, rem=80
[V] MTLRenderQueue_CheckPreviousOp: new op=7
[V] MTLRenderQueue_flushBuffer: opcode=31, rem=68
MTLBlitLoops_Blit [tx=1, xf=0, AC=SRC_OVER]: bdst=0x7fd52a34aa00 [tex=0x7fd529462cf0, 50x50, O=0], src=0x7fd528ff4f60 (50x50) O=0 premul=1 | (0, 0, 50, 50)->(0.00, 0.00, 50.00, 50.00)[V] replaceTextureRegion src (dw, dh) : [50, 50] dest (dx1, dy1) =[0, 0]
[V] MTLContext : commandBuffer is NULL
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x00007fff59e2cd3c, pid=16575, tid=73227
#
# JRE version: Java(TM) SE Runtime Environment (17.0) (fastdebug build 17-internal+0-adhoc.jdv.open)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-internal+0-adhoc.jdv.open, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, bsd-amd64)
# Problematic frame:
# C  [MetalTools+0x9d3c]  -[MTLToolsCommandBuffer commit]+0x5d

In MTLBlitLoops_replaceTextureRegion we have commandbuffer commit and also usage of Compute Encoder.

I have attached crash log also.
Even with release build + Metal API validation issue is easily reproducible.

This can be reproduced even in SwingSet2 by launching it with Metal API validation and clicking on different things.
Comments
No performance impact of the patch found. I'm going to integrate it.
19-02-2021
Tried on mac mini 2018 and macbook pro 2012 - the issue is not reproducible with the recent sources. Could you please verify this issue on macBook pro 13" 2015 once more.
19-02-2021
The fix is safe (if it works) I'm only worrying about the performance impact.
17-02-2021
I'm unable to reproduce the failure. The demo always works on my machines.
17-02-2021
Alexey, will you be trying that patch ?
17-02-2021
Looks to be related to texture access synchronisation. If we force commit blitencoder call in replaceTextureRegion i see that crash doesnt happen. Force commit in repalceTextureRegion used : diff --git a/src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m b/src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m index 6b22a18d0fd..9e1f31c1176 100644 --- a/src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m +++ b/src/java.desktop/macosx/native/libawt_lwawt/java2d/metal/MTLBlitLoops.m @@ -213,6 +213,13 @@ void drawTex2Tex(MTLContext *mtlc, toTexture:dest destinationSlice:0 destinationLevel:0 destinationOrigin:MTLOriginMake(dx1, dy1, 0)]; [blitEncoder endEncoding]; + [mtlc.encoderManager endEncoder]; + MTLCommandBufferWrapper * cbwrapper = [mtlc pullCommandBufferWrapper]; + id<MTLCommandBuffer> commandbuf = [cbwrapper getCommandBuffer]; + [commandbuf addCompletedHandler:^(id <MTLCommandBuffer> commandbuf) { + [cbwrapper release]; + }]; + [commandbuf commit]; } }
14-02-2021
This is easily reproducible on macBook pro 13" 2015 - macOS 10.15.7 This is not reproducible on macBook pro 16" 2019 - macOS 11.1
12-02-2021
Easiest way to reproduce this is- 1) Enable metal validation 2) Launch SwingSet2 with metal pipeline 3) Resize the SwingSet2 window slightly by mouse
12-02-2021