[CI] Run tests on ARM

[moi15moi]

It might be a good idea to run the test on the windows-11-arm github action runner to catch potential issues that only occurs in that architecture.
I don't have an example for windows arm, but I had already had an issue that was only happening on linux arm cpu (due to using ctypes), so I believe we might catch some bugs.

[junkmd]

Thank you!
I think this is a really good suggestion.

Actually, I also haven’t encountered any specific issues on arm architecture yet, so I’m not entirely sure what might happen.
But precisely because of that, I believe it’s very important to try it early and identify any potential problems ahead of time.

It would be great if you could either create a draft pull request adding windows-11-arm to the workflow, or try it first in your fork and share the results — especially if you notice anything strange or unexpected.

If any tests fail or odd behavior appears, we can review it together and discuss with the community how to address it.

For the slow coverage issue with Python 3.12, we can probably handle it by adding conditional logic in the workflow if needed.

[moi15moi]

From what I can see, the unit tests fails on ARM.
To be exact, this test "seg fault".

It happen because addressof(ptr.contents) seems to access an invalid address.
If I comment self.assertEqual(addressof(ptr.contents), addressof(sc)) and and add addressof(ptr.contents), the test will still fail.
If I comment addressof(ptr.contents), the test will pass.

I believe it happen because comtypes.util.byref_at doesn't work properly, but i'm not sure what it does. It seems pretty complicated.

[junkmd]

Thank you for your investigation.

util.py has been left broken for a long time and was only recently revived, so such problems would occur.
This is an area involving many low-level details.

The followings are believed to be related to this problem:
python/cpython#136847
#445
python/cpython#130410
python/cpython#131747
python/cpython#133205

To address the problems you've reported, please try the following points:

1. Applying if sys.version_info >= (3, 14): _layout_ = "ms"

Currently, the util.PyCArgObject class has a _pack_ setting placed under a sys.version_info >= (3, 14) version bridge. However, starting from Python 3.14, using _pack_ is deprecated. The comment I added was probably a remnant from some trial-and-error session where adding _pack_ happened to make it work at the time.
In the Python versions and Windows environments currently supported by comtypes, this should work fine even without setting _pack_ at all. Instead, please try specifying the newly introduced _layout_ attribute.

2. Changing ("size", c_int) to ("size", c_ssize_t)

In CPython's implementation of PyCArgObject, the size field has been assigned Py_ssize_t since long ago.
On the other hand, when this project started (earlier than Python 3.2 and Python 2.7), c_ssize_t did not yet exist in ctypes, so c_int was likely used as a substitute. Please update it to the proper type.

[moi15moi]

I tried both suggestions on (3.11 to 3.14) and it still return an invalid adress.

[junkmd]

This might be something we should escalate to the CPython community.

If other tests are passing, do you have any thoughts on adding @skipIf to skip only the failing tests on arm64 for now?

[moi15moi]

As we can see here, there seems to be a problem with IMalloc. I still didn't have time to look into this issue, but this should be easier to found the issue.

[junkmd]

Thank you for your investigation.
I have a few questions and observations regarding the current status:

1. Investigation into test.test_util.ByrefAtTest

I would like to clarify the scope of the failures in test.test_util.ByrefAtTest on arm64.

Were all test cases within this class failing, or was the issue limited specifically to test_com_interface?
If we skip only test_com_interface, do we expect the other test cases in this class to pass?

2. List of Failed Tests (Excluding COM Server Memory Leaks)

I have listed the test failures observed in this run, excluding the known COM server memory leaks.

2.1 Missing Registry Entries in GHA (test_client.py)

comtypes/comtypes/test/test_client.py

Lines 52 to 55 in 258da0e

	def test_clsid(self):
	clsid = comtypes.GUID.from_progid("MediaPlayer.MediaPlayer")
	mod = comtypes.client.GetModule(clsid)
	self.assertEqual(mod.MediaPlayer._reg_clsid_, clsid)

There is a possibility that the required registry keys are missing on the arm64 machines used by GitHub Actions.
It might be possible to resolve this by enabling the necessary Windows features:

• dism /online /enable-feature /featurename:WindowsMediaPlayer /all /norestart
• Install-WindowsFeature DirectShow-Media-Foundation

2.2 Unexpected IMalloc.DidAlloc behavior (test_malloc.py / test_outparam.py)

comtypes/comtypes/test/test_malloc.py

Lines 28 to 45 in 258da0e

	def test_Realloc(self):
	malloc = CoGetMalloc()
	size1 = 4
	ptr1 = malloc.Alloc(size1)
	self.assertEqual(malloc.DidAlloc(ptr1), 1)
	self.assertEqual(malloc.GetSize(ptr1), size1)
	size2 = size1 - 1
	ptr2 = malloc.Realloc(ptr1, size2)
	self.assertEqual(malloc.DidAlloc(ptr2), 1)
	self.assertEqual(malloc.GetSize(ptr2), size2)
	size3 = size1 + 1
	ptr3 = malloc.Realloc(ptr2, size3)
	self.assertEqual(malloc.DidAlloc(ptr3), 1)
	self.assertEqual(malloc.GetSize(ptr3), size3)
	malloc.Free(ptr3)
	self.assertEqual(malloc.DidAlloc(ptr3), 0)
	malloc.HeapMinimize()
	del ptr3

comtypes/comtypes/test/test_malloc.py

Lines 47 to 61 in 258da0e

	def test_SHGetKnownFolderPath(self):
	ptr = LPWSTR()
	hr = _SHGetKnownFolderPath(
	byref(FOLDERID_System), KF_FLAG_DEFAULT, None, byref(ptr)
	)
	self.assertEqual(hr, hresult.S_OK)
	self.assertIsInstance(ptr.value, str)
	self.assertTrue(Path(ptr.value).exists()) # type: ignore
	malloc = CoGetMalloc()
	self.assertEqual(malloc.DidAlloc(ptr), 1)
	self.assertGreater(malloc.GetSize(ptr), 0)
	_CoTaskMemFree(ptr)
	self.assertEqual(malloc.DidAlloc(ptr), 0)
	malloc.HeapMinimize()
	del ptr

comtypes/comtypes/test/test_outparam.py

Lines 47 to 73 in 258da0e

	@patch.object(c_wchar_p, "__ctypes_from_outparam__", from_outparam)
	def test_c_char(self):
	# Allocate memory from the Python/C runtime heap.
	# This ensures the address is valid but "unallocated" from COM.
	buf = create_unicode_buffer("abc")
	ptr = cast(buf, c_wchar_p)
	# Confirm the memory is not managed by the COM task allocator.
	self.assertEqual(malloc.DidAlloc(ptr), 0)
	x = comstring("Hello, World")
	y = comstring("foo bar")
	z = comstring("spam, spam, and spam")
	# The `__ctypes_from_outparam__` method is called to convert an output
	# parameter into a Python object. In this test, the custom
	# `from_outparam` function not only converts the `c_wchar_p` to a
	# Python string but also frees the associated memory. Therefore, it can
	# only be called once for each allocated memory block.
	for wchar_ptr, expected in [
	(x, "Hello, World"),
	(y, "foo bar"),
	(z, "spam, spam, and spam"),
	]:
	with self.subTest(wchar_ptr=wchar_ptr, expected=expected):
	self.assertEqual(malloc.DidAlloc(wchar_ptr), 1)
	self.assertEqual(wchar_ptr.__ctypes_from_outparam__(), expected)
	self.assertEqual(malloc.DidAlloc(wchar_ptr), 0)

The cause of these failures is still unclear.
I wonder why even though IMalloc.Free or CoTaskMemFree is explicitly called, IMalloc.DidAlloc occasionally returns 1.

While it is theoretically possible for COM to allocate something at a recently freed address, these tests seem to fail before the memory should have been fully released.
Is it possible that the timing of COM allocation/deallocation behaves differently on arm64 compared to x64/x86?

[moi15moi]

1. I'm not able to explain why, but if I don't skip all test.test_util.ByrefAtTest, test_comserver.TestLocalServer.test_SetName fails with a leak. Example: https://github.com/moi15moi/comtypes/actions/runs/22330722980/job/64612191827
   I don't know if it is just a coincidence.

I just tried to only skip the tests you mentionned + test.test_util.ByrefAtTest and I get this result: https://github.com/moi15moi/comtypes/actions/runs/22330951316

Also, we get a strange result for this test:

test_Draw (test_viewobject.Test_IViewObject.test_Draw) ... unknown ARM CPU part 0xd49 ignored
unknown ARM CPU part 0xd49 ignored
unknown ARM CPU part 0xd49 ignored
unknown ARM CPU part 0xd49 ignored
ok

[junkmd]

The memory leak issue with the third-party COM server seems hit-or-miss — some jobs pass and others fail with no clear pattern.
Since we can usually get them to work by retrying, we're keeping the priority low for the time being.

---

test_Draw (test_viewobject.Test_IViewObject.test_Draw) ... unknown ARM CPU part 0xd49 ignored
unknown ARM CPU part 0xd49 ignored
unknown ARM CPU part 0xd49 ignored
unknown ARM CPU part 0xd49 ignored

It appears that these outputs occur because the underlying low-level libraries (such as the LLVM compiler infrastructure or the runtime) fail to recognize the specific ARM CPU and output the Part ID as a warning while inkedlib is running via x64 emulation on Arm64.

I understand this to be merely "noise" caused by missing definitions in the runtime; since the tests are passing, it does not affect the core functionality of the COM objects, such as drawing logic or memory management.
While suppressing these warnings would result in cleaner test output, we can deprioritize this for now.

---

I've confirmed that test_malloc pass with the changes you made to the malloc implementation.
Looking at the official documentation, it's clear that using SIZE_T is more appropriate than ulong.

* https://learn.microsoft.com/en-us/windows/win32/api/objidl/nn-objidl-imalloc
* https://learn.microsoft.com/en-us/windows/win32/api/objidl/nf-objidl-imalloc-alloc

Does changing _CoGetMalloc to _ole32_nohresult.CoGetMalloc also contribute to passing these tests?

I suspect that issues related to c_size_t or c_ssize_t are deeply involved here.
If there is no difference between using _ole32_nohresult and _ole32, I think it might be better to stick with _ole32.

Since the current implementation does not strictly follow the COM specifications, I would welcome a separate PR if you'd like to isolate and submit the malloc implementation fixes first.

[junkmd]

I realized I had a misunderstanding.

I just tried to only skip the tests you mentionned + test.test_util.ByrefAtTest and I get this result: https://github.com/moi15moi/comtypes/actions/runs/22330951316

I realized that this result was from 1506e99, not from the CI run of your latest commit (f8b6073).
I now understand that the IMalloc tests still fail even after changing to c_size_t and _ole32_nohresult.

I’ll add a strikethrough to my previous comment to avoid any confusion.

[junkmd]

@moi15moi

Primarily, IMalloc::DidAlloc is a method to determine if a memory block was allocated by the specific allocator.
https://learn.microsoft.com/en-us/windows/win32/api/objidlbase/nf-objidlbase-imalloc-didalloc

Whether it returns 0 after the memory has been freed might be architecture-dependent.
Therefore, I'm starting to think that asserting this behavior may not be appropriate for these tests.

Could you try removing the assertions that check the DidAlloc return value after calling CoTaskMemFree or Free?

If the tests pass after those changes, I will then look into reviewing the other remaining tests.