Steps: 1. Download and install chrome, open the link, https://www.khronos.org/registry/webgl/sdk/tests/conformance2/textures/misc/tex-base-level-bug.html?webglVersion=2&quiet=0 2. Crash happens. Notes: This issue cannot be reproduced on Ubuntu 18.04 system graphics drivers. It only could be reproduced on git mesa master and seems that there is a regression. The crash stack: romium/src/out/Debug/chrome --type=gpu-process --field-trial-handle=17795898598484613598,10625606198856481036,131072 --gpu-preferences=KAAAAAAAAACAAABAAQAAAAAAAAAAAGAAAAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAA --service-request-channel-token=15512887321706573271: intel_tex_validate.c:161: intel_finalize_mipmap_tree: Assertion `intel_miptree_match_image(intelObj->mt, &intelImage->base.Base)' failed. Received signal 6 #0 0x7f4f0ae16bcd base::debug::StackTrace::StackTrace() #1 0x7f4f0ab229ac base::debug::StackTrace::StackTrace() #2 0x7f4f0ae16624 base::debug::(anonymous namespace)::StackDumpSignalHandler() #3 0x7f4ee4875890 <unknown> #4 0x7f4ee0542e97 gsignal #5 0x7f4ee0544801 abort #6 0x7f4ee053439a <unknown> #7 0x7f4ee0534412 __assert_fail #8 0x7f4ecddd8aa8 <unknown> #9 0x7f4ecddd8b84 <unknown> #10 0x7f4ecdd9a17f <unknown> #11 0x7f4ecdb0ba82 <unknown> #12 0x7f4ecdb0c7ac <unknown> #13 0x7f4ef89927a9 gl::GLApiBase::glDrawArraysFn() #14 0x7f4ef89f97ff gl::RealGLApi::glDrawArraysFn() #15 0x7f4ef42494c1 gpu::gles2::GLES2DecoderImpl::DoDrawArrays() #16 0x7f4ef41e50bd gpu::gles2::GLES2DecoderImpl::HandleDrawArrays() #17 0x7f4ef426d88c gpu::gles2::GLES2DecoderImpl::DoCommandsImpl<>() #18 0x7f4ef422d695 gpu::gles2::GLES2DecoderImpl::DoCommands() #19 0x7f4f00c6b8dd gpu::CommandBufferService::Flush() #20 0x7f4edf10dfad gpu::CommandBufferStub::OnAsyncFlush() #21 0x7f4edf11cba4 _ZN4base20DispatchToMethodImplIPN3gpu17CommandBufferStubEMS2_FvijENSt3__15tupleIJijEEEJLm0ELm1EEEEvRKT_T0_OT1_NS6_16integer_sequenceImJXspT2_EEEE #22 0x7f4edf11cad8 _ZN4base16DispatchToMethodIPN3gpu17CommandBufferStubEMS2_FvijENSt3__15tupleIJijEEEEEvRKT_T0_OT1_ #23 0x7f4edf11ca64 _ZN3IPC16DispatchToMethodIN3gpu17CommandBufferStubEMS2_FvijEvNSt3__15tupleIJijEEEEEvPT_T0_PT1_OT2_ #24 0x7f4edf116b73 _ZN3IPC8MessageTI35GpuCommandBufferMsg_AsyncFlush_MetaNSt3__15tupleIJijEEEvE8DispatchIN3gpu17CommandBufferStubES8_vMS8_FvijEEEbPKNS_7MessageEPT_PT0_PT1_T2_ #25 0x7f4edf10bc4d gpu::CommandBufferStub::OnMessageReceived() #26 0x7f4f0757e998 IPC::MessageRouter::RouteMessage() #27 0x7f4edf130220 gpu::GpuChannel::HandleMessageHelper() #28 0x7f4edf12bd2b gpu::GpuChannel::HandleMessage() #29 0x7f4edf120def _ZN4base8internal13FunctorTraitsIMN3gpu17CommandBufferStubEFvRKNS2_9SyncTokenEEvE6InvokeIS8_RKNS_7WeakPtrIS3_EEJS6_EEEvT_OT0_DpOT1_ #30 0x7f4edf120d55 _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN3gpu17CommandBufferStubEFvRKNS4_9SyncTokenEERKNS_7WeakPtrIS5_EEJS8_EEEvOT_OT0_DpOT1_ #31 0x7f4edf120ccd _ZN4base8internal7InvokerINS0_9BindStateIMN3gpu17CommandBufferStubEFvRKNS3_9SyncTokenEEJNS_7WeakPtrIS4_EES5_EEEFvvEE7RunImplIRKS9_RKNSt3__15tupleIJSB_S5_EEEJLm0ELm1EEEEvOT_OT0_NSI_16integer_sequenceImJXspT1_EEEE #32 0x7f4edf13a7e9 _ZN4base8internal7InvokerINS0_9BindStateIMN3gpu10GpuChannelEFvRKN3IPC7MessageEEJNS_7WeakPtrIS4_EES6_EEEFvvEE7RunOnceEPNS0_13BindStateBaseE #33 0x7f4f00c69e9e _ZNO4base12OnceCallbackIFvvEE3RunEv #34 0x7f4f00c7efcc gpu::Scheduler::RunNextTask() #35 0x7f4f00c8fc6f _ZN4base8internal13FunctorTraitsIMN3gpu9SchedulerEFvvEvE6InvokeIS5_RKNS_7WeakPtrIS3_EEJEEEvT_OT0_DpOT1_ #36 0x7f4f00c8fbea _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMN3gpu9SchedulerEFvvERKNS_7WeakPtrIS5_EEJEEEvOT_OT0_DpOT1_ #37 0x7f4f00c8fb80 _ZN4base8internal7InvokerINS0_9BindStateIMN3gpu9SchedulerEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE7RunImplIRKS6_RKNSt3__15tupleIJS8_EEEJLm0EEEEvOT_OT0_NSF_16integer_sequenceImJXspT1_EEEE #38 0x7f4f00c8fabc _ZN4base8internal7InvokerINS0_9BindStateIMN3gpu9SchedulerEFvvEJNS_7WeakPtrIS4_EEEEEFvvEE3RunEPNS0_13BindStateBaseE #39 0x7f4f0aad13ee _ZNO4base12OnceCallbackIFvvEE3RunEv #40 0x7f4f0ab23e72 base::debug::TaskAnnotator::RunTask() #41 0x7f4f0abb5d26 base::MessageLoop::RunTask() #42 0x7f4f0abb60ae base::MessageLoop::DeferOrRunPendingTask() #43 0x7f4f0abb6539 base::MessageLoop::DoWork() #44 0x7f4f0abbd81c base::MessagePumpGlib::HandleDispatch() #45 0x7f4f0abbdf71 base::(anonymous namespace)::WorkSourceDispatch() #46 0x7f4ee2789287 g_main_context_dispatch #47 0x7f4ee27894c0 <unknown> #48 0x7f4ee278954c g_main_context_iteration #49 0x7f4f0abbd90f base::MessagePumpGlib::Run() #50 0x7f4f0abb541b base::MessageLoop::Run() #51 0x7f4f0ac5d92d base::RunLoop::Run() #52 0x7f4f02bfb7be content::GpuMain() #53 0x7f4f05ed1522 content::RunOtherNamedProcessTypeMain() #54 0x7f4f05ed3bde content::ContentMainRunnerImpl::Run() #55 0x7f4f05ec8aac content::ContentServiceManagerMainDelegate::RunEmbedderProcess() #56 0x7f4f0b0c37fa service_manager::Main() #57 0x7f4f05eced03 content::ContentMain() #58 0x55d3bef15246 ChromeMain #59 0x55d3bef15152 main #60 0x7f4ee0525b97 __libc_start_main #61 0x55d3bef1502a _start r8: 0000000000000000 r9: 00007ffd2e4d4130 r10: 0000000000000008 r11: 0000000000000246 r12: 00007f4ece13e562 r13: 00007f4ece13e618 r14: 00000000000000a1 r15: 000006d576684ec0 di: 0000000000000002 si: 00007ffd2e4d4130 bp: 00007f4ee06bb7d8 bx: 0000000000000000 dx: 0000000000000000 ax: 0000000000000000 cx: 00007f4ee0542e97 sp: 00007ffd2e4d4130 ip: 00007f4ee0542e97 efl: 0000000000000246 cgf: 002b000000000033 erf: 0000000000000000 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000 [end of stack trace]
xinghua, it would help if you could bisect this issue. Let us know if you cannot.
Hi. It doesn't reproduce on system drivers because they were built without "debug" flags. Reproduced this issue on debug mesa versions: 18.3.0-git 18.2.1 (tag) 18.0.0 (tag) 17.3.6 (tag) Also I found interesting behavior. Even on latest mesa, after running test several times - 3-5, it will pass and crashes will disappear. I thought that it might be some cashed data, but cache is empty for the page. The same behavior and for test from this bug https://bugs.freedesktop.org/show_bug.cgi?id=107892
(In reply to Mark Janes from comment #1) > xinghua, it would help if you could bisect this issue. Let us know if you > cannot. Hi, Mark, We will try to bisect it.
This test is relatively new (from last year) so it could be that the bug has been always there. It seems that test first uploads a texture with size 2x2, then it changes base level to 2 and uploads level 0 again with different size 1x1. For some reason we then fail extents checking in 'intel_miptree_match_image'. It could be because of the base level change.
(In reply to Tapani Pälli from comment #4) > This test is relatively new (from last year) so it could be that the bug has > been always there. It seems that test first uploads a texture with size 2x2, > then it changes base level to 2 and uploads level 0 again with different > size 1x1. For some reason we then fail extents checking in > 'intel_miptree_match_image'. It could be because of the base level change. Hi, Tapani, It seems that you had known the root cause of this issue. Do you still need me to bisect it for you?
(In reply to xinghua from comment #5) > (In reply to Tapani Pälli from comment #4) > > This test is relatively new (from last year) so it could be that the bug has > > been always there. It seems that test first uploads a texture with size 2x2, > > then it changes base level to 2 and uploads level 0 again with different > > size 1x1. For some reason we then fail extents checking in > > 'intel_miptree_match_image'. It could be because of the base level change. > > Hi, Tapani, > It seems that you had known the root cause of this issue. Do you still need > me to bisect it for you? My feeling is that this is not a regression but we've always had it. It seems like some other drivers had it as well: https://bugs.chromium.org/p/chromium/issues/detail?id=705865&desc=4
(In reply to Tapani Pälli from comment #6) > (In reply to xinghua from comment #5) > > (In reply to Tapani Pälli from comment #4) > > > This test is relatively new (from last year) so it could be that the bug has > > > been always there. It seems that test first uploads a texture with size 2x2, > > > then it changes base level to 2 and uploads level 0 again with different > > > size 1x1. For some reason we then fail extents checking in > > > 'intel_miptree_match_image'. It could be because of the base level change. > > > > Hi, Tapani, > > It seems that you had known the root cause of this issue. Do you still need > > me to bisect it for you? > > My feeling is that this is not a regression but we've always had it. It > seems like some other drivers had it as well: > > https://bugs.chromium.org/p/chromium/issues/detail?id=705865&desc=4 Did you already dive into this issue? Just to avoid collision with you if yes :-)
Created attachment 141837 [details] simple reproduccer to simplify the debugging process. Hi, I have created the simple reproducer because debugging the chrome not very convenient. My current progress in this issue: I managed to reproduce this issue in the following way: 1. Use shader program which is used at least one 'texture sample' in FS instead of 'FF'. 2. Setup following property for texture GL_TEXTURE_MIN_FILTER = GL_LINEAR or GL_NEAREST 3. The program must upload level 2 = 4x4, 1 = 2x2, 0 = 1x1. The pixels values is not matter but must be uploaded and sequence of uploading is very matter, firstly level 2 then 1 and lastly 0. 4. The last operation which should cause the assertion is glDrawArrays which uses shader and texture mentioned above to draw some rectangle. I found out that when we try to re-create miptree in 'intel_finalize_mipmap_tree' function we don't consider the 'base level' in width0, height0, depth0 calculations. I not very familiar with this part of the mesa code but I found that the 'intel_miptree_create_for_teximage' function consider the 'base level'. So I tried to do it in 'intel_finalize_mipmap_tree' and that fixes this issue for me. So I hope that this is a possible fix: https://patchwork.freedesktop.org/patch/254397/
(In reply to asimiklit from comment #8) > Created attachment 141837 [details] > simple reproduccer to simplify the debugging process. > > Hi, > > I have created the simple reproducer because debugging the chrome not very > convenient. > > My current progress in this issue: > > I managed to reproduce this issue in the following way: > 1. Use shader program which is used at least one 'texture sample' in FS > instead of 'FF'. > 2. Setup following property for texture GL_TEXTURE_MIN_FILTER = GL_LINEAR or > GL_NEAREST > 3. The program must upload level 2 = 4x4, 1 = 2x2, 0 = 1x1. The pixels > values is not matter but must be uploaded and sequence of uploading is very > matter, firstly level 2 then 1 and lastly 0. > 4. The last operation which should cause the assertion is glDrawArrays which > uses shader and texture mentioned above to draw some rectangle. > > I found out that when we try to re-create miptree in > 'intel_finalize_mipmap_tree' function we don't consider the 'base level' in > width0, height0, depth0 calculations. > I not very familiar with this part of the mesa code but I found that the > 'intel_miptree_create_for_teximage' function consider the 'base level'. > So I tried to do it in 'intel_finalize_mipmap_tree' and that fixes this > issue for me. So I hope that this is a possible fix: > https://patchwork.freedesktop.org/patch/254397/ *wording fix* 1. Use shader program which uses at least one 'texture sample' in FS instead of 'FF'.
I a piglit test was suggested to avoid regressions in future: https://patchwork.freedesktop.org/patch/257925
I tried latest Ubuntu 19.04 (Mesa 19.0.1), and the issue can't be reproduced. Thanks for the fix!
*** Bug 111083 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.