The logs are showing a number of "Scudo OOM" warnings similar to those discussed in #121595. However, none of them have been fatal yet.

In API level 35 the memory allocator no longer prints such an alarming message when this happens. Instead it will just be a one line message like this (llvm/llvm-project#68444):

I/scudo   : Can't populate more pages for size class 8720.

Luckily, in API level 35 they've also added the ability to print the allocator statistics at any time, with code like this (llvm/llvm-project@5759e3c):

import ctypes
ctypes.CDLL(None).mallopt(-205, 0)

Based on those statistics, it doesn't look like Python has a memory leak, as the "inuse" column after the test is roughly the same as it was before. So it's probably just temporary high memory use during the test, causing allocations to be directed to the next highest size class.

On the buildbot about a year ago, these warnings were often associated with crashes. As described in Android/README.md, we worked around this by running the emulator once to create it, then editing its configuration files to increase the emulator RAM from 2 GB to 4 GB. After that, the warnings continued, but the crashes stopped.

But that isn't such a good option on GitHub Actions, because the runner is not persistent, so the extra emulator restart would add about a minute to every CI run. In theory you should be able to avoid this by creating the emulator from a custom hardware profile, but in my experiments, the emulator always ended up with 2 GB of RAM regardless of what it said in the profile.

The tests that trigger this are:

• test.test_ast.test_ast.AST_Tests.test_ast_recursion_limit
• test.test_compile.TestSpecifics.test_compiler_recursion_limit
• test.test_compile.TestSpecifics.test_stack_overflow

These tests all involve parsing an extremely long Python statement. Although they're all skipped on WASM because of limited stack space, reducing the recursion limit does not prevent the warning. What does prevent it is reducing the size of the Python statement, e.g. from 500,000 repetitions to 200,000.

Since I haven't seen these tests crash on GitHub Actions yet, I'm not going to change them just now. If they do start crashing, we can change them to reduce the statement size on Android alone, or even on all platforms if it doesn't significantly reduce the strength of the test.

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Does uses not accept variable expansions in workflow references?

@freakboy3742 it does not. But I don't think that it's neccessary or that composite actions would be any different in this regard.

Does uses not accept variable expansions in workflow references?

@freakboy3742 it does not. But I don't think that it's neccessary or that composite actions would be any different in this regard.

You may not be able to use variable expansions directly in an action reference, but you can use a variable in a checkout step, and then run the action from the checkout. This is how python/release-tools#265 works.

It'd be a bit decoupled but this is not necessarily a bad thing.

I'm not sure about that. The workflows to build and test Python are closely coupled to the scripts, makefiles, etc, which they call, all of which are in the cpython repository. And the command lines may vary from one version of Python to another. So cpython would seem like the appropriate place to maintain them.

Although the action is broken up into steps, the context of those steps is lost when it's embedded in the workflow.

I agree this wasn't ideal. I've just pushed an alternative approach which uses ::group:: markers to split up the output, which results in a much better UI.

Does uses not accept variable expansions in workflow references?

@freakboy3742 it does not. But I don't think that it's neccessary or that composite actions would be any different in this regard.

You may not be able to use variable expansions directly in an action reference, but you can use a variable in a checkout step, and then run the action from the checkout. This is how python/release-tools#265 works.

Sure - I understand how this works when used as an action; I was driving more towards the "can we use this as a workflow" approach. But if a variable isn't valid as an actions reference, then it's a moot point.

It'd be a bit decoupled but this is not necessarily a bad thing.

I'm not sure about that. The workflows to build and test Python are closely coupled to the scripts, makefiles, etc, which they call, all of which are in the cpython repository. And the command lines may vary from one version of Python to another. So cpython would seem like the appropriate place to maintain them.

I agree with @mhsmith here - I don't think decoupling the build scripts from the code repo would be a net win. It's already complicated enough having to update 2 repositories (the development guide and the code repo) whenever the build script is updated; adding third repository that requires an update isn't going to make things any clearer.

Although the action is broken up into steps, the context of those steps is lost when it's embedded in the workflow.

I agree this wasn't ideal. I've just pushed an alternative approach which uses ::group:: markers to split up the output, which results in a much better UI.

This is definitely better - still not as good as "true" actions steps, but it's a lot more legible.

Thanks for your ideas, everyone. I've now added an android.py ci command which performs the build, package and test sequence. This has several advantages:

• The command is so simple, that there's no need to wrap it in a reusable action or workflow; the cpython and release-tools repositories can invoke it directly.
• It's much easier to test locally than a script in a workflow file.
• It avoids the circular dependency we'd have with make, because the Makefile doesn't exist until android.py runs configure.
• cibuildwheel uses the same android.py test script, so handling the GitHub Actions KVM setup at this level will save all the package maintainers from needing to do it manually.

I have made the requested changes; please review again.

I've also made the corresponding changes to python/release-tools#265.

Thanks for making the requested changes!

@freakboy3742: please review the changes made to this pull request.