ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
illwieckz has joined #zink
<fdobridge> <S​id> https://pastebin.com/NvZTGJ6d
<fdobridge> <S​id> random segfault in zink caused by electron
<fdobridge> <k​arolherbst> I'm sure it's some threading madness 🙃
<fdobridge> <z​mike.> would be useful to know exactly which line that is and what pointer (I assume) is null
<fdobridge> <S​id> will look into it after dinner
<fdobridge> <S​id> it happened just as I was about to go cook, so
<fdobridge> <!​DodoNVK (she) 🇱🇹> I guess something's wrong with `dst_view` variable (because 24.3.4 and `main` are on the same commit with regards to the `zink_render_pass.c` file)
<zmike> but there's already an assert higher up
<zmike> though the pastebin doesn't include the signal being hit here
<fdobridge> <S​id> Program terminated with signal SIGSEGV, Segmentation fault.
<fdobridge> <k​arolherbst> electron is doing heavy multi threading stuff, so it's not unlikely that things get screwed up badly here in unexpected ways
<zmike> what is the app
<fdobridge> <S​id> vesktop 1.5.5
<fdobridge> <S​id> and it's seemingly random, because I've been running my session on nvk+zink all day
<zmike> hm
<fdobridge> <k​arolherbst> what's the mesa verison? 24.3.4?
<fdobridge> <S​id> it's 1944 here right now, PC has been up since ~1030
<fdobridge> <S​id> `mesa-git 25.1.0_devel.201940.e488b5e45e2`
<fdobridge> <k​arolherbst> @zmike. if you want to make zink threading proof, run the android emulator with native OpenGL 🙃
<fdobridge> <k​arolherbst> you'll hit races left and right
<fdobridge> <z​mike.> I don't know what this means
<fdobridge> <k​arolherbst> it will share a single OpenGL context doing all rendering or something
<fdobridge> <k​arolherbst> for every app
<fdobridge> <k​arolherbst> it's brutal
<fdobridge> <z​mike.> I mean what is "the android emulator with native opengl"
<fdobridge> <S​id> as always fdo gitlab is slow as molasses
<fdobridge> <k​arolherbst> or doing 100 contexts or something
<fdobridge> <k​arolherbst> ahh.. you want a x86_64 image
<fdobridge> <k​arolherbst> that can call into the host gl
<fdobridge> <k​arolherbst> newer versions might use vulkan instead, dunno.. has been years
<fdobridge> <k​arolherbst> but it's was an excellent stress test for threading
<fdobridge> <S​id> ok yeah, I built on commit `e488b5e45e2 venus: support VK_KHR_global_priority`
<fdobridge> <k​arolherbst> crashed within seconds if you screwed up thread safety
<fdobridge> <z​mike.> no I mean literally link me to whatever tf you're talking about
<fdobridge> <S​id> 560 commits behind upstream
<fdobridge> <z​mike.> thanks
<fdobridge> <k​arolherbst> don't need to run an app, just start the emulator and do stuff like opening chrome or so 😄
<fdobridge> <k​arolherbst> I've done it when 12 or 13 was the newest version or so
<fdobridge> <k​arolherbst> but you can pick the version anyway
<fdobridge> <k​arolherbst> more info on hw acceleration
<fdobridge> <k​arolherbst> though in my experience just picking a x86_64 image was enough, I think there is a checkbox in the AVD settings in the GUI to enable it explicitly
<fdobridge> <S​id> this is the line frame #0 of the backtrace is pointing to
<zmike> yes, I have it here
<zmike> I know what's happening just not how
<fdobridge> <S​id> hm, well
<fdobridge> <S​id> my gdb skills are still pretty bad, but I can do whatever you need me to
<fdobridge> <S​id> actually..
<zmike> can you print msaa_expand_mask
<zmike> and also i
<fdobridge> <S​id> (gdb) print msaa_expand_mask
<fdobridge> <S​id> $1 = 1
<fdobridge> <S​id> (gdb) print i
<fdobridge> <S​id> $2 = 0
<zmike> yeah that's about what I expected
<fdobridge> <S​id> :3
<fdobridge> <k​arolherbst> not sure if sharing core files is helpful, because they rely on external debug symbols, no?
<zmike> yeah...
<fdobridge> <S​id> mm
<fdobridge> <S​id> well, I've got gdb open :salute:
<fdobridge> <k​arolherbst> maybe `p *dst_view` and `p *csurf` could indicate what's wrong
<zmike> somehow csurf isn't a csurf
<fdobridge> <S​id> (gdb) p *dst_view
<fdobridge> <S​id> Cannot access memory at address 0x0
<fdobridge> <k​arolherbst> yeah.. I expect the ref count to be 0 or lower or something funky
<fdobridge> <S​id> ```
<fdobridge> <S​id> (gdb) p *csurf
<fdobridge> <S​id> $3 = {base = {reference = {count = 2}, format = PIPE_FORMAT_R8_UNORM, writable = 0, texture = 0x1f3402a22000, context = 0x1f34001b8030, width = 128, height = 16, nr_samples = 8, u = {tex = {level = 0, first_layer = 0, last_layer = 0}, buf = {first_element = 0, last_element = 0}}}, surf = 0x1f340002e500,
<fdobridge> <S​id> transient = 0x0, transient_init = false, needs_mutable = false}
<fdobridge> <S​id> ```
<fdobridge> <k​arolherbst> mhhh
<fdobridge> <k​arolherbst> maybe not
<fdobridge> <!​DodoNVK (she) 🇱🇹> That's what I expected for that variable
<fdobridge> <k​arolherbst> zmike: you did into account that this might be release code and asserts might not hit, right?
<zmike> well then it'll just crash
<zmike> which is also fine
<fdobridge> <k​arolherbst> yeah
<fdobridge> <k​arolherbst> but it sounded like you assumed `dst_view` to be not NULL, dunno
<fdobridge> <S​id> nope
<fdobridge> <S​id> --buildtype debug
<fdobridge> <k​arolherbst> heh
<zmike> with asserts disabled I guess
<fdobridge> <S​id> hmm let me check
<fdobridge> <k​arolherbst> it's the `b_ndebug` option
<fdobridge> <S​id> -D b_ndebug=true
<fdobridge> <k​arolherbst> yeah, so asserts are disabled
<fdobridge> <S​id> I'll switch that over to false, thanks :froge:
<fdobridge> <k​arolherbst> anyway, I hate debugging electron apps, it's a pain
<zmike> I'd guess you should hit an assert before that, but maybe not
jhli has joined #zink
xroumegue has joined #zink