Usage of fully qualified names causes the engine to crash. #5037
Comments
hubertp
added
p-high
|
Reproducible. Caused by #3663 which changed from |
|
And here is a follow up culprit - serializer was silently crashing because we weren't catching the exception: |
|
Hubert Plociniczak reports a new STANDUP for yesterday (2023-02-07): Progress: Continued investigation into the crash. I think I have a better understanding of the crash and why we should revert to Next Day: Next day I will be working on the #5037 task. Discover why we don't recover gently from serialization problems, come up with a fix for serializing FQNs |
An exception encountered during serialization prevents engine from continuing because it enters an infinite loop(!). # Important Notes The aim of this PR is to make it possible for engine to recover from the serialization failures. Any failure would mean that we enter an infinite loop in deserialization which is in turn waiting for the serialization to finish (which will never happen). In this particular case FQNs are [referencing concrete modules](#5037). A separate PR will address that.
|
Hubert Plociniczak reports a new STANDUP for yesterday (2023-02-08): Progress: Created PR for an issue when a crash in serializer would render engine unusable - deserialization would enter an infinite loop waiting for serialization to finish; serializer already finished (via a crash) but didn't communicate it.Continued investigation for the actual failure itself - turned out in FQNs we weren't properly preparing metadata for serialization/deserialization (toAbstract and toConcrete conversions were incorrect). It should be finished by 2023-02-09. Next Day: Next day I will be working on the #5568 task. Come up with a test case and start looking into performance improvements to import/export |
|
Hubert Plociniczak reports a new STANDUP for yesterday (2023-02-09): Progress: Coming up with a setup for the test-case took longer than expected but overall quite happy with the state of PR (no further failures so far). During QA took special attention to the logs of project-manager serializer and noticed weird caching problems that led to constant recompilation during startup, for a clean project. Going down the rabbit hole led me to filing #5608 which might improve our performance. Started looking at the state of import/export resolution. It should be finished by 2023-02-09. Next Day: Next day I will be working on the #5568 task. Main focus is improving/caching import/export resolution. |
Serialization of FQNs' metadata was broken - we attempted to serialiaze concrete modules and that's against the design. Added a test illustrating the problem which would previously fail during serialization. Closes #5037 # Important Notes It is still hard to discover problems like this because SerializationManager creates system threads; when the exception occurs, it is typically not the real cause. Creating regular threads via `createThread` seems to be problematic for `native-image`. There is a simple workaround for the former but will leave it out for another PR to simplify the review.
github-project-automation
bot
moved this from 🔧 Implementation
to 🟢 Accepted
in Issues Board
This task is automatically imported from the old Task Issue Board and it was originally created by Paweł Grabarz.
Original issue is here.
When a node is added or modified to contain a fully qualified name, the engine crashes and a project needs to be restarted. If the file was saved with the fully qualified name in script, the project immediately crashes on startup as well.
Minimal code example :
Engine logs after fresh startup:
Comments:
(Paweł Grabarz - Feb 3, 2023)
Maybe a duplicate of #184389924 (Hubert Plociniczak - Feb 3, 2023)
The text was updated successfully, but these errors were encountered: