Happening on 3.3.1

Fixed by rB6dd2e193e16f.

Wrong task number in commit, sorry...

LGTM, indeed option to only reset from app template without touching to 'global' userpref seems like the best solution for me too.

I am not sure what exactly it means. If the construction of depsgraph is somehow called on an invlaid state of the view layers, then the proper solution is to hide such access behind an API. To me it does not seem to be a good design to require all areas which needs to acccess view layers to ensure re-syncing of any kind. If it is something what needs to be done during evaluation, then it should follow typical tagging process. Depsgraph evaluation should not make decision to re-sync anything if it was not tagged for.

Submitted D16150 to address this problem.

Looking into this, here is whats happening:

I think the depsgraph should ensure all view layers from all scenes it 'handles' are in sync when it starts an update process. Reason being, depsgraph expects valid 'static' data to work on (for relations building etc.), so imho one cannot expect it to work with non-updated 'dirty' viewlayers at all? @Sybren A. Stüvel (sybren) , @Sergey Sharybin (sergey), maybe you have better insight here?

@Philipp Oeser (lichtwerk) this patch makes total sense to me indeed, feel free to commit it (and tag it for backport to 3.3) :)

Hi, thanks for the report, this is a known issue/TODO that needs to be tackled at some point... Will keep the report alive, since looks like we did not have any task for materials support in liboverride yet...

You should not be able to unlink objects from a linked collection, this makes no sense, that is the bug. ;)

This is an issue between depsgraph and geometry nodetree I think... At least ASAN back trace shows that deleted collection is properly removed by depsgraph while rebuilding its relations, but for some reasons it looks like the object geometry, or its geonodetree, using the deleted collection is not (properly) updated... @Jacques Lucke (JacquesLucke) think this should be for you?

I havent checked on this reports, just noting that a similar thing came up in T101433: Delete Hierarchy operator crashes on an object whose collection is referenced by a Collection Info node with Separate Children enabled

After the link t1.blend object.
Create library override on the object.
Switch the first material slot to object mode.
Then select mat1.
Then create a local copy and rename it to mat1a.
Do the same for mat2.
Then get t2.blend.

Thanks, committed rBbf4926b30c6fc7b9f98dde508b7b644feaf21022, closing.

I can confirm the issue.

Thank you for the report.
I can confirm the unexpected behavior and forward it to the developers.

Added your bug trace to the description and updated the video for an actual example file. I think the difference between a debug and a regular build is that in debug immediately see a fall, and in a normal build it only crashes when the error becomes too fatal.

I compiled a debug build of blender (72ceb7dec136ce65261692d57d8d1251a30c5352) along with the patch from D16031 but it's still crashing (it seemed to fix T101233 though) . Debug builds don't seem to output any crash data to /tmp like a release build, so I ran it through gdb with a backtrack command after it crashed. I'll attach it here. I'm not too experienced with gdb, but hopefully it helps.

Analyzed the blend file and have the following question and remark:

• Somehow the scripts triggers a viewlayer.update(). From the stack trace it's unclear to me where this is coming from. I guess some listener is triggered when the usd_import ops is performed? Anyone any idea?
• Looking into the viewlayer.update(), it seems that the script fails because there are 2 viewlayers in the file of which 1 is only resynced (probably the active one ), the other one not. The depsgraph makes a copy of the scene which fails because of the viewlayer out of sync.

A way to solve this could be that depsgraph syncs all viewlayers before copying. Or we could mark all dest viewlayers "dirty" when copying and remove the assert.

Yes, I edited your description. I pursued the goal of localizing the error as much as possible.
I tested fix T101233 in a debug build. This error is still there. Also, when the fix for that report is in the daily build, hopefully you can also check to see if it's the same bug.

I gave what I thought was a proper bug report (steps to reproduce and a screenshot), but Illiya replaced my text with a video reproducing the bug in a slightly different way, and then later added a stack trace and blend file. It looks like my text was partially restored now. Anyway, I can confirm that the added "Delete crash.blend" attachment causes the same crash I was getting. If you delete the "Delete ME" container in the outliner and then the "Cube.001" object, it crashes. Deleting in the opposite order crashes as well. Also, as I mentioned in the steps to reproduce, you may need to do something after deleting to trigger the crash, like creating a new object in the scene.

Assert is introduced by rB68589a31ebfb: ViewLayer: Lazy sync of scene data., but quickly looking at the script I am not sure why rB4a60c4746ddf: Fix T101272: Missing view layer updates handling collections via python. doesn't fix this.

@Val Acar (valacar) @Iliya Katueshenock (Moder) can we please get proper bug report, following our template and guidelines (main things missing: reproducible .blend file and clear simple steps to reproduce the issue)? Thanks.

Thanks for the report. I'm not able to redo the crash. I guess this is same as T101233: Regression: Deleting Object in outliner with a specific filter setting crashes Blender.
Can you both confirm?
Also- It's nice to have reproducing steps written in words (video can be used as additional information)

For the minute there is no reference kept to anything outside the Blender scene. This change just exposes the existing importer/exporter logic as an option for the collection, so if you import something multiple times it will create that many duplicates in the scene.

face->num_glyphs not accurate for bfont

• Update based on feedback

@Pam Hampton (pamtango) - Also, the foreign language fonts don't work either. Also, if you type with MS Spanish keyboard accents are not shown. Two different issues, but thought I should mention them.

Also, the foreign language fonts don't work either. Also, if you type with MS Spanish keyboard accents are not shown. Two different issues, but thought I should mention them.

So how does this work if you have two collections that import the same object (maybe with different material or color for example). Is two objects created or is there some override being calculated?

Caused by rBc973d333da31: Fix T100527: Right click in the attribute name field crashes blender.
@Bastien Montagne (mont29) ^

Thanks for the report. I'll check

Can reproduce. I think there is same report as this one already, but can't find it so will confirm.

Would it make sense to name these BLENDER_USER_RESOURCES and BLENDER_SYSTEM_RESOURCES instead?

Here's a follow-up to the preview video that resolves the first issue I was having where I was unable to map the collection->import_properties to the op->ptr in the wm_usd_import_exec callback.

Weird about these dates though is that I only added the ability to use Wingding and symbol fonts with a commit on 2021-08-04 rBae920d789ed3: VSE: Allow Wingdings and Symbol Fonts. Therefore it makes sense that it is reported working on 2021-08-31. But then the "Broken" date is just a month later.

(This is the maximum accuracy that I have to identify the error based on the versions I have on my computer.)

@Harley Acheson (harley) This was my test, sorry if I was misleading.
I got confused in the files, although it seemed to me that in the end I specified everything correctly ... I'll fix it now!

@Pam Hampton (pamtango) - Your "Worked" and "Broken" versions list the same versions. And I can't tell which versions you are showing in the video. Can you please list which versions that you tested in the video?

Better selection, some cleanup.