Search Issue Tracker
Won't Fix
Fixed in 2020.3.X, 2021.1.X
Votes
1
Found in
2018.4
2019.3.4f1
2020.2
Issue ID
1254522
Regression
No
[IL2CPP] Incorrect results when calling a method from outside Class in a Struct
How to reproduce:
1. Open the attached "MutableStructRepro.zip" Project
2. Make sure the "IL2CPP" is selected in the Project Settings
3. Build and Run the Project
4. Press the only button in the scene
Expected Behavior: Label shows "567" value
Actual Behavior: Label shows "456" value
Reproducible with: 2018.4.24f1, 2019.4.2f1, 2020.1.0b14, 2020.2.0a14
Note: The code is in "NewBahaviorScript.cs". It seems that the code in the 88th line is not executed.
-
neuecc
Sep 27, 2020 16:01
Currently, UniTask needs a workaround for this problem.
This is not desirable as it is accompanied by an extra steps.
-
tim_lol
Sep 26, 2020 09:06
A fix for this would be very helpful for async method builders. As it is, I have to `#if ENABLE_IL2CPP` to rewrite my entire builders for less efficient versions, just so it will work.
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Crash when trying to force Shader to interpret 1/30 as a floating point operation
- Terrain is flickering when adjusting "Compatibility Mode" and "Use Rendering Layers" Settings
- Isometric tiles are flickering and overlapping each other when entering Play Mode with Tilemap Renderer mode set to "Chunk"
- Crash on ParticleSystemParticles::array_reserve when particle system starts
- Docking Text Property Preview Window next to UI Builder breaks the window and causes NullReferenceException
Resolution Note (2020.2.X):
Thank you for your bug report. We have reproduced your issue and have confirmed that in the conditions:
1. A generic class A<T>
2. A generic mutable struct B<T>
3. A<T> calls a method on B<T>
4. The call to B<T> makes a call to code that accesses the B<T> instance from its original location.
5. That call makes a update a property to B<T>
The update make step 5 are lost.
Unfortunately correcting this issue will take some time to fix as it will require changes that will affect all generic method calls. This has been added to our internal issues list and will do plan on fixing it, but I cannot give you a timeframe for that fix will be available.
Please let us know if you need any assistance with a work around. But changing any of the conditions above would do so. For example if the mutable struct B<T> is not generic then the issue does not occur or if any changes to B<T> in step 4 are made directly using the this pointer then the issue will not occur.
Resolution Note (fix version 2021.1):
Fixed in 2021.1.24f1