[BUG]: Python 3.13 Runtime Crash (Access Violation) after prolonged execution - suspected conflict with Adaptive Interpreter

[reshet]

Environments

Build Platform: Tested on both Linux (Docker) and Windows 10/11 GitHub Actions runner.
Runtime Platform: windows.x86_64
Python: 3.13.5 (Upgrade from 3.9.13)
PyArmor: 9.2.3 and 9.1.8 (Upgrade from PyArmor 7)

Command line

pyarmor reg /tmp/myapp/pyarmor_9.2.3-ci-8101.zip
pyarmor -v
pyarmor gen \
    --platform "windows.x86_64" \
    --obf-code 1 \
    --no-wrap \
    --output "/tmp/myapp/obfuscated-working-dir/myapp" \
    --exclude "**/tests/*" \
    ./

Description

We are migrating a production application from Python 3.9 / PyArmor 7 to Python 3.13.5 / PyArmor 9.2.3.

We are encountering a critical stability issue where the obfuscated application crashes with a Memory Access Violation (0xC0000005), but only after a significant period of runtime (varying between 4.5 hours, 7 hours, or 24+ hours depending on the environment workload).

Key Observations:

• Delayed Failure: The application runs thousands of iterations of its main logic loops successfully. The crash occurs abruptly after hours of normal operation with no runtime data changes or spikes.

• Location: The crash occurs in different code paths depending on the workload, but always in "hot" loops that have been executed frequently.

Isolation confirmed via obf-code:

When obfuscated with defaults (--obf-code 1), the crash is reproducible.
When obfuscated with --obf-code 0, the application survives indefinitely (24h+) without any memory errors.

Cross-Platform Build Behavior:

We tested building on Windows-for-Windows: Result is a hard crash (Access Violation) after ~4.5 hours.

We tested building on Linux-for-Windows (both times using --platform windows.x86_64): Result is "soft" corruption—the app continues running but begins reading invalid/nonsense data from memory after the same time period.

Analysis & Theory

Since the issue correlates with "hot" loops and only occurs in Python 3.13 (which introduced the Tier 1 Adaptive Interpreter and bytecode rewriting), we suspect a conflict between PyArmor's bytecode encryption and the interpreter's attempt to optimize/rewrite these "hot" instructions in memory.

Given that PyArmor docs state support for Python 3.13 and 3.14, we assume this behavior is accounted for, but our testing suggests the optimizer is eventually corrupting the encrypted memory space.

Expected Results
The application should remain stable indefinitely, as it did with Python 3.9/PyArmor 7, or there should be a recommended configuration to disable conflicts with the Python 3.13 Adaptive Interpreter.

Actual Results
Process termination with 0xC0000005 (Access Violation) or memory corruption after 4-24 hours of runtime. This is currently a release blocker for us.

[jondy]

Thanks for your analysis, if it's as you guessed, Python 3.13 Tier 1 Adaptive Interpreter and bytecode rewriting results in this issue, my sugesstion is to use Pyarmor v9 new scripts like RFT/VMC/ECC, please refer to Pyarmor 9 new features

https://pyarmor.eke.org.cn/v9.html