Plugin module import freezes on startup

lasselauch

Hi Maxon/Cinema4D devs!

I'm currently working with aescripts on developing their licensing system for python and for C4D. The license script is packaged in a pyz file for easy of distribution and the plugin script simply imports the pyz file to get access to the licensing system.

One problem we're facing is that for C4D plugins C4D gets stuck on startup when showing Initializing Plugins 100%. After a lot of trial and error I found out that this happens ONLY when the pyz file is bigger than ~10mb.

This doesn't happen if you run a script that imports the pyz. Only for plugins that gets loaded on startup.

Here's a link to a demo repo for you to try it out and hopefully can figure out what's causing this:

https://www.dropbox.com/scl/fo/87yyir1y6g6qrbi4mv6yr/AEwz6XxVyFuecXqlwVWxsus?rlkey=4yt2c6abiw1hdys5hgujjsre3&st=ymbhaxr5&dl=0

Any ideas on why that is and how to best prevent the freeze are welcome!

Thanks & Cheers,
Lasse

ferdinand

Hey @lasselauch,

Thank you for reaching out to us. In general, your problem is simply out of scope of support, as you are trying to get the aescripts third-party library going.

The license script is packaged in a pyz file for ease of distribution [...]

That is not quite the truth, is it? The package is clearly zipped to further increase the obfuscation which happens with pyarmor inside and to hide away its injected binaries (in /aescripts_PythonLicenser/aescripts_PythonLicenser/bin). Which also explains the package size which is otherwise not obtainable with pure Python code.

One problem we're facing is that for C4D plugins C4D gets stuck on startup when showing Initializing Plugins 100%. After a lot of trial and error I found out that this happens ONLY when the pyz file is bigger than ~10mb. This doesn't happen if you run a script that imports the pyz. Only for plugins that gets loaded on startup.

You could easily defer the loading of your package when Cinema 4D and the size would be the culprit (but that is rather unlikely because Cinema 4D loads itself 100's of megabytes when the modules are loaded). But I went ahead and did it and deferred the loading to C4DPL_PROGRAM_STARTED (the latest point in the boot sequence, this is when the user sees the c4d UI for the first time) and also to C4DPL_STARTACTIVITY (a bit earlier, but after all modules have been loaded). See PluginMessage for details. This does not really change the outcome; it just freezes then at a later point, e.g., to the point when the user sees the UI.

import os
import sys
import c4d

lic_settings = {
    ...
}

def PluginMessage(id, data):
    if id==c4d.C4DPL_PROGRAM_STARTED:
        current_directory = os.path.dirname(os.path.abspath(__file__))
        pyz_path = os.path.join(current_directory, 'res', "aescripts_PythonLicenser.pyz")
        sys.path.insert(0, pyz_path)
        from aescripts_PythonLicenser import aesl

    return True

I then had a look at your claim that 'this doesn't happen if you run a script that imports the pyz'. Your Demo_Script.py is faulty as it does not define the import path correctly, it is missing the 'res' directory and therefore only raises an import error. When you fix that, it just freezes as much as the other code (which is not very surprising since executing a Script Manager script and code after C4DPL_PROGRAM_STARTED are more or less the same thing).

import sys
import os

# Must be os.path.join(dir, "res", "aescripts_PythonLicenser.pyz")
sys.path.insert(
    0,
    os.path.join(
        os.path.dirname(os.path.abspath(__file__)), "aescripts_PythonLicenser.pyz"
    ),
)
from aescripts_PythonLicenser import (
    aesl,
    UpdateStatus,
    aesl_log,
    show_logs,
    run_license_tests,
)

Conclusion

The TLDR is here that you have there an obfuscated library which seems to freeze in any context in Cinema 4D. This could either be a flat-out bug in your library where it never exits some loop or due to the library trying to use features that are not available in Cinema 4D (multiprocessing, tkinter, asyncio, etc.). I would recommend that you get an un-obfuscated version of the library, and then try to load it from a Script Manager script with a debugger attached, to see where it hangs.

Also, py_armor and all the other things the aescripts library does will not deter any cracker. They will just crack your encrypted pyp file (which I assume you planned on doing), and remove the aescripts library. You cannot even make binary language (e.g. C++) executables crackproof, and for languages like Python, it is just a joke for anyone even remotely competent. py_armor is not a good idea. So, it stands to be questioned if all that effort is worth it. The most effective licensing system is a low effort server request for a valid user/serial number which keeps honest users honest. Crackers will remove that too, but then you have at least not poured days, weeks, or even months into a system which will be cracked within 72 hours after release.

Cheers,
Ferdinand

lasselauch

Hi Ferdinand,
I was essentially just forwarding this message from the developer of the licence framework. Sorry for not being clearer in the first place.
I showed him your answer, and here is his response. Please let me know if I can be of any further assistance.

Hi Ferdinand! I totally understand you so I'll write my findings in this mail instead. I'm not after help with my code, I just want to report the bug I found.

The pyz file is part of python and allows you to package modules in a zip file for easier distribution, it has nothing to do with obfuscation in our case, it's just easier for the end user to copy one file instead of multiple folders and files.

My finding with the 10mb file freeze comes from my trial and error. If I compile our licensing framework to work with Python 3.7-3.9 the resulting size is below 10mb, same if I compile for 3.9-3.11, same for 3.10-3.13 or what ever combo I do that ends up in less than 10mb pyz file the C4D plugin will read it but if I compile any combo where the pyz file ends up being more than 10mb the freeze happens.
Let's say I compile for C4D 2026 it will work if I compile for 3.9-3.11 and it will work for 3.11-3.13 but it won't work for 3.9-3.13, exactly after 10mb. That ends me up thinking something is going on on C4D side.

Lasselauch sadly seemt o have packaged the project a bit weird, thus Demo_Script.py is pointing wrongly. With "it doesn't happen when running a script" I mean when you run a script from Extensions -> User Scripts.
Here is another zip with all different file combos for you to try out with yourself: https://www.swisstransfer.com/d/1f1d457f-89fe-4fef-80fd-2185c0ebe34c
As you can see, using 3.9-3.13 freezes C4D but 3.9-3.11 and 3.11-3.13 does not. The internal code is exactly the same except that they package different PyArmor frameworks. I have double-checked the code and there is no execution-difference between the different pyz files.

And the whole thing about obfuscation, honestly I'm just a dev that aescripts hired to add their licensing system to python and they want to protect the code so in that area I'm just doing what I'm told.

//Jacob Danell

ferdinand

Hey Jacob,

Thank you for the added data. First of all, I have invited you to the forum to end this middle man communication, which is a bit odd.

The pyz file is part of python ...

I am aware of what pyz is, I just pointed this out because I of course looked inside your package and found all the py_armor obfuscated code and the injected binaries in there. So, I pointed out that this is bit more than just "packaged in a pyz file for ease of distribution [...]" as Lasse/you put it, the goal is here clearly obfuscation. Which is also relevant for support, as it limits what you and I can see (without getting hacky).

My finding with the 10mb file freeze comes from my trial and error ... mean[t] when you run a script from Extensions -> User Scripts.

Your code also freezes when you load it as a Script Manager script. That is what I did with the last package from Lasse, and now also yours. The code in your script is again wrong, which is why it won't freeze until you fix it. This is the code I found:

And I fixed it then to this. When I ran it then, Cinema 4D froze for two minutes or so, after that it opened a myriad of dialogs to then terminate into two crash dialogs (it was pure luck that I let it run for so long, Lasses previous version might have acted similar, but there I killed the C4D process, as soon as I saw the 'beach ball of death' cursor on MacOS).

Please read my answer below carefully, as I already pointed out most of this in my previous posting.

I would STRONGLY suggest debugging this without obfuscation. Maxon also cannot debug larger sections of code or test further packages for you. I understand that obfuscation might not be your choice, but it will make your life harder in debugging this, as you always fly blind. We of course still will provide support, but you have to provide more than "it does not work/crashes/freezes, please help us", especially when this is not code tied to our APIs.
Attach a debugger from the Script Manager and see why your code crashes/freezes (see link in last posting when unsure how to do this). But you need an un-obfuscated code base for this to make any sense.
Defer your loading to a later point, e.g., C4DPL_PROGRAM_STARTED, when you have issues in the direct plugin registration context. In that case you would always register your plugin, but then only execute it when the your own license check succeeded.
- But you absolutely cannot ship a plugin which freezes Cinema 4D for multiple minutes on startup or when invoking your plugin because your licensing takes so long. When we see this in the wild, we will have to blacklist your plugin IDs, as this damages the brand Cinema 4D. Please use threading then to not block the main thread with your long running code.
- What I did not notice before is that you apparently try to open multiple dialogs (for me it opened multiple dialogs when I ran the script). The GUI and many other systems are not yet available when Cinema 4D is still booting, e.g., in the splash screen. You can expect all systems to be up and running when C4DPL_STARTACTIVITY is emitted, but it is better to wait for C4DPL_PROGRAM_STARTED for long running tasks (i.e., the two events I tested in my previous posting).
- Please also keep in mind that Cinema 4D has its own anti-piracy measures. Python plugins are sort of special in that they work slightly different than native C++ plugin modules (the Python C++ module shipped by Maxon sort of acts as a surrogate for Python plugins in the module registration phase). But Cinema 4D won't allow plugin threads to start their own processes at this point (which you might be trying to do with your injected binaries), and threading should also be avoided at this point, as the job system of Cinema 4D might be still booting. What you are meant to do in PluginStart (or the __main__ context of a pyp file), is register your plugins. You can run some quick logic there, but you are certainly not meant to start communicating with servers and opening GUIs there. You can read here a bit more about this from a C++ system perspective.
I would recommend to do your license check in the background in its own thread once C4DPL_PROGRAM_STARTED has been emitted (so that you can also open dialogs to signal errors).
An alternative would be to do it when the user clicks the button of your command. But you should also here put it into its own thread, so that it does not block everything else.

Cheers,
Ferdinand