Indeed… :|

Well, RigidBody does not necessarily assume there is only one scene having it? So code above should not just handle first scene found with a RBW, imho, should be applied to all potential scenes having it.
And if no scenes have it, then just call BKE_rigidbody_free_object() instead? With a NULL rbw (which shall be OK, since if there are no rbw in any scenes, there should be no RB sim, hence no runtimedata like rbo->shared->physics_object [rbo->shared is calloc'ed on readfile, so its pointers are NULL until RB sim is run]).

Well, don’t see how body of the code needs to be aware of internal logic of the macro, with my proposition? Anyway, since we are making patches, added D4384 to illustrate it. ;)

@Sergey Sharybin (sergey) drawing code is not calling mesh_calc_modifier (afaik). Drawing code is getting an evaluated mesh which, somehow, is missing CD_MLOOP data. This should not happen, ever, and seems to only happen in case of threaded evaluation with several mesh objects…

I see your point, but meh… Am not a big fan of such splitting… :/

Thanks, but eeeeeeek!

Well, looks like this is a threading issue between (presumably) draw code and scene evaluation (aka depsgraph eval), so would like to summon @Sergey Sharybin (sergey) and @Clément Foucault (fclem) here.

You could have asked to orig author of that code, would have been simpler…

@Clément Foucault (fclem) I think that is drawing code issue in fact, adding a printf at start of DRW_curve_batch_cache_create_requested(), I get things like:

Noted some quick things below, but not sure why you assigned this to me? Am not particularly familiar with nodes code, think maybe @Brecht Van Lommel (brecht) would be best dev here?

@Sergey Sharybin (sergey) I suspect by the time of writing that was correct, and call to BKE_object_runtime_reset() was added later? Anyway, no, this did not cause any issue afaik, otherwise I would have noted it in comment. ;)

Checking a mesh integrity is not a cheap process, so we cannot do it on a regular basis, would slow things down too much in production files. So yes, once meshes are corrupted, one can expect various issues, including crashes and co. Point is, corrupted meshes are not supposed to happen at all (and happen very rarely with core Blender code, usually they are generated buy some broken add-on)… Bugs leading to such situation are considered pretty serious, but we cannot do anything without being able to reproduce the process leading to that corruption.

That mesh is corrupted, selecting it and running "C.object.data.validate(verbose=True)" in the py console gives me:

ERROR (bke.mesh): /home/i74700deb64/blender/__work__/src/source/blender/blenkernel/intern/mesh_validate.c:536 BKE_mesh_validate_arrays: 	Poly 4 has duplicated vert reference at corner (2)
ERROR (bke.mesh): /home/i74700deb64/blender/__work__/src/source/blender/blenkernel/intern/mesh_validate.c:554 BKE_mesh_validate_arrays: 	Poly 102 needs missing edge (60, 63)
ERROR (bke.mesh): /home/i74700deb64/blender/__work__/src/source/blender/blenkernel/intern/mesh_validate.c:554 BKE_mesh_validate_arrays: 	Poly 102 needs missing edge (63, 103)
ERROR (bke.mesh): /home/i74700deb64/blender/__work__/src/source/blender/blenkernel/intern/mesh_validate.c:662 BKE_mesh_validate_arrays: 	Loop 16 is unused.
ERROR (bke.mesh): /home/i74700deb64/blender/__work__/src/source/blender/blenkernel/intern/mesh_validate.c:662 BKE_mesh_validate_arrays: 	Loop 17 is unused.
ERROR (bke.mesh): /home/i74700deb64/blender/__work__/src/source/blender/blenkernel/intern/mesh_validate.c:662 BKE_mesh_validate_arrays: 	Loop 18 is unused.
ERROR (bke.mesh): /home/i74700deb64/blender/__work__/src/source/blender/blenkernel/intern/mesh_validate.c:662 BKE_mesh_validate_arrays: 	Loop 19 is unused.

Re usercount of IDs outside of a Main, main library.c code already expects outside-of-main IDs to not do any refcounting (with things like BLI_assert((flag & LIB_ID_CREATE_NO_MAIN) == 0 || (flag & LIB_ID_CREATE_NO_USER_REFCOUNT) != 0); e.g.).

Can be either disabled FBX add-on, or some other add-on 'crashing' python while loading, which will prevent any further ad-on loading during startup… please open blender from a command line and attach here the messages printed in the OS console…

Please include the OBJ file here…

Hey, added you to the Translations project, and the ab.po file to the SVN repo, you should be ready to go! :)

Those are two different operators/operatioons, but do not see why copying material from IDTemplate widget should not also duplicate its actions. Fix incoming.

@Jacques Lucke (JacquesLucke) yes, that something like that that should have been made from the start. But no, people like to complicate things at global level, just for the sake of some immediate, localized simplification… Thing is, doing that now is not trivial at all, given the plate of spaghetti that is NodeTree code. Would involve a lot of careful checking and testing to ensure nothing gets broken on the way. Never had the courage to dive really into this. :|

@Sebastian Parborg (zeddb) with an ASAN build on linux, this should always lead to an hard crash with heavy complains of 'using memory after free' ;)

File->new triggers a "Main nuke", which means we do not clean up properly every IDs, and count on order in which ID types are freed to save us from that kind of issue.

Eeeeeeh! What do we say about reporting several issues in same report? xD

@Jacques Lucke (JacquesLucke) Will do this, Node code is a real nightmare when it comes to ID management, with all its weird specific types of copying processes… :(

From T61440:

Eeeh indeed missed your comment in T43295, best would be to merge this one there, and add additional requests from @Michael Soluyanov (crantisz).

First of all, this is not a bug report at all, and should not be handled here. We have a site for that kind of question: https://devtalk.blender.org/

EEEh! Patch by @Mikhail Rachinskiy (alm), sorry, thought arc land was preserving author… :/

Seems to make sense to me, @William Reynish (billreynish) @Sergey Sharybin (sergey) @Brecht Van Lommel (brecht) @Campbell Barton (campbellbarton) any of you guys against that change (switching default boolean modifier op to Difference).

Eeeh, no, never worked on that even… I’d say try to poke @Campbell Barton (campbellbarton) again, maybe? Otherwise, just commit, you'll get reports soon enough if you break something ;)

Thanks for the report, but general assessments like that do not really help, we cannot separate everything in Blender. Please provide specific cases (with exact, complete message that has several meanings, and which meanings absolutely need to be separated).

I would think this is an issue on the importer… Here are material definitions for both (in same FBX file) (using our JSon extraction of FBX binary data):

BKE_modifier_get_evaluated_mesh_from_evaluated_object() is doing plain rubbish in EditMode case… That was probably true at the time it was written, but we do have valid final and deformed (aka cage) evaluated meshes in BMEditMesh, nowadays. So fix is actually quite simple. ;)