The builds from Buildbot are fine, only happens with my self compiled build.

I did a full clean build, did not fix it. Attaching my system-info here, no idea whats wrong.

Check if it's a regression since some previous release (checkout to a previous releases, compile them and see). If so you can bisect what revision caused the issue.

I'm on very similar setup to the buildbot and release environment and can't reproduce the issue, so unlikely to help here.

I get kernel_assert failures relating to the emission part of the L_sum here:
https://developer.blender.org/diffusion/B/browse/master/intern/cycles/kernel/kernel_accumulate.h$450

@Sergey Sharybin (sergey): It only happens after enough time into the simulation, presumably when the smoke starts intersecting the domain box.

@Lukas Tönne (lukastoenne), any particular frame number i am to render to see that? What frame you rendered anyway? :)

Frame 26 for example (after rerunning the sim from the start).

I get the non-finite assert as well, but it happens way less often than in @Thomas Dinges (dingto)'s screenshot, so the NaNs I get might actually be unrelated to the bug here.
Anyways, by enabling floating point exceptions (P356), I already found two areas that might cause trouble:

• intern/cycles/kernel/kernel_volume.h:294 may divide by zero if full_transmittance is one (which I guess is quite common) - mathematically, that makes sense since distance-based sampling is impossible in fully transparent volumes. However, I guess detecting that case and not using MIS in that case would be the more stable solution.
• intern/cycles/kernel/kernel_volume.h:629 may overflow when ray->t is FLT_MAX and the step size is lower than 1 - generally, the conversion to an integer might overflow here. The more stable approach would be to compare ray->t to global_max_steps*step_size and set max_steps to global_max_steps if it's larger, only doing the divide and cast otherwise.

I can just go ahead and handle these two points, but maybe they're known and actually fine?

@Lukas Stockner (lukasstockner97), think those two would be safer to address those two points. Please go ahead.