#Bursted code behaving differently in release build only

1 messages · Page 1 of 1 (latest)

wraith wolf
#

We use a type 'ObservableEvent' that is a fixed-size key-value store using an fixed byte array, mapping semantics to untyped values. The event generation is working fine unless the code is called in a bursted context in a release build; it seems to fill the data with zeroes and not much else (from what I can tell).

I've tried with various BurstCompile settings on the assembly level to see if I could reproduce the problem in-editor, but I can't. The build logs none of the related errors either. My initial hunch was this has something to do with type sizes/offsets, but I didn't have any real idea yet. After putting debug logs everywhere, things suddenly worked... so I made several builds to figure out where, and I found that if I put logs in ObservableEventBuilder.Build(), the code does what it's supposed to do.

I assume this is a burst compiler bug. We're on 1.8.7 currently. Before I submit a bug report, I figured perhaps it's a known issue. Did anyone see something similar?

Code below.

proven hill
#

Where is observableEvents defined

#

Soon as I hear someone putting logs in and it working i immediately think you have a timing issue

#

Only happens in builds because things are faster

#

Or the system order has been changed

spark lantern
#

there have also been bugs in the past where logs triggered or un-triggered bugs in burst's screw-with-the-IL-before-translating-to-llvm stages, so it's not impossible

proven hill
#

oh definitely, i've reported a couple myself (long time ago though)

#

I just like to rule out user error first

wraith wolf
#

observableEvents is a dynamic buffer created at the start, there are 7 of them that are being cycled through

#

personally I thought maybe this temporary variable is being optimized a little too greedily 🤷

    ObservableEvent @event = _event;
    this = default;
    return @event;
#

the logs tell me it's adding an event with all zeroes into the dynamic buffer, so I doubt the issue is related to a timing thing

#

(unless I misunderstand what you mean perhaps)

proven hill
#

I mean you've turned off safety and something like you have two jobs writing to it at once and it causes issues only in builds

#

Basically I just wanted to check if safety was turned off or not

wraith wolf
#

ah, well, this stuff isn't even jobified

proven hill
#

Oh, well in that case it rules out like 95% of user errors

#

I'd suggest posting this on burst forum

#

Burst devs usually quite interested in stuff like this

#

(and maybe an official report)

wraith wolf
#

I submitted a bug report already, you reckon it's worth adding a forum post?

proven hill
#

From my experience you'll get a faster response