Ahoy,

I'm using Debian Trixie on a machine with an Intel Haswell integrated GPU with GNOME on Wayland. GNOME Maps nowadays has support for getting public transit directions in my area and displaying the possible routes on a map with vector tiles, potentially including all of the different bus stops as well. This is to say that it's probably fairly GPU-intensive when it draws the routes.
I was fumbling with a user interface quirk that made it tricky to set the departure time to my liking and so I quickly switched between the routes, changed departure times, and panned around on the map. Although this seems like a race condition I'm able to reproduce it pretty easily in a minute or two. I've seen it fail two different ways but the more typical (and insightful) way corresponds to the backtrace I'm attaching for invoking 'gjs /usr/bin/gnome-maps'.
To me, it looks like gjs uses a foreign function interface to call into GLib/GDK right within the same process, which is why gjs itself crashes. Words that stand out to me are "GskGLRenderer", "GskGLImage", and after what looks like a giant daisy chain of GSK GPU drawing operations, we find "_mesa_TexImage2D", "teximage_err", "st_AllocTextureImageBuffer", and then we get into Crocus functions before memset() tramples on the address space. (Sometimes the FORTIFY_SOURCE protections kick in and glibc intervenes before the kernel does.)

This sure does look an awful like the upstream Mesa issue 13426 I've referenced which is fixed only in Mesa 25.3.0 and newer—although because of the butterfly effect being at play, the backtrace does look kind of different every time on my end.

I am suspicious if I'm really hitting that same issue so I've marked this bug 'moreinfo' at least until I gather follow-up info. My backtrace shows 'compressed=0' but I think the upstream issue is about 'compressed=1' not being handled properly. I also set breakpoints on suspect functions mentioned in the upstream fix's commit message but I actually didn't hit any of them.
This is mainly a note for myself but my plan of attack is as follows:
 • the Mesa version in trixie-backports should still be affected and I ought to confirm that
 • then cherry pick the upstream fix into a local rebuild of the Debian package and see if I can reproduce the issue anymore: if not, I can confirm this and maybe we can talk about whether it deserves to get into trixie-(proposed-)updates?
 • if that doesn't help, then I can fast-forward to whatever is in upstream Git—and maybe use some LD_PRELOAD or LD_LIBRARY_PATH voodoo so I don't have to deal with Debian packaging changes—and see if I can reproduce then. If I can't, then I can get to bisecting with Git. If the search space is big, I can probably script the keyboard shortcuts to provoke GNOME Maps using xdotool with Xwayland (if the issue even happens then?) or wtype.

Please note: I haven't done a search of the (potentially open) issues filed upstream yet.

Control: tags -1 moreinfo
Control: notforwarded -1
I've rebuilt the Debian Trixie packages with https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/37150 applied and the problem still occurs, so that's probably not it. I have noticed Mesa upstream adding workarounds for GTK 4 applications recently; maybe the issue is on their end. Many issues and commits use the same buzzwords that pertain to this bug, but since I don't know what they mean, I think I've exhausted my ability to do more detective work for now.
I also upgraded all binaries of src:mesa to the Trixie backports version and didn't see any relief.
This might not be as easy as I thought. I don't know too much about Mesa; does one usually need to reboot (or at least restart the graphical session) for upgrades to take effect such that they might address this issue? Also Mesa uses modules of some kind in directories like /usr/lib/x86_64-linux-gnu/dri/, but I don't know what I need to do about that.

I think I've hit a dead end, but largely due to lack of knowledge in this space and the high upfront cost to learning this subject. If anyone is daring enough to dig in, I can make arrangements for remote access to this machine such as by SSH.