GeezerVison

Enable tests for 3.13 in the same PR?

@filmor @lostmsu - is there a plan for enabling support for 3.13? I see this PR has been stale for quite a while already. Just checking what's the status :)

All development is public. You can see here that the "simple" approach of adding new offsets (that I have indeed verified) fails. Debugging gave me additionally that it crashes in some very early dictionary access, but I don't really know how to go further.

According to cvdump "c:\Program Files\Python313\python313.pdb" (cvdump from here), the PyHeapTypeStruct is stated to have a size of 928 bytes:

[...]
S_UDT:             0x1211, PyHeapTypeObject
[...]
0x1211 : Length = 58, Leaf = 0x1505 LF_STRUCTURE
	# members = 13,  field list type 0x1210, 
	Derivation list type 0x0000, VT shape type 0x0000
	Size = 928, class name = _heaptypeobject, unique name = .?AU_heaptypeobject@@, UDT(0x00001211)
[...]

However, when I look at the value of the TypeOffset313.init value, it is also 928.

We seem to have one property too much, don't we?

Aaah, got it, thanks @kunom!

The issue is that, unlike all other members, the new tp_watched and tp_versions_used attributes are char and uint16_t. I'll update our geninterop script to pick this up and release a new version latest tomorrow (CET).

I might have to release a new version of clr-loader as well to bump the cffi dependency.

/edit: Actually, fixing the generator requires more work that I don't think is worth the effort, seeing that we should remove the direct type offsets eventually. I will just lazy-fix this by dropping one of the fields, alignment does the rest.

Not shure whether this still matters, but I was finally able to produce an offset listing of the full 3.13 struct PyHeapTypeObject using Ghidra reverse engineering. According to that tool, the following struct members have a size different from 8:

But as you correctly noted, due to alignment, only the tp_watched;tp_versions_used; combination matters.

On my local machine, the embedding tests also pass for 3.13. I'll have to spend some more time tomorrow to get the CI going, but I'm quite confident that I can release a new version either tomorrow or this weekend.

Not that I'm against 3.13 support, but this seems to fail multiple tests and should have been marked alpha, or manually released calling our NuGet monthly build for preview packages, IMHO.

It is not failing tests, our CI is just a bit rusty. I ran a many combinations locally and will follow up in the next week to reactivate the excluded platforms.

@filmor I'm receiving a 'Attempted to read or write protected memory' error in my C# code when interacting with Python 3.13. This suggests potential memory corruption. Could this error be due to incompatibility with Python 3.13, or is it a sign that 3.13 is not supported?
var m_threadState = PythonEngine.BeginAllowThreads(); using (Py.GIL()){}