I was build drivers r4p0 for Orange Pi 2 (Allwiner H3 soc) and get seg fault from running test app colour triangle with FBTURBO and mali r4p0 drivers.
Lubuntu 1404
ump
mali
mali_drm
and ssvb/xf86-video-fbturbo
also MaliLib.so blobs in /usr/lib
After debug I found that It crash in the eglSwapBuffers() call.
And here some back traces
(gdb) bt
#0 __GI___libc_malloc (bytes=) at malloc.c:2907
#1 0xb6f59cc4 in __egl_mali_post_to_window_surface () from /usr/lib/libEGL.so
#2 0xb6f59294 in _egl_swap_buffers () from /usr/lib/libEGL.so
#3 0xb6f5836c in eglSwapBuffers () from /usr/lib/libEGL.so
#4 0x00009050 in Redraw (width=200, height=200) at test.c:135
#5 0x00009790 in main (argc=1, argv=0xbefff6f4) at test.c:328
//==================================================
//================================================== Single stepping until exit from function _egl_surface_job_incref, which has no line number information. 0xb6f59dbe in __egl_mali_post_to_window_surface () from /usr/lib/libEGL.so (gdb) s Single stepping until exit from function __egl_mali_post_to_window_surface, which has no line number information.
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0xb69d1460 (LWP 2377)] 0xb6f5a224 in _egl_surface_job_decref () from /usr/lib/libEGL.so (gdb) bt #0 0xb6f5a224 in _egl_surface_job_decref () from /usr/lib/libEGL.so #1 0xb6f596be in __egl_worker_callback () from /usr/lib/libEGL.so #2 0xb6f62238 in _mali_base_worker_thread () from /usr/lib/libEGL.so #3 0xb6d10fbc in start_thread (arg=0xb69d1460) at pthread_create.c:314 #4 0xb6dc720c in ?? () at ../ports/sysdeps/unix/sysv/linux/arm/nptl/../clone.S:92 from /lib/arm-linux-gnueabihf/libc.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) (gdb)
Hi magicse,
From reading your question I believe you have access to the sourcecode for the userspace libraries (libEGL.so in this case), in which case I assume you also have a support contract with us? Questions about anything only available under a commercial licence are best directed to ARM support. Also if that is the case then r4p0 is quite old and I'd recommend updating to the latest release.
Hope this helps,
Chris
Hi, Chris Varnsverry
No I haven't user space sources. I have only blobs from Orange Pi ver r4p0.
That's why it my singe way with driver ver r4p0 and which not work well.
I know that many peoples from Orange Pi community have issues with eglSwapbuffers and Dri2swapbuffers and drivers not work with that blob.
I think in blobs source error for working with DRI2Swapbuffers.
Only with patched blobs drivers worked well.
I think it's a bug in call to DRI2SwapBuffers. I'm not sure, but it seems that last parameter is something like some_struct *s and someone passed wrong pointer, so stack gets corrupted when DRI2SwapBuffers tries to write something to &s
<__egl_platform_swap_buffers+40> ldr r3, [pc, #36]
<__egl_platform_swap_buffers+42> movs r2, #0 <__egl_platform_swap_buffers+44> add r4, sp, #24 ; There was #28 <__egl_platform_swap_buffers+46> add r3, pc <__egl_platform_swap_buffers+48> ldr r0, [r3, #4] <__egl_platform_swap_buffers+50> movs r3, #0 <__egl_platform_swap_buffers+52> str r4, [sp, #16] <__egl_platform_swap_buffers+54> strd r2, r3, [sp] <__egl_platform_swap_buffers+58> strd r2, r3, [sp, #8] <__egl_platform_swap_buffers+62> ldr r0, [r0, #4] <__egl_platform_swap_buffers+64> bl 0xb6f5cf64 <DRI2SwapBuffers>
After that changes in blob. Drivers work well.
Nice debugging! Hopefully that helps out some other people too. If the offset into the struct is wrong that seems to point to the blob being built for a different version of DRI2 to what is currently on your platform and the rest of your application is built against. I'd recommend approaching AllWinner and asking them what their roadmap for future driver updates is.
If the offset into the struct is wrong that seems to point to the blob being built for a different version of DRI2 to what is currently on your platform and the rest of your application is built against.
No, both __egl_platform_swap_buffers and DRI2SwapBuffers are defined in libMali.so, and former calls latter with wrong pointer
Hi whitewind,
Ah OK I misunderstood, didn't realise both symbols were in libMali.so. I'll forward this onto the driver team so they are aware, but this might have already been fixed in later releases as r4p0 is quite old now. Thanks magicse for sharing your fix!
Thanks,