Random deadlock during drawing

[Mikchel]

Hello all.
I have some strange freezing of drawing process. I develop app which shows video on background and some shapes in foreground. Sometime i need to pause video, and after restart it again.
I can not understand the reason of freezes. It looks like deadlock inside OGL library. It is strange as i'm drawing in one thread there is no any concurrence calls for drawing other shapes.
Here is gdb backtrace.

Program received signal SIGINT, Interrupt.
__libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
46 ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory.
(gdb) bt
#0 __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:46
#1 0x762d0fce in futex_abstimed_wait (cancel=true, private=0, abstime=0x0, expected=1, futex=0x76f1ed38 <khrn_queue+76>) at sem_waitcommon.c:42
#2 do_futex_wait (sem=sem@entry=0x76f1ed38 <khrn_queue+76>, abstime=0x0) at sem_waitcommon.c:211
#3 0x762d10a6 in __new_sem_wait_slow (sem=0x76f1ed38 <khrn_queue+76>, abstime=0x0) at sem_waitcommon.c:392
#4 0x7611cb3e in vcos_event_wait () from /home/user/Downloads/for_test4/lib/libvchiq_arm.so
#5 0x7611cda8 in vchiu_queue_pop () from /home/user/Downloads/for_test4/lib/libvchiq_arm.so
#6 0x76efb25a in rpc_recv () from /home/user/Downloads/for_test4/lib/libEGL.so
#7 0x76efe6f4 in get_error () from /home/user/Downloads/for_test4/lib/libEGL.so
#8 0x76f0d372 in get_vgu_error () from /home/user/Downloads/for_test4/lib/libEGL.so
#9 0x76f0e520 in vguRoundRect () from /home/user/Downloads/for_test4/lib/libEGL.so
#10 0x00026022 in CApplication::drawRoundRectPainters (this=<optimized out>, backPaint=0x7efa8740, strokePaint=0x7efa873c, path=0x7efa8744, s=...,
fg=2147483392, radius=10, strokeWidth=-1, strokeColor=2147483647) at app_gl.cpp:4133
#11 0x00027902 in CApplication::hitZoneRender (this=this@entry=0x7efa9958) at app_gl.cpp:2269
#12 0x0002a432 in CApplication::sceneRender (this=this@entry=0x7efa9958) at app_gl.cpp:923
#13 0x0001bc28 in CApplication::schedulerApp (this=this@entry=0x7efa9958) at app.cpp:2197
#14 0x0001d2e4 in CApplication::execApp (this=this@entry=0x7efa9958) at app.cpp:936
#15 0x0000fdd2 in main (argc=5, argv=<optimized out>) at main.cpp:246
(gdb)

./vcgencmd cache_flush;./vcdbg reloc >c.log - after deadlock happen also freeze without any output.

Is there any method to understand the reason of deadlock?
Thanks.

[Mikchel]

Here is vcdbg reloc output....may be it can help

[Paeryn]

Are you constantly creating & destroying paths every frame (especially if you are doing a lot of them)? I've seen it freeze for upto 30 seconds at a time and sometimes even lock up totally when doing that.

Is there any reason why you are linking to local copies of the shared libraries (libvchiq_arm and libEGL) rather than the system ones in /opt/vc/lib/ ?

[Mikchel]

Yes, you are right. I'm creating them each time when drawing scene. But i found that it is not very good and started to use vgClearPath to use same path. Actually it is not helpped. Should i use one path for scene drawing at all ?
As i have this deadlock bug i compiled libraries from fresh userland repo and copy to remote RP2.

WBR,

[Paeryn]

If you can you are best off defining paths outside of any drawing loops and modifying the drawing of them. I found vgClearPath still has problems, if you just need to alter the coodinates and not the actual segment types in each path then you are best off using vgModifyPathCoords (that is if you can't achieve the same thing using combinations of vgRotate, vgScale, vgShear and vgTranslate to modify how coordinates are transformed when drawing). Though if you are using vgu* functions to create paths then when using vgModifyPathCoords you need to make sure you set the coordinates of the segments correctly as you can't alter what type each segment of the path is, only the coordiates of each segment.

I wouldn't think using the userland repo versions would make any difference, when I looked into it the problem seems to be within the gpu side of things (it locks up waiting for the gpu to respond). The userland code does a bit of stuff to prepare data and to hold on to some data that will save having to query the gpu for some things but ultimately the bulk of the driver code is on the gpu and the userland mainly passes (semi-)processed data on to it.

[Mikchel]

Actually my scene is not big enough. I'd tell that is is small
So if creation about 50 drawing objects can put GPU code to deadlock then something wrong in this code
Ok, thank you for your suggestion. I will try to rewrite code.

WBR,