It is happening for us all the time, in more than 10 frames out of 180 of a simulation (resolution 550, smoothing 1, remove air bubbles Yes, speed 0.8).

Okay, here is what happened:

1. The "crash" occurred only in Debug build configuration.
2. When reading particle velocities from disk, the number of particles from the file header were not considered. They were only set in the particle system (positions, flags) reading routine. It's apparently safer to read them twice.

Here is the patch:
https://developer.blender.org/D2719

Sorry it's my first bug fixing time, i'm not sur to do it right.
I have a patch for this, can I claim this task?

Yeah, I'm on it. Just couldn't reproduce the "instant crash" on neither Linux nor OSX. So it's either really a Windows problem or a faulty build.

Ideally would be better to communicate directly with the branch's author in that kind of cases… Will let @Sebastián Barschkis (sebbas) decide now.

In the fluid domain settings, there's different Final Display and Viewport Display modes. If those match the result is the same.

OK: I've finally found some time to write some better documentation for this, but it'd be useful to check if this is correct. It seems:

This is an odd behavior indeed. Might be a mesh evaluation order issue...
However particles are subject to an overhaul in 2.8, so we are limiting the work on the current system to only regressions.
Thanks for the report, but as this is not a regression, archiving it for now.

Confirmed, issue is in DM evaluation code actually, never clears the deformedOnly flag when evaluating a generative modifier!!!

Very nice solution, Aaron! ❤

Here is a fix which uses a soft limit of 50 and a hard limit of 128:

I have observed the same bug. I guess it sill hasn't been addressed?

All I want to achieve is to fluid inflow object emit fluid the same way on non animated mesh and animated mesh. I already tried the displacement and ocean modifier, looks good but I wanted drops dripping from running character. As soon as I tick option "export animated mesh" inflow emits enormous amounts of fluid. Is there a way to make deformed mesh emit fluid like non deformed (not animated)?

Thought: perhaps renaming it to Boid Goal/Avoid field would help.

Crikey, just had a quick play—thanks Ronan!—and this is a hugely valuable feature. As he says, it lets you animate between Goals rather than moving the Goals (which produces a different effect). The lack of docs is the killer—the fact the strength needs to be negative for Goal use means it's even more unlikely folks will just stumble across its functionality.

I mentioned fluid control only to give trajectories to drops coherent with character movements.

So to make it working right I need to put into domain a FLUID object and make character mesh a FLUID CONTROL object? As far as I imagine - this way my character will not emit any drops (as my basic intention was). Am I right?

Ok, this makes sense. So we actually have a horrible case of misnaming, lacking documentation, and terrible code design.
I can look for a better way to handle this in the code at some point (when I start working on particles), but for now, I think it is a matter of fixing the docs. (And maybe coming up with a better name, as the field does not introduce any kind of "boyd behavior", but rather influences existing boyds particles...)

There is a misunderstanding, here.

Boïds fields are a 2.4x feature.
It only works with a Goal or Avoid rule for Boïds particles and a strength that must be negative for Goal rule and positive for Avoïd rule.
https://youtu.be/Uvltf_oBd9E?t=1m33s

In T51302#430826, @Peter Boos (PGTART) wrote:

Might have some weird boid uses as seen here https://www.youtube.com/watch?v=kyrhDTmPUAc

@Peter Boos (PGTART) It is not that, but the feature has no code behind it and literally does nothing.

Might have some weird boid uses as seen here https://www.youtube.com/watch?v=kyrhDTmPUAc
Its not that if you have not used some feature inside blender that you should remove it, instead learn it.
Things might not always have up to date documentation either, but still thats no reason to remove it.

I didn't look at boids.c, but since the code in do_physical_effector does nothing, and pdDoEffectors has no special case handling for boid (no calls to boids.c stuff), I can only see this force field being a noop.

I looked into this and I found this in the code:

case PFIELD_BOID:
	/* Boid field is handled completely in boids code. */
	return;

+1 for soft limit.

I really don't think this is the way to go about this. There is no point in slightly increasing the limit, as you can just as well find the new limit to be too low at some point in the future. I would be for keeping the 50 limit, but replacing it with a soft limit, that way, new users don't accidentally freeze their sims, but you are free to increase the the segments to whatever you want.