Wayland client crash in wl_buffer_release

[stephenminutill]

We are seeing crashes in our Wayland client applications.  Our applications open and close multiple windows throughout their lifecycle and it appears that the Vivante driver does not destroy the Wayland buffer proxy objects with wl_buffer_destroy, so they still get release events when they are already destroyed

We were able to replicate this crash with a small modifiication to simple-egl.c, running under Weston.  Attached is the patch to simple-egl.c and the backtrace of the crash, collected on a SabreSD board running fsl-yocto-3.10.53-1.1.0 BSP.

Is our code incorrect, or is this a bug?  If it is a bug, is there a workaround?

Original Attachment has been moved to: simple-egl.c.patch.zip

Original Attachment has been moved to: wl_buffer_release-crash-bt.txt.zip

[HugoOsornio]

Hello stephenminutillo

Thanks for providing the files, I will replicate it in our environment, we just created a patch that solved a similar issue, will verify if this applies to the patch and come back with an answer.

Thanks,

Hugo

[HugoOsornio]

Hello stephenminutillo

I already integrated the patch to the simple EGL and am running it on a 3.10.53 BSP.

It destroys and then creates an egl window every 100 frames, so far the issue has not happened, the demo has been for about 10 minutes now.

Will leave it running, for an hour, if the issue is not reproduced, then I will share my .so files with you so you can test it with them on your end.

Cheers,

Hugo

[HugoOsornio]

Hello stephenminutillo

I used the modified simple-egl app and left it running overnight.

I did not notice the issue on my end, the board powered off at some point at night but as soon as I got back and moved the mouse on the board, the system resumed execution.

I will proceed to attach the set of drivers that I have for you to test in your environment.

Cheers,

Hugo

[stephenminutill]

These libraries seem to fix the original problem, but with them installed simple-egl crashes with a different problem in our environment, in wl_list_empty:

#0  wl_list_empty (list=list@entry=0x0) at

/home/petersen/projects/fsl-release-bsp/build-wayland/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/wayland/1.6.0-r0/wayland-1.6.0/src/wayland-util.c:79

#1  0x76ea04e4 in dispatch_queue (display=display@entry=0x14008, queue=queue@entry=0x0) at

/home/petersen/projects/fsl-release-bsp/build-wayland/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/wayland/1.6.0-r0/wayland-1.6.0/src/wayland-client.c:1260

#2  0x76ea0e6c in wl_display_dispatch_queue (display=0x14008, queue=0x0) at

/home/petersen/projects/fsl-release-bsp/build-wayland/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/wayland/1.6.0-r0/wayland-1.6.0/src/wayland-client.c:1407

#3  0x76afc7bc in ?? ()

Is it possible that additional libraries need to also be replaced to be compatible?  We noticed that the zip file did not contain these files which may also be related:

libg2d-viv.so

libgc_wayland_protocol.so.0.0.0

libGL.so.1.2.0

libVIVANTE.so

libwayland-viv.so.0.0.0

[HugoOsornio]

Hello stephenminutillo

You are right, additional libraries must be needed. I can run the applications without any issues on my system.

Attaching the files you requested.

If this does not work, I can take a complete snapshot of my environment and make it available to you.

Cheers,

Hugo

[stephenminutill]

Thanks, with these additional libraries installed the problem does go away.  Will this fix be going into some official patch or official release?  We need to get it integrated with the BSP provided by our vendor, TimeSys.

[HugoOsornio]

Hello Stephen,

We are just on the fix and test cycle of the next BSP release, I am not aware of the dates yet, but must have more information by next week.

Cheers,

Hugo

[stephenminutill]

Thanks for your quick response to this problem.  Please let me know as soon as possible when this fix will be released.  It is a high severity issue for us.

I see in Git a branch called daisy_3.10.53-1.1.2_patch with updated imx-gpu-viv and imx-gpu-viv-kernel packages.  Do those packages contain this fix?

[HugoOsornio]

The issues were fixed on the Dizzy Branch, I parsed through the changes and I cannot see the fix on the Daisy sources yet.

[stephenminutill]

Will the fixes also be back ported to the BSP based on the 3.10.53 kernel?  That's what we are using now and we need to get these fixes integrated in ASAP.

[HugoOsornio]

Hello stephenminutillo

I just received confirmation from our GPU team that while the libs provided above fix the issue, they have still to fix/validate other artifacts caused by this fix.

They are not able to provide an estimate release time yet. And yes, the plan is to backport the fixes to the 3.10.53BSP

Cheers,

Hugo