Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crashing with RecursionError #154

Open
dixie-flatliner opened this issue Sep 16, 2021 · 14 comments
Open

Crashing with RecursionError #154

dixie-flatliner opened this issue Sep 16, 2021 · 14 comments

Comments

@dixie-flatliner
Copy link

dixie-flatliner commented Sep 16, 2021

Fresh install of Vapoursynth, fresh install of Python 3.9, fresh install of Windows.

Lots of packages seem to trigger a Recursion Error with the traceback in crash_a.txt. "upgrade-all" triggers one with the contents of crash_b.txt. There's no clear common denominator (some fail, some don't), and the messages are exactly the same regardless of the script. Have also tested with both the script provided in the official installer, and the latest commit from this repo.
Notably the example command (vsrepo.py install havsfunc ffms2 d2v) is triggering the former.

crash_a.txt
crash_b.txt

Apologies if this is some form of PEBKAC scenario I've created.

@theChaosCoder
Copy link
Collaborator

Same happend to me with latest python 3.9 + VS R54 stable in Windows-Sandbox (basically a fresh windows).

@myrsloik
Copy link
Member

Is this with the R54 vsrepo or master?

@theChaosCoder
Copy link
Collaborator

theChaosCoder commented Sep 17, 2021

vsrepo master. R54 does not work bcs of the agent thingy.

@theChaosCoder
Copy link
Collaborator

It seems it only happens with packages where havsfunc is a dependency. I will test later more.

@theChaosCoder
Copy link
Collaborator

Removing "nnedi3_resample" from havsfunc as a dependency "fixes" the installation. Still unclear why it happens.

@theChaosCoder
Copy link
Collaborator

theChaosCoder commented Sep 17, 2021

And removing muvsfunc from nnedi3_resample "fixes" it also... there is some kind of dependency-check-loop created here.

This happens also on my pc with everyhing = latest pre-realese version.

compile first, then don't forget to extract the vspackages3.json (<= this really is annoying, we should either keep the generated json or make a "keep" parameter so it does not get deleted on compile. I always forget it while testing packages...)

use portable installation
python vsrupdate.py compile
python .\vsrepo.py -p -t win64 install nnedi3_resample -s vscripts

@myrsloik
Copy link
Member

nnedi3_resample => muvsfunc => havsfunc => nnedi3_resample

Simple rule: smaller wrappers like nnedi3_resample shouldn't depend on the gigantic script collections.

Additional detail: nnedi3_resample probably shouldn't rely on the old nnedi3 since znedi3 is a perfect replacement. Could also apply to other scripts.

@myrsloik
Copy link
Member

And nnedi3_resample only uses muvsfunc.Depth. This could be trivially done with the internal resizer but apparently we need 2 extra dependencies there. Sigh...
I really don't feel like implementing a circular dependency detector so I suggest we drop muvsfunc as a nnedi3_resample dependency for now.

@theChaosCoder
Copy link
Collaborator

Yes lets drop muvsfunc.

I don't really know how dependencies are currently handled in vsrepo, but I would build an install list first (going through each package only once) and then you basically only need to trigger the dl function for each item in the list.

@theChaosCoder
Copy link
Collaborator

@dixie-flatliner Please run vsrepo update again and check if everything is ok now.

@dixie-flatliner
Copy link
Author

dixie-flatliner commented Sep 17, 2021

Indeed it is. Sorry for making a report here for what wound up being a problem with a script.

@theChaosCoder : that install list idea is sounds really logical.

@myrsloik
Copy link
Member

The list idea is only worth it if we're going to allow circular dependencies. I'm not sure we should. If anything I'd rather add vsrupdate code to verify there are no circular references.

@theChaosCoder
Copy link
Collaborator

Yeah some kind of check would be good or this will happen again someday.

I just noticed that the dependency is mvsfunc and not muvsfunc... 😑

@myrsloik
Copy link
Member

These are great module names! I've never confused myself either!
Will add some check for this later. Keeping this issue as a reminder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants