-
-
Notifications
You must be signed in to change notification settings - Fork 349
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
[Bug]: Under multithreading, using the isOverriding method will lead to incorrect results of the getElements method #5619
Labels
Comments
MartinWitt
added a commit
that referenced
this issue
Jan 17, 2024
Synchronization logic has been added to the method adaptation process in the TypeAdaptor class to prevent multi-threading issues. This change was necessary because without synchronization, simultaneous modifications by multiple threads could lead to inconsistent or unexpected results. The relevant issue can be found at #5619.
I-Al-Istannen
pushed a commit
that referenced
this issue
Jan 17, 2024
When checking whether a method overrides another, we need to adapt both methods to a common ground. In an early version this required cloning the entire method, including its body, to perform the adaption. PR #4862 fixed this by nulling the body before cloning the method and then restoring it afterwards. This operation is not thread safe, as it may write concurrently and also modifies what other parallel threads might see when traversing the model. This patch now introduces a private override specifying whether we are only interested in the signature. If that is the case, we explicitly construct a new method using the factory instead of cloning the original. Closes: #5619
I-Al-Istannen
added a commit
that referenced
this issue
Jan 17, 2024
When checking whether a method overrides another, we need to adapt both methods to a common ground. In an early version this required cloning the entire method, including its body, to perform the adaption. PR #4862 fixed this by nulling the body before cloning the method and then restoring it afterwards. This operation is not thread safe, as it may write concurrently and also modifies what other parallel threads might see when traversing the model. This patch now introduces a private override specifying whether we are only interested in the signature. If that is the case, we explicitly construct a new method using the factory instead of cloning the original. Closes: #5619
SirYwell
pushed a commit
that referenced
this issue
Jan 22, 2024
When checking whether a method overrides another, we need to adapt both methods to a common ground. In an early version this required cloning the entire method, including its body, to perform the adaption. PR #4862 fixed this by nulling the body before cloning the method and then restoring it afterwards. This operation is not thread safe, as it may write concurrently and also modifies what other parallel threads might see when traversing the model. This patch now introduces a private override specifying whether we are only interested in the signature. If that is the case, we explicitly construct a new method using the factory instead of cloning the original. Closes: #5619 Co-authored-by: I-Al-Istannen <i-al-istannen@users.noreply.github.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Under multithreading, using the isOverriding method will lead to incorrect results of the getElements(new TypeFilter<>(CtExecutableReference.class)) method;
This bug is sporadic, executed multiple times and only shows up sometimes
Source code you are trying to analyze/transform
Source code for your Spoon processing
Actual output
Expected output
Spoon Version
10.4.3-beta-2
JVM Version
11
What operating system are you using?
win
The text was updated successfully, but these errors were encountered: