On Tue, Apr 24, 2018 at 3:13 AM, Johan Helsing wrote:
> Emil: Your alternative patch won't work because dri_make_current is not
> necessarily called with NULL after a buffer has been destroyed.
>
>
> The problematic sequence is a pattern we use in QtWayland:
>
>
> //create temporary context
>
> s
On 24 April 2018 at 08:13, Johan Helsing wrote:
> Emil: Your alternative patch won't work because dri_make_current is not
> necessarily called with NULL after a buffer has been destroyed.
>
Interesting, the trace attached in the bugreport does a proper
makecurrent/surface dance.
Namely, MakeCurren
ekka.paala...@collabora.co.uk; ML Mesa-dev
> Subject: Re: [Mesa-dev] [PATCH] st/dri: Fix dangling pointer to a destroyed
> dri_drawable
>
> On 2018-04-24 09:13 AM, Johan Helsing wrote:
>> Emil: Your alternative patch won't work because dri_make_current is not
>> neces
Hi Johan,
On 24 April 2018 at 09:44, Johan Helsing wrote:
> If the call to dri_destroy_buffer is delayed until the next eglMakeCurrent,
> that would also solve the problem (I'm not sure how that would affect other
> things, though).
It _must_ be:
If the EGL surface surface is not current to an
happy.
Johan
From: Michel Dänzer
Sent: Tuesday, April 24, 2018 10:36:00 AM
To: Johan Helsing; Marek Olšák
Cc: Daniel Stone; pekka.paala...@collabora.co.uk; ML Mesa-dev
Subject: Re: [Mesa-dev] [PATCH] st/dri: Fix dangling pointer to a destroyed
dri_drawable
On 2018-04-24 09:13 AM, Johan Helsin
On 2018-04-24 09:13 AM, Johan Helsing wrote:
> Emil: Your alternative patch won't work because dri_make_current is not
> necessarily called with NULL after a buffer has been destroyed.
>
>
> The problematic sequence is a pattern we use in QtWayland:
>
>
> //create temporary context
>
> surfac
Emil: Your alternative patch won't work because dri_make_current is not
necessarily called with NULL after a buffer has been destroyed.
The problematic sequence is a pattern we use in QtWayland:
//create temporary context
surface1 = eglCreateWindowSurface() <-- dri_drawable pointer is malloce
FYI, the commit was causing crashes of qtcreator and firefox, so I reverted
it.
Marek
On Fri, Apr 20, 2018 at 6:29 AM, Johan Klokkhammer Helsing <
johan.hels...@qt.io> wrote:
> If an EGLSurface is created, made current and destroyed, and then a second
> EGLSurface is created. Then the second mal
Hi Johan,
On 20 April 2018 at 11:29, Johan Klokkhammer Helsing
wrote:
> If an EGLSurface is created, made current and destroyed, and then a second
> EGLSurface is created. Then the second malloc in driCreateNewDrawable may
> return the same pointer address the first surface's drawable had.
What d
Pushed, thanks!
Marek
On Fri, Apr 20, 2018 at 6:29 AM, Johan Klokkhammer Helsing <
johan.hels...@qt.io> wrote:
> If an EGLSurface is created, made current and destroyed, and then a second
> EGLSurface is created. Then the second malloc in driCreateNewDrawable may
> return the same pointer addres
If an EGLSurface is created, made current and destroyed, and then a second
EGLSurface is created. Then the second malloc in driCreateNewDrawable may
return the same pointer address the first surface's drawable had.
Consequently, when dri_make_current later tries to determine if it should
update the
11 matches
Mail list logo
