[BUG] Encryption may generate functions that cause Python to crash after 1024 or 2048 calls.

[irreg]

Encryption may generate functions that cause Python to crash with a memory access violation (0xc0000005) after 1024 or 2048 calls.

The exe is generated from source code containing about 5000 functions, and this has occurred 4 times in about 200 encryptions. (In other words, a problematic function is generated with low probability, and if we generate it again with the same py file, it will not occur.)
The function that causes the problem appears to change randomly each time it is generated.

The command at the time of generation is as follows

• pyarmor pack -s main.spec -x "--restrict=101 --exclude .venv" main.py

The above command generates a single exe file, but the problem also occurs when the exe file is disassembled back into a .py file and executed

I tried to find out as much as possible about one of the files where the problem occurred.
It seemed that the error occurred at the moment of calling a particular encrypted function from a particular encrypted function in another file. I replaced one of the two files with an unencrypted one and the problem no longer occurs.
However, I have not been able to get any detailed results because of the encryption.

Is there any possible known or resolved cause?
I will add more if I find out anything else.

C:\Users\Admin>pyarmor info
INFO     PyArmor Version 6.8.0
INFO     Python 3.8.9
ERROR    [Errno 2] No such file or directory: '.pyarmor_config'

OS: Windows 10 x64

[jondy]

Try to upgrade latest Pyarmor 7.x version: 7.7.4

It's better to provide sample script could reproduce in my side

[jondy]

Also try to remove option --restrict=101

[irreg]

Thanks for the reply. I have tried what you pointed out.

• Pyarmor 7.7.4: No change, error still occurs.
• Remove --restrict=101: No change, error still occurs.

I've created a reproduction code below.

Abstract

This is a procedure that creates 10000 files that may cause problems and then runs and tests them all.

File structure

root
|- run.py # Entry point
|- main.py* # Script to launch sub-processes from the main process
|- sub.py* # Script to call the files these are causing the problem
|- mod.py # File that may cause problems after encryption
|- cls.py* # Definition loaded from mod.py
|- duplicate.py* # Script to copy mod.py to suspects folder 10000 times before encryption

Files marked with * do not require encryption; the problem reproduces without encryption.

File Contents

run.py

import main

if __name__ == '__main__':
    print("start")
    main.run()
    print("end")

main.py

from concurrent.futures import ProcessPoolExecutor, ThreadPoolExecutor, as_completed
import sys
import re


def submit(n):
    import sub
    sub.run(n)


def execute(n):
    with ProcessPoolExecutor(max_workers=1) as e:
        future = e.submit(submit, n)
        future.result()


def run():
    max_workers = 12
    n_list = list(range(10000))
    continue_on_error = False
    for arg in sys.argv[1:]:
        if matched := re.search(re.compile(r"-*worker=(?P<num>\d+)"), arg):
            max_workers = int(matched.group("num"))
        elif matched := re.search(re.compile(r"-*range=(?P<begin>\d+)[,:-](?P<end>\d+)"), arg):
            n_list = n_list[int(matched.group("begin")):int(matched.group("end"))]
        elif matched := re.search(re.compile(r"-*continue-on-error"), arg):
            continue_on_error = True
        else:
            print(arg)
    e = ThreadPoolExecutor(max_workers=max_workers)
    futures = [e.submit(execute, n) for n in n_list]
    try:
        for future in as_completed(futures):
            n = n_list[futures.index(future)]
            try:
                future.result()
            except Exception as ex:
                print(f"{n},failed: {ex}")
                if not continue_on_error:
                    raise
            else:
                print(f"{n},success")
    finally:
        for future in futures:
            future.cancel()
        e.shutdown(wait=False)

sub.py

The reproduction probability will decrease if there is not some complex processing before calling the function in mod.py.
A script that can be reproduced with a relatively short effective description is described in sub.py.
Updated on November 1 as a faster method was found. If this complex processing is executed at least 8 times at the end, the probability of occurrence seems to be almost the same

import pandas as pd
import importlib


class A:
    def a(self, a, b):
        pass

    def b(self, t):
        pass


def run(n):
    mod = importlib.import_module(f"suspects.mod{n:04}")
    for i in range(1025):
        if i > 1015:
            aaa = [pd.DataFrame({j: [0.0] for j in range(97)}).astype("category") for _ in range(4)]
            for a in aaa:
                for s in "abcdefg":
                    a[s] = ""
            bbb = [a.to_numpy() for a in aaa]
            c = pd.DataFrame({"": [0.0]}).astype("category")
            d = c.to_numpy()
        mod.f(A(), A())
        if i % 100 == 0:
            print(f"{n},{i}")

mod.py

I couldn't find a way to reproduce it in a shorter description.

from cls import C


def f(a, c):
    l = list()
    n = ""
    l.append(n)
    if c is None:
        t = C(C(a=l).x({n: None}))
    else:
        t = c
    a.a(a=True, b=True)
    r = C(a.b(t))
    r.x = l
    return r

cls.py

class C:
    def __init__(self, a):
        pass

duplicate.py

import shutil
import os

os.makedirs("suspects", exist_ok=True)
for i in range(10000):
    shutil.copy(
        r"mod.py",
        rf"suspects\mod{i:04}.py",
    )

Reproduction environment

• Windows 10/11 x64
• Python 3.8.9
• Pyarmor 6.8.0/7.7.4
• (pandas 2.0.3)

Reproduction procedures

1. Arrange files as written in the File structure
2. Execute python duplicate.py
3. Execute pyarmor obfuscate run.py --recursive
4. Move to dist folder
5. Execute python run.py

The following is no longer necessary because sub.py could be made faster (updated November 1). It takes about an hour.
Since it takes more than 10 hours to test everything, it is recommended to divide the work among several PCs with the range=x:y option specified.

python run.py range=0:5000

The default setting is to stop when one problematic file is found, but if you want to get all results without stopping, specify the options as follows.

python -u run.py continue-on-error >result.csv

In my environment, I found about 1 or 2 files per 1000 files with errors. The error does not always occur even in problematic files, and some files have only a 1% or less chance of error (for the current sub.py description). The probability of occurrence varies from file to file.
Since some files only occur with low probability, it may be necessary to repeat the test hundreds of times to find all problematic files.

[irreg]

@jondy Could you please reopen it?

[jondy]

Sorry, in test scripts, there is third-party library pandas, generally I only debug Python offical system library, not other libraries.

And pyarmor obfuscated scripts has different frame, for example, sys._getframe(1) will get different frame as original scripts.

And someone else has reported the issues about pandas to use sys._getframe to query some local variables.

So there are 2 solutions, first patch pandas, there are some examples for Pyarmor 8, but it also works for Pyarmor 7
https://pyarmor.readthedocs.io/en/latest/how-to/third-party.html

The other solution is to use --obf-code 0 to obfuscate the related scripts, the default options for other scripts.

[irreg]

It seems that sys._getframe is never called in this code. I will continue to investigate.

[irreg]

We have investigated the cause.
Apparently, it occurs in many cases if the function is calling native code (written in C language etc.).
I was able to reproduce it even with ThreadPoolExecutor and sqlite objects in the standard library as shown below.

sub.py ver.2

import importlib
from concurrent.futures import ThreadPoolExecutor

class A:
    def a(self, a, b):
        pass

    def b(self, t):
        pass

def a(c):
    b = ThreadPoolExecutor()
    return ThreadPoolExecutor()


def run(n):
    mod = importlib.import_module(f"suspects.mod{n:04}")
    for i in range(1025):
        if i > 1015:
            ccc = [a(ThreadPoolExecutor()) for _ in range(512)]
        mod.f(A(), A())

sub.py ver.3

import importlib
import sqlite3

class A:
    def a(self, a, b):
        pass

    def b(self, t):
        pass

def a(c):
    b = sqlite3.connect(":memory:")
    return sqlite3.connect(":memory:")


def run(n):
    mod = importlib.import_module(f"suspects.mod{n:04}")
    for i in range(1025):
        if i > 1015:
            ccc = [a(sqlite3.connect(":memory:")) for _ in range(512)]
        mod.f(A(), A())

No error seems to occur when using "--obf-code 0". However, considering the results so far, it is a little difficult because all codes must be set to "--obf-code 0". (If the conditions that cause the problem are met, a remote encrypted file that is completely unrelated to those conditions will cause an error.)

We also checked the behavior with version 8 (trial).
It was reproduced when using the old command, but may not be reproduced when using the new command.

old: pyarmor-7 obfuscate run.py --recursive
new: pyarmor gen run.py . -r --private

If there is no problem with the new command, that's enough, but I would appreciate it if you could add it and find out what the problem was.
Thank you for your response.

[irreg]

Although the CPU is different, there appear to be many similarities in the conditions of occurrence and problems with issue #885. It may be the same case. (Confirmed that advanced 2 and restrict 2 options have nothing to do with reproducing the problem)

[jondy]

@irreg If Python > 3.6, try it with Pyarmor 8.

[irreg]

I have tried it on Pyarmor 8.4.3.

I can reproduce the problem by executing the encrypted file with the following command.

• pyarmor-7 obfuscate run.py --recursive

I could not reproduce the problem when using the new command as shown below.

• pyarmor gen run.py . -r --private

However, the new command does not work with Restrict Mode 100+ we were using. Because of this, We are seriously looking for a replacement for this feature.

[irreg]

We further investigated the conditions under which the problem occurs in version 7 and found that the problem can be reproduced with any content of the mod.f function as long as the bytecode before encryption is 16, 48, 64, 192 or 448 ... instructions.

Therefore, it will also occur in the following cases

mod.py (48 Instructions)

def f(a, c):
    if None is not None:
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None
        x = None

[jondy]

How about only obfuscate mod.py by --obf-code 0?

First obfuscate all the scripts with normal options, save to dist/
Then obfuscate mod.py by --obf-code 0, save to dist2/
Next copy dist2/mod.py to dist

Thanks for your efforts, but now Pyarmor 8 still has tasks, pyarmor.man, Refine RFT mode, enhancement for BCC mode, after that it's Pyarmor 7 bugs.

The prefer solution is to upgrade Pyarmor to 8+

This issue may be as knonwn issue for Pyarmor 7