09:32 <ctismer> Found the problem: We are crashing when trying to retrieve the partial function.

09:32 <ctismer> static auto *const _partial = Shiboken::String::createStaticString("partial");

09:32 <ctismer> static auto *const partial = PyObject_GetAttr(functools, _partial);

09:34 <ctismer> cfbolz: is matti around in these days?

09:37 <cfbolz> ctismer: he has been on vacation, I think back tomorrow? Or next week?

09:39 <cfbolz> ctismer: do. You feel like giving me some C code that shows the problem? I can also try to look into it

09:48 <ctismer> cfbolz: Ok, fine! Here is the crashing function. It is retrieving the partial function from Python.

09:48 <ctismer> https://www.irccloud.com/pastebin/TrpIVbRg/partial

10:03 <ctismer> doing that segfaults, but I did not debug any further because I can't make sense of the generated code (also obscure since I have an ARM now)

10:08 <ctismer> I have confirmed that the crash is really in that last PyObject_GetAttr call.

10:11 <ctismer> We can probably work around that, but it really is an astonishing bug :D

10:35 <ctismer> Ahhh, the `_functools` module seems not to exist.

11:24 <ctismer> Fixed :-)

11:39 <cfbolz> ctismer: aaaaah, right. why did it work on an older version then?

11:40 <ctismer> No idea, maybe an alias was there

14:46 <ctismer> _functools is a builtin module which gets extended by functools. Maybe they did a clean-up

15:00 <tumbleweed> https://foss.heptapod.net/pypy/pypy/-/issues/3861 ?

15:20 <ctismer> yeah, but _functools is totally gone, now. Anyway, things work for us with functools

16:20 <cfbolz> ctismer: _functools in cpython is an 'accelerator module' that might or might not be there

16:21 <mattip> maybe PyObject_GetAttr should check for a NULL obj

16:23 <mattip> but CPython does not check for NULL, so why should we?

16:30 <mattip> I guess since this is C, it should be on the caller to make sure after every call there was no error returned

17:32 <ctismer> I used that function because I prefer a builtin since I don‘t have to check if it was tampered with. And I was away fron PyPy for about a year, so I was much surprized.

17:39 <ctismer> Was the function existent by accident in PyPy 7.3.9 or why did I get no crash?

17:40 <ctismer> s/function/module/

17:42 <ctismer> Ah, I will handle the accelerator module as you said cfbolz, thank you!

17:55 <ctismer> mattip: things are very different. CPython will probably stick with this internal acceleration, and I used this because it‘s a builtin. PyPy has no reason to accelerate itself. But being an immutable builtin is a welcome security measure for us. Admittedly an abuse :-)

18:15 <tumbleweed> ctismer: see the ticket I posted above for what happened there (the module was removed to fix that bug)

19:10 <mattip> PyObject_GetAttr(obj, name) will segfault if obj is NULL. Someone needs to check that. The implementation of PyObject_GetAttr does not do any validity checks

19:10 <mattip> neither in CPython nor in PyPy

21:21 <ctismer> Yes, why should it. _functools is a builtin module. There is by definition no reason to check anything of a builtin. This is now lost by the removal of _functools, and I need to verify that I really get the function that I expect. A bad move in my eyes.

21:32 <jean-paul[m]> del _functools.partial totally works.

21:32 <jean-paul[m]> It might be builtin but it's still a hateful sack of mutable state

21:33 <jean-paul[m]> I think you have to say "I don't mind if it segfaults sometimes" or "I'll check for NULL (and probably other things) everywhere".

21:33 <jean-paul[m]> which you say is, of course, up to you :)

21:33 <jean-paul[m]> (put another way, it was always possible for it to segfault, the _functools change that actually happened merely realized one of those ways)

21:48 <ctismer> Hmm, you are right jean-paul[m] it was only obfuscation by the name but it is not safe since this is not read-only. And there is no way out because there is no API to access this reliably. Thanks for the correction, how sad. There should be a layer for extensions that gives a secure way to access internals without exposing their implementation.

21:53 <ctismer> That was really a very wrong assumption that builtin modules were read-only. Sigh… I stand corrected

23:40 <ctismer> tumbleweed: Now I understand the reference you gave :)