i965: Clapper segfaults when playing DASH-MPD playlist

[sp1ritCS]

Steps to reproduce:

1. Run: com.github.rafostar.Clapper "http://www-itec.uni-klu.ac.at/ftp/datasets/mmsys12/RedBullPlayStreets/redbull_4s/RedBullPlayStreets_4s_isoffmain_DIS_23009_1_v_2_1c2_2011_08_30.mpd"
2. Clapper starts playing the first segment
3. Clapper throws SIGSEGV
4. ??
5. Profit

---

When running inside of Valgrind, it crashes after about 7s and natively only 3-4s. So I assume it's some kind of memory issue.

Valgind log:

==20890== Memcheck, a memory error detector
==20890== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==20890== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info
==20890== Command: /usr/bin/com.github.rafostar.Clapper http://www-itec.uni-klu.ac.at/ftp/datasets/mmsys12/RedBullPlayStreets/redbull_4s/RedBullPlayStreets_4s_isoffmain_DIS_23009_1_v_2_1c2_2011_08_30.mpd
==20890== 
==20890== Warning: set address range perms: large range [0x1dcec4225000, 0x1dcf43e25000) (noaccess)
--20890-- WARNING: unhandled amd64-linux syscall: 315
--20890-- You may be able to write your own handler.
--20890-- Read the file README_MISSING_SYSCALL_OR_IOCTL.
--20890-- Nevertheless we consider this a bug.  Please report
--20890-- it at http://valgrind.org/support/bug_reports.html.
==20890== Warning: unimplemented fcntl command: 1033
==20890== Thread 21 gstglcontext:
==20890== Invalid read of size 4
==20890==    at 0x1C3446FB: ??? (in /usr/lib64/dri/i965_dri.so)
==20890==    by 0x1F72968F: ???
==20890==    by 0x1C464BA8: ??? (in /usr/lib64/dri/i965_dri.so)
==20890==    by 0xF80FD22: gst_gl_memory_copy_teximage (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF810067: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF80AC30: gst_gl_memory_copy_into (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF80CE98: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF7F0BE3: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF81CD02: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF81CCC1: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0x49C3C76: ??? (in /usr/lib64/libglib-2.0.so.0.6600.7)
==20890==    by 0x49C7F56: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.6600.7)
==20890==  Address 0x30 is not stack'd, malloc'd or (recently) free'd
==20890== 
==20890== Invalid read of size 4
==20890==    at 0x1C3446FB: ??? (in /usr/lib64/dri/i965_dri.so)
==20890==    by 0x1C3446FF: ??? (in /usr/lib64/dri/i965_dri.so)
==20890==    by 0x1C464BA8: ??? (in /usr/lib64/dri/i965_dri.so)
==20890==    by 0xF80FD22: gst_gl_memory_copy_teximage (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF810067: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF80AC30: gst_gl_memory_copy_into (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF80CE98: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF7F0BE3: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF81CD02: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF81CCC1: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0x49C3C76: ??? (in /usr/lib64/libglib-2.0.so.0.6600.7)
==20890==    by 0x49C7F56: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.6600.7)
==20890==  Address 0x30 is not stack'd, malloc'd or (recently) free'd
==20890== 
==20890== 
==20890== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==20890==  Access not within mapped region at address 0x30
==20890==    at 0x1C3446FB: ??? (in /usr/lib64/dri/i965_dri.so)
==20890==    by 0x1C3446FF: ??? (in /usr/lib64/dri/i965_dri.so)
==20890==    by 0x1C464BA8: ??? (in /usr/lib64/dri/i965_dri.so)
==20890==    by 0xF80FD22: gst_gl_memory_copy_teximage (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF810067: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF80AC30: gst_gl_memory_copy_into (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF80CE98: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF7F0BE3: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF81CD02: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0xF81CCC1: ??? (in /usr/lib64/libgstgl-1.0.so.0.1803.0)
==20890==    by 0x49C3C76: ??? (in /usr/lib64/libglib-2.0.so.0.6600.7)
==20890==    by 0x49C7F56: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.6600.7)
==20890==  If you believe this happened as a result of a stack
==20890==  overflow in your program's main thread (unlikely but
==20890==  possible), you can try to increase the size of the
==20890==  main thread stack using the --main-stacksize= flag.
==20890==  The main thread stack size used in this run was 8388608.
==20890== 
==20890== HEAP SUMMARY:
==20890==     in use at exit: 95,646,731 bytes in 292,123 blocks
==20890==   total heap usage: 1,356,930 allocs, 1,064,807 frees, 419,459,212 bytes allocated
==20890== 
==20890== LEAK SUMMARY:
==20890==    definitely lost: 61,648 bytes in 163 blocks
==20890==    indirectly lost: 38,566 bytes in 1,569 blocks
==20890==      possibly lost: 27,792,897 bytes in 21,794 blocks
==20890==    still reachable: 67,182,016 bytes in 265,503 blocks
==20890==                       of which reachable via heuristic:
==20890==                         length64           : 19,944 bytes in 273 blocks
==20890==                         newarray           : 3,072 bytes in 81 blocks
==20890==                         multipleinheritance: 312,192 bytes in 319 blocks
==20890==         suppressed: 6,668 bytes in 7 blocks
==20890== Rerun with --leak-check=full to see details of leaked memory
==20890== 
==20890== For lists of detected and suppressed errors, rerun with: -s
==20890== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
[1]    20890 segmentation fault (core dumped)  valgrind com.github.rafostar.Clapper

I'll append a --leak-check=full --show-leak-kinds=all dunno if you can do something with that, but my browser crashes if I'd paste it here, as it has 835030 lines. clapper_full_valgrind.txt.gz

[Rafostar]

This happens in i965 driver when GStreamer "touches" GL context when renegotiating video resolution (adaptive streaming). This might go away when Clapper video widget is ported from GLArea to GdkPaintable. This is not reproducible on my AMD system unfortunately.

This is most likely the same issue as: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3029

[Rafostar]

I can confirm that this is GLArea unrelated. Same thing happens in GTK4 video player demo.

[Rafostar]

Applied workaround for Flatpak package. A proper fix needs to land in Mesa Intel driver (issue linked in one of above comments). Nothing more I can possibly do here, so closing.