Avoid infinite loop in EasyConfig cache#5164
Avoid infinite loop in EasyConfig cache#5164Flamefire wants to merge 2 commits intoeasybuilders:developfrom
Conversation
|
@Flamefire This is too much to include (very) last minute in EasyBuild v5.3.0 (which is now blocked by this issue). We should first make the minimal changes necessary to circumvent the problem that was introduced in #4818 It seems like that would be reverting to not using |
aa174c9 to
28f4277
Compare
I meant to do that but included unrelated changes due to |
…syconfigs are independent
|
This indeed also fixing the immediate problem, but I prefer going with my (even more) minimal PR, which reverts back to how things were done before #4818 was released: We can take the time to properly figure out what we overlooked, and also make sure a CI test is added that catches the problem (if only by searching for the |
|
Closing in favor of #5166 |
|
@Flamefire Can you open an issue with some details, as a reminder to come with a proper fix, which undoes the rollback done in #5166? |
(created using
eb --new-pr)I'm not fully sure why but #4818 leads to an infinite loop or at least heavy slowdown when parsing an easyconfig because of our way of implementing
EasyConfig::copy:We simply reparse the whole easyconfig from scratch and
finalize_dependencieswill parse the dependencies causing copies in the cache handling which parses their dependencies again leading to parsing the same EasyConfig literally thousands of times until I had to abort it.The change of adding it to the cache before doing the copy of the returned easyconfig makes it better, seems to break the infinite loop at least for a test I had. Not sure we should keep that though.
Example:
`eb PyTorch-bundle-2.1.2-foss-2023a-CUDA-12.1.1.eb`
Copies GCCcore 47 times triggering a parse each