Bug [Fixed] Unable to get memory profiler to capture snapshot on device with 2019.3.13

Hi Jerome,

Thanks for the bug report. While you're already checking earlier versions, could you maybe check if this doesn't happen pre 2019.3.12f1? We do know of this bug introduced in that version while fixing some native connections not being properly reported. If you don't have the issue in such earlier versions it is very likely a duplicate of that issue and the fix for that one is already in flight.

Cheers,
Martin

 

Thanks for checking
To be clear, in flight in this case means on a branch, waiting for a risk assessment and approval, then going through a myriad of automated testing while being merged and eventually landing on the 2019.3 branch, where the issue is then verified on by Release QA (additional, post landing check. Our team internal QA already tested the branch). That branch then will be released as a new 2019.3 version. 2019.3.14f1 is already branched off from that so it'll be .15 or later depending on how fast this all goes.
You can check the link in my last post to see if it got verified as having landed on 2019.3 and which version it will come with.

I hope this fix will get to you asap and that you can manage around that for the time being. And sorry this slipped up in the first place.

As to alpha testing this, it'll hopefully land rather simultaneously across 2019.3 2020.1.0b and 2020.2.0a and quickly enough that a dedicated build for testing this would just complicate or delay this or similar work and likely cause you more trouble than it's worth too

 

Yeah, we did reflect on this one and we know parts of the reasons why it regressed and landed without noticing it. Normally we'd also add a regression test but here's already part of the reason for why it slipped. While we're still fixing up the Profiler connection to be fully stable (and mockable) we can't create stable automated tests for these cases :/
That and this issue just happened to not occured in the manual tests that we did due to sheer bad luck...

Anyways, we're working on the connection stability, setting up a stable networked test environment, and then we'll get automated test coverage for this (easier said than done, so yes to the complexity ) so this will hopefully occured less. We're also building up a stronger manual test case.

 

The fix has landed on 2019.3.15f1 (which isn't yet available) so it will become available soon

 

uh... that shouuuld work. Then again, there were some backend changes in 2019.3 and the Package UI in 2019.3 might be expecting to be able to take a screenshot (which 2019.2 can't provide)...

So just to clarify how I understand your situation, connecting a 2019.3.15f1 Editor to a 2019.2.2f1 build:

• Taking a Memory Snapshot in the Editor via the Memory Profiler Package UI fails *
• Taking a Memory Snapshot in the Editor via API works, i.e. captures on the connected device and sends the file to the Editor
• Taking a Memory Snapshot in the Player via the API doesn't create a file on the device even though the callback returns true

*(Warning: Since the player would be lacking the backend improvements, it could take quite a while to capture, both on the device, freezing up the Player and while processing it in the Editor. The later would still be faster the newer the package version is.)
Did I get that correctly? (Apologies for asking, I just wanted to make sure I got the combination matrix right.)

If that is the case, it would certainly look like the screenshot code is the issue here. The Package UI has no chance of knowing the Unity version of the Player you connected to, so it just assumes it is UNITY_2019_3_OR_NEWER. Profiler data streams now have that info, starting from somewhere in the 2019.3 alpha version range. However, the Memory Profiler can't rely on the Profiler recording frames from the player to then use that info to know which Unity version it is... So this might not be feasible for us to fix retroactively and 2019.2 has gone out of support so we couldn't even backport this.

That said, you can totally go through the MemoryProfiler.cs file in the package, search for UNITY_2019_3_OR_NEWER as it relates to the Capture calls and turn that into

#if UNITY_2019_3_OR_NEWER && false

to temporarily fix it for your current situation

As another work around, you can also try to take the capture with a 2019.2.2f1 Editor (you can just open an empty project). If that successfully gets you a file, you can then hit "Import" in any other Editor to pull that snapshot over from where it was stored (or simply move the file over).

 

Actually, we might be able to provide a backwards snapshotting compatibility option to the UI if this is really just about the screenshot... I'm just not sure how often that would be used and how often it would just cause more confusion than be helpful.