ChanServ changed the topic of #zink to: official development channel for the mesa3d zink driver || https://docs.mesa3d.org/drivers/zink.html
cheako has joined #zink
Akari` has joined #zink
Akari has quit [Read error: Connection reset by peer]
omegatron has quit [Quit: What happened? You quit!]
<ajax> X Error of failed request: BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 55 (X_CreateGC) Resource id in failed request: 0x800074 Serial number of failed request: 306 Current serial number in output stream: 307
<ajax> okay, one who broke pasting in irssi, but two how the actual f did i manage to get a BadIDChoice in the wild
<ajax> hm. not reliably at the same serial number, but still pretty reliably.
<ajax> wrong week to quit smoking, etc
<ajax> naturally since this is a race i get an entirely different crash when i try this in gdb
<ajax> have we considered whether computers might be a mistake
<ajax> (not urgent)
omegatron has joined #zink
<zmike> haha wtf
<zmike> how is src null
<zmike> definitely never seen that one before
<ajax> afaict the swapchain gets killed after we check its liveness at the top of zink_blit
<zmike> oh
<zmike> huh.
<ajax> yeah
<zmike> that sounds illegal
<zmike> like the frontend should be not letting that happen
<zmike> but hm
<zmike> I guess maybe it needs an early return like the draw path has?
<ajax> it can't hurt i guess, assuming it doesn't regress anything
<zmike> but I think at the least that test definitely shouldn't be exhibiting such behavior
<ajax> right
<zmike> and using a hack to force the zombie keepalive behavior locally the test passes without issue
<ajax> real possibility that this is a second-order bug resulting from the glx layer just being wrong
<zmike> I would assume it is for the scenario of this test
<ajax> which: BadIDChoice already implies i'm losing sync between xcb and xlib, so, yes, something else is already wrong
<zmike> there should be an early return in the blit path though if you want to add one
<zmike> potentially this could happen during app shutdown or something
<zmike> so misrenders don't matter because the app is already dead
<zmike> (assuming the app is blitting from the swapbuffer resource at that exact moment and the new acquire picks that up)