Help Burst backend produces array out of range errors

[locque]

Code:

System.IndexOutOfRangeException: Index {0} is out of range of '{1}' Length.

The Oni backend works just fine, but I can't get Burst to work at all. It just keeps throwing this error, framerate is chugging at a few frames and no fluid is getting rendered. I've tested in pretty much all of the sample scenes, it's the exact same problem in all of them.



I followed the setup and backends manual pages exactly. I installed the jobs, burst, collections, and mathematics package. Then I checked that burst compilation was enabled, and disabled safety checks, leak detection, and the jobs debugger. I also tried switching synchronous compilation on and off, to no effect.

Here's some proof: https://imgur.com/a/N8D4VBR


What's going on?

[josemendez]

Code:

System.IndexOutOfRangeException: Index {0} is out of range of '{1}' Length.

The Oni backend works just fine, but I can't get Burst to work at all. It just keeps throwing this error, framerate is chugging at a few frames and no fluid is getting rendered. I've tested in pretty much all of the sample scenes, it's the exact same problem in all of them.



I followed the setup and backends manual pages exactly. I installed the jobs, burst, collections, and mathematics package. Then I checked that burst compilation was enabled, and disabled safety checks, leak detection, and the jobs debugger. I also tried switching synchronous compilation on and off, to no effect.

Here's some proof: https://imgur.com/a/N8D4VBR


What's going on?

Hi there,

Can you post the full error stack trace? Never seen a similar report, and the Burst backend is the one used by default... so this is quite unusual!

Also, what Unity/Burst/Collections versions are you using?

[locque]

Here are some of the stack traces, there are tons of variations of these though, with different indices and different methods causing them.

https://pastebin.com/rAfHhxpg

I have to use pastebin since your forum considers stack traces to be spam and blocks me from posting if I put them in here.

These are my package versions, everything should be up to date:

Burst 1.5.6
Collections 1.1.0
Jobs  0.11.0-preview.6
Mathematics 1.2.5

Unity 2020.3.26f1 LTS

[josemendez]

Here are some of the stack traces, there are tons of variations of these though, with different indices and different methods causing them.

https://pastebin.com/rAfHhxpg

I have to use pastebin since your forum considers stack traces to be spam and blocks me from posting if I put them in here.

These are my package versions, everything should be up to date:

Burst 1.5.6
Collections 1.1.0
Jobs  0.11.0-preview.6
Mathematics 1.2.5

Unity 2020.3.26f1 LTS

Hi there,

All error messages indicate Burst is trying to access empty arrays (Index # is out of range of '0' length), so it seems like these aren't even initialized. Initialization happens during the solver's Awake(), and the underlying data arrays used by both Oni and Burst are the exact same. So this is really weird.

Tried running the Burst backend using the exact same versions of Unity and all packages on Windows 10 and MacOS Catalina, but so far I've been unable to reproduce this (see images below). Many of these package versions aren't verified for 2020.3.26f1 though (only Mathematics is), I'm not sure of how robust mixing unverified packages is or if it may play a role on this issue.

Does this happen consistently every time you hit play? Have you tried this on an empty project? What platform/OS is Unity's editor running on? What CPU do you have? Are you using quick enter play mode (domain reloading disabled)?

I have to use pastebin since your forum considers stack traces to be spam and blocks me from posting if I put them in here.

We use Cleantalk as our anti spam filter, the reason that appears in its logs for considering your previous post as spam is that it was reposted multiple times in a very short timespan (the message appearing in the logs is "Forbidden: You sent forms too often. Please wait a few minutes.") I've manually flagged it as "not spam" though.

You should be able to post logs without issue, many other forum users routinely do this. Let me know otherwise so that I can delve deeper into this!

[locque]

Does this happen consistently every time you hit play? Have you tried this on an empty project? What platform/OS is Unity's editor running on? What CPU do you have? Are you using quick enter play mode (domain reloading disabled)?

Yes, it happens every time. Burst has never worked once on my setup.

I tried this on an empty project with nothing other than the fluid package and the dependencies.

Unity is running on Windows 10, and my CPU is a Ryzen 5900X. Windows and BIOS are up to date.

Not sure about the quick play mode thing, I never heard about that. I didn't modify any of the default editor settings though.

We use Cleantalk as our anti spam filter, the reason that appears in its logs for considering your previous post as spam is that it was reposted multiple times in a very short timespan (the message appearing in the logs is "Forbidden: You sent forms too often. Please wait a few minutes.") I've manually flagged it as "not spam" though.

I noticed that too, but that was the error I got yesterday. I tried again earlier today and got a different message that clearly stated spam as the reason for the post being blocked, and I was immediately able to post after removing the stack traces from the post even after resubmitting numerous times.

[josemendez]

Yes, it happens every time. Burst has never worked once on my setup.

Have you tried any other Burst based stuff in Unity? are you able to get any Burst-compiled code to run at all?

Unity is running on Windows 10, and my CPU is a Ryzen 5900X. Windows and BIOS are up to date.

This CPU has the SSE 4.2 vector instruction set, so Burst should be able to generate code for it.

Not sure about the quick play mode thing, I never heard about that. I didn't modify any of the default editor settings though.

It's an experimental Unity feature, unsupported by Obi as of now. It's disabled by default, so unless you've manually turned it on it should be no issue (https://docs.unity3d.com/Manual/Configur...yMode.html)

I'm afraid it's going to be very hard to pinpoint the cause since I'm unable to reproduce it under the same conditions. The only difference between our setups as far as I can tell is the CPU, I'm using a Core i9. If we cannot figure out the cause all I can do is offer you a full refund :/.

[locque]

Thanks for the refund offer, but I'm fine with using Oni for now.

I don't think there is a way around using preview packages though, is there? Jobs isn't even verified for 2019.4 unless the manual page is wrong : https://docs.unity3d.com/2019.4/Document....jobs.html

No idea what the status of Collections is for 2019.4 since that doesn't even have an entry in the manual.

I'll do some more experimenting with Burst and update you in case I figure the problem out.

[josemendez]

Thanks for the refund offer, but I'm fine with using Oni for now.

No worries, let me know if you want it at any point.

I don't think there is a way around using preview packages though, is there? Jobs isn't even verified for 2019.4 unless the manual page is wrong : https://docs.unity3d.com/2019.4/Document....jobs.html

Jobs is a preview package and required by Obi, so there's no way around using it.

However "verified" is not the opposite of "preview". A verified package is one that has been tested with and known to work with a specific Unity version. See: https://docs.unity3d.com/Manual/pack-safe.html

There's many packages that are out of preview, but non-verified. These show no tags at all (no "preview", but no "verified" either) in the package manager. The Burst and Collections versions you're using are not verified, which means they haven't been tested to work correctly with 2020.3.26f1. It's Unity's way of saying "should work, but we cannot guarantee it". On the other hand, a package being "preview" means "use at your own risk, this package is subject to undergo massive changes at any time".

I've tried the same versions you listed and they did work for me though. It stands to reason that for common use cases most package versions should work with most Unity versions. That's why I'm unsure of how much risk one assumes when using unverified packages. I doubt it has any impact on the issue you're facing, but I guess trying the verified versions can't hurt.

[locque]

Finally managed to get Burst running, but only in 2019.4 with Jobs 0.2.10.

There must have been a massive change in the 0.11.0 Jobs update, which asks you to recompile scripts and replace obsolete APIs unlike all other version leading up to it. Unfortunately that's the only version that works with 2020.3, every older version causes this error:

Code:

Library\PackageCache\com.unity.jobs@0.2.9-preview.15\Unity.Jobs\IJobParallelForDefer.cs(73,85): error CS8377: The type 'U' must be a non-nullable value type, along with all fields at any level of nesting, in order to use it as parameter 'T' in the generic type or method 'NativeList<T>'

I'm building for x64 Windows, does Burst perform better than Oni on that platform? I do want to get the best performance I can get, but if it's a marginal difference I'm not sure that's worth downgrading my workflow to 2019.4.

[josemendez]

Finally managed to get Burst running, but only in 2019.4 with Jobs 0.2.10.

There must have been a massive change in the 0.11.0 Jobs update, which asks you to recompile scripts and replace obsolete APIs unlike all other version leading up to it. Unfortunately that's the only version that works with 2020.3, every older version causes this error:

If Unity asks you to update obsolete APIs, do not accept (at least at first). Chances are it will break the existing code, Unity even warns you to make a backup just in case. This is because the auto-updater only works well in trivial cases - name function changed, property replaced by a method, etc. Most of the time it will render things useless.

Obsolete APIs are "simply" deprecated, which means they are subject to change/removal in the future. This is typically the case with preview packages, however doesn't mean the code is broken in any way.

This being said, I just reimported Obi and tested what happens if you let Unity automatically update the code and it made no difference for me. Things still ran perfectly afterwards, using jobs 0.11.0.

I'm building for x64 Windows, does Burst perform better than Oni on that platform? I do want to get the best performance I can get, but if it's a marginal difference I'm not sure that's worth downgrading my workflow to 2019.4.

Burst does perform slightly better than Oni in Windows (difference is negligible, maybe 0.1-0.2 ms) but it also has much better profiling tools, integrated with Unity's profiler. You also have the full C# source at your disposal, which can be a good thing if you want to future-proof your project (I can also make the Oni C++ sources available to you, but you'd need to recompile them and that's cumbersome).

If you don't see the project needing maintenance 10 years into the future, or don't care about profiling there's no downside to using Oni as your backend.