It still append with today build , here is the crash log, tested on bug_02.blend

Hm, I cannot reproduce the crash (linux).
What I can reproduce is the behaviour of T57125 (element selection drawing not in sync between instances) -- but not the crash...

Rebuilt from scratch after my previous comment to know for sure. But I can repro OP's issue when using a Debug build (compiled from source) which allows the assert to hit. I was also unsuccessful in creating a repro .blend; the act of saving and then re-loading the .blend seems to fix the issue. Perhaps the mesh loop/normal data is not being updated correctly after one of the operators but is being updated on .blend load?

happens with mac too

Hmpf, release builds should not abort on assert… but anyway… we need to be able to reproduce that, please attach a corrupted .blend

I got it. I was just explaining that mesh from curve is not the only thing about curve that does not work as it should. Beveled Curves are not supposed to behave like that.
And several other things don't work as they should for other types of objects than meshes.
It will be fixed when a developer will take time to review curves. But for the moment, most of work done was focusing on meshes, armatures and new grease pencil objects.

I missed the "don't post bugs for 2.8 unless crashing" rule. So it shouldn't be here.
However I don't know what are you talking about anyway. I have trouble turning curve into a mesh. That's the reason I posted it here. So I don't propose anyting regarding bevel start value and blah blah, I propose that curve to mesh works just like in 2.79. Get it?

Can confirm this (although I am not sure this is solvable easily)
`
Subdivide smooth depends on vertex normals. These are mostly fine when having meshes with faces but are more "problematic" in edge-only meshes.
(you can inspect these with the Normals Overlay)

@Dalai Felinto (dfelinto) No worries, and sorry I didn't respond right away. Yeah that's OK with me, I'm just glad to have helped contribute a bit to blender. :) I'll be back to supply whatever I can, so no worries.

I can reproduce. There is no crash.

Please don't use this task as a place for bug reports. In the future open a new report. Although this is not a crash, it is a feature considered done and then a valid bug (if the reporter went through the trouble of checking if the operator is marked as done). That said, William's explanation is point on, and the tool is behaving as designed.

Well, it's tricky to make a proper behavior on this. But user still expect 'auto join' in my opinion.
Thanx for explanation by the way!

You might want to bridge faces on several objects at a time.

In T54643#539686, @William Reynish (billreynish) wrote:

Oleg are those two different objects? If so I don't think it will work. You also cannot create edges or faces between different objects.

We could have a better error message here though.

Oleg are those two different objects? If so I don't think it will work. You also cannot create edges or faces between different objects.

@Dalai Felinto (dfelinto) MESH_OT_bridge_edge_loops committed but it is not working at all 😞

Please follow our submission template and guidelines, also read these tips about bug reports, and make a complete, valid bug report, with required info, precise description of the issue (only ONE issue per report!), precise steps to reproduce it, small and simple .blend and/or other files to do so if needed, etc.

Operator implemented on rBffb424c85f8e7a1c1c2d1722eda261b007525613

As a user of blender who sculpts I also consider this a bug. It is reasonable to expect an up to date mesh when you hit shift-z while sculpting (to e.g. check how the model looks in chosen lighting setup) , there is no indication, explanation or, honestly, logic to its current behaviour and it's inconsistent with how Blender works in other modes.

It's a known limitation of the ABF method unfortunately. We can try to invent some new algorithms to solve this, but it's beyond the scope of a bug.

Ah, ok, this is a debug assert triggering which is perhaps why you didn't see the crash. Happens on latest git pull from the blender2.8 branch still.

Not sure there is any bug here, not all UV unwrapping methods work well for all kind of geometry… Could be mere floating point precision limitations, etc. @Campbell Barton (campbellbarton) or @Brecht Van Lommel (brecht) may know better here?

Cannot confirm that with current branch, might have already been fixed, can you please try again with latest build?

@Germano Cavalcante (mano-wii) that is kind of separated issue, not directly related to that bug imho.

I don't really like the idea of keeping a looptris pointer for each object evaluated.
Since the bmesh does not change, these looptris would be exact copies and it would be necessary to make sure to recalculate the looptris in each access.

Issue is in fact exact same one as with undo/redo: in macros, when next operator needs access to evaluated data, we have to ensure depsgraph is properly evaluated before calling that next operator:

Hrrmmm… we have a CDDerivedMesh with a NULL mvert array, that shall not happen… @Sergey Sharybin (sergey) maybe that’s on your desk (subdiv stuff)?

@Raphael Victal (Blenderaiser) This is a separate issue which involves depsgraph tagging (poke @Sergey Sharybin (sergey)). Please create a new report for that one.

Hi guys, I've tested and it's crashing. When I click on 'Mark Freestyle Edge', the Blender closes.

Option is there in the Overlays though… @Jeroen Bakker (jbakker), @Clément Foucault (fclem), can one of you check on that? Thanks.

Uh, this is actually same as T56167…