> -----Original Message----- > From: Emil Velikov [mailto:emil.l.veli...@gmail.com] > Sent: Friday, September 8, 2017 11:03 PM > To: Antognolli, Rafael <rafael.antogno...@intel.com> > >> > > Isn't this strange? Can someone please comment? > >> > > > >> > In all fairness there was a few wtf moments as Mark mentioned the > >> > issue. As on a quick look "it cannot happen" :-\ > >> > > >> > One way is to add some printfs "debugging" across the board and > >> > check with Mark if he can run (only?) the affected test on the CI. > >> > > >> > >> Number of tests failing on CI due to this are huge, any 'one' can be > >> picked up. I do have my CI branch setup now but I don’t think I can > >> use it for debugging (not advised). I'll sync up with Mark again. Just > >> wanted a > confirmation, I'm not missing something obvious. Thanks. > > > > Hi Yogesh, > > > > I replied to you already when you messaged in private, the error is > > not related to the kernel returning true for that, it's related to a > > memory corruption caused by wrong use of the dri2_surf_init inside > > platform_x11_dri3.c. Quoting myself: > > > > "More specifically, it looks like this test fails every time: > > > > glcts -n > > dEQP-EGL.functional.query_context.get_current_context.rgb888_window > >
This passes for me. That’s what confused me again. how is that possible? Output: Writing test log into TestResults.qpa dEQP Core git-dfcb8e870438f6f2bfe71d4bb63d43120debb3a3 (0xdfcb8e87) starting.. target implementation = 'X11 EGL' Test case 'dEQP-EGL.functional.query_context.get_current_context.rgb888_window'.. Pass (Pass) DONE! Test run totals: Passed: 1/1 (100.0%) Failed: 0/1 (0.0%) Not supported: 0/1 (0.0%) Warnings: 0/1 (0.0%) > > I see several valgrind warnings inside platform_x11_dri3.c. I believe > > you are probably accessing the dri2_surf before it was allocated, or > > after it was freed..." > > > > When I tested this back then, the "out_fence_enable" (or whatever was > > called) in dri2 was false, but after a couple runs it would become a > > bogus number, which also points to memory corruption. > > > > I suggest ignoring the kernel and focusing on valgrind debugging. > > > Nicely spotted there Rafael. > > The issue is that the dri3 surface primitive wraps around _EGLSurface. > Thus as we reference the new variables we effectively write onto the > loader_dri3 bits. And at a later stage the dri3 loader code toggles those to > "use > out fence = true". I will check this with valgrind. > > -Emil _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev