12:22 <arigato> cfbolz: found a way to remove the crash https://github.com/python/cpython/pull/19474

12:23 <cfbolz> arigato: very cool

12:24 <cfbolz> arigato: of course once they start merging the nogil stuff everything will become way more complicated :-(

12:26 <arigato> ah. I think I'm not going to look at all

12:26 <cfbolz> :-)

12:26 <cfbolz> arigato: probably sensible

12:29 <cfbolz> arigato: I have an incredibly random question: do you remember whether we had to do anything special to make gdb understand the JIT's stack frames to make gdb commands like "backtrace" and "up" work? or is our function prologue/epilogue close enough to what a C compiler produces that the gdb pattern can deal with it?

12:29 <cfbolz> (if you don't remember that's fine)

12:33 <arigato> as far as I remember, gdb out of the box used to understand the frames

12:33 <cfbolz> ok, makes sense

12:34 <arigato> it might have been accidental, though

12:34 <arigato> instead of carefully designed

12:35 <cfbolz> yeah, that's kind of what I'm suspecting too

12:35 <arigato> (except on Power64, where I remember I needed to make the frames be fully "official" because otherwise some other OS things were not happy)

12:35 <cfbolz> interesting

12:36 <cfbolz> apparently there's a bunch of different mechanisms for this, eg gdb will to abstract interpretation to find the frame pointer on some CPUs

12:36 <arigato> ah, cool

12:36 <cfbolz> https://github.com/bminor/binutils-gdb/blob/master/gdb/prologue-value.h

12:37 <cfbolz> there seems to be a bug in the subtraction implementation: https://github.com/bminor/binutils-gdb/blob/master/gdb/prologue-value.c#L114

12:37 <cfbolz> the constant_last (&a, &b); call will swap the arguments, which is incorrect because subtract isn't commutative

12:38 <cfbolz> I haven't decided whether I want to send a patch (by mail) yet though :-)

12:38 <arigato> :-)

12:39 <arigato> "constant - nonconstant" should always be pvk_unknown

12:39 <arigato> how on earth did you find this bug?

12:40 <cfbolz> arigato: just randomly looked at the code :-)

12:40 <arigato> right, it has abstract interpretation in the description after all :-)

12:41 <cfbolz> the long story is: was chatting with some cpython devs that have a JIT prototype, and for the gdb didn't manage to understand the frames

12:41 <cfbolz> so I got curious how it works

12:42 <cfbolz> (the abstract interpretation is not used on x86 though, but arm 64 and some others)

12:42 <arigato> cool

12:43 <cfbolz> it seems to be a mess though, eg linux perf doesn't do anything like this, and you need to emit dwarf frame descriptions at runtime if you want to sample the full stack

12:50 <fijal> hi!

12:52 <fijal> are you sure that (Py_ssize_t)refcount < 0 cannot be optimized away by C compiler?

13:01 <sam_> the gdb people are rather nice and might be worth asking them in #gdbt oo

13:01 <sam_> *#gdb too

13:04 <cfbolz> sam_: thanks :-)

15:38 <cfbolz> arigato: the nogil work is 77 pull requests 😆

15:38 <cfbolz> they merged 9

15:43 <Alex_Gaynor> cfbolz: how did you find all 77, I'm failing to find with search

15:43 <cfbolz> Alex_Gaynor: "private communication"

15:43 <Alex_Gaynor> 👍