Just re-tested with Blender 2.76b and problem don't appear.

Hello Sergey,

Thanks for having a look at this :-)

• Does it happen with latest builds from builder.blender.org?

I didn't give a try but will do for sure.
I had to de-install 2.77a as it caused problems (at least for me) and switched back to 2.76b.
I will test with last build anyway.

• Try using opengl32.dll from ftp://ftp.blender.org/sergey/softwaregl/ and put it next to blender.exe. This will switch Blender to fully software OpenGL mode, which is slower but will eliminate possible interference with broken OpenGL drivers (which could be a case here).

Ok. What I also noticed is that I have quite regularly problems after "minimizing" the Blender windows : it doesn't re-open correctly and application needs to be closed down and restarted. Maybe an OpenGL issue indeed...

Ok, gave a try with blender-2.77.0-git.29a17d5-AMD64

Problem still persists even when opengl32.dll in folder and running in software mode.

Tried to "debug" but I'm not too familiar with all the Windows debug tools (WER ?)

Is there a way I could help you out any further ?

Hello Sergey,

I'm very much afraid that at the time I opened up this thread, I actually didn't feed you with enough material to test :-{
I do have to apology as the file in question has multiple dependancies to other linked files and I mistankently overlooked a bit this point...

So, I have now made a .zip file hopefully containing all the material to simulate :

As in previous posts, with 2.77a (or even latest build), making any change to the file and un-doing it (CTRL-Z or via "history") cause Blender to unexpectedly close. This phenomenon do not appear with 2.76b.
This has also apparently nothing to do with an OpenGL issue.

Thanks a lot for your help and support,

Bernard

Don't really have time right now to investigate, but thanks for additional information. We'll check it shortly!

Ok Sergey,

Let me know if I could be of further help anyway.

Thanks for your time and efforts.

BRGDS,

Bernard

Was looking into this bugs, seems it's caused by create_placeholder in readfile.c

This creates a place-holder on file read, however its lost on undo, (seems like this is caused by the library data being reloaded but not the placeholder).
Which is freed from setup_app_data, but kept in the .

Looking into some possible fixes (either create new placeholders, or move them out of Main so they're not freed).

@Bastien Montagne (mont29), any insights here?

This fixes the bug, but seems a bit hackish - P365

Hello Bastien, Campbell,

To answer your question: not that I'm aware of (meaning I have checked everything to the best of my knowledge).

Everything links correctly, even multi-dependencies objects (e.g. the camera - the illustrated object - is made up of multiple parts which are located in the "G3_Parts" folder).

My local setup is exactly similar to the one I have enclosed fro reference (Blender_Crash.zip).

What I was thinking of doing is to "depopulate" the scene from its objects one by one up to a point where - hopefully - the problem doesn't appear anaymore... Is it worth a try ?

Let me know If I get your point wrong or if I messed up with something.

Looking forward to hearing from you guys, and anyway : fantastic job !!!

BRGDS,

Bernard

Hello Bastien,

I'll further investigate and hopefully provide you with a much simpler setup to test with.

Up until know, I could indeed isolate the object that causes Blender to crash.
This might have indeed something to do with the multi-level linking as this object has multiple dependencies but which all seem beeing correctly resolved.

I keep you posted anyway.

BRGDS,

Bernard

Hello Bastien (& other followers),

Sorry, but it took me some time to nail down the issue in a simplified set-up.

Please find herewith a file that would allow you to reproduce the problem :

In short, it goes over linking a group of linked objects (themselves being a group of object).
Maybe a bit hard to explain but the file exemple is pretty straightforward.

Hope it helps,

Bernard

Hey @Bernard Etiennot (beti001), thanks for the file, but it’s not crashing at all here, tried several actions & multiple undo, nothing wrong :|

I can recreate the crash on AMD X3 455, r7 360, loaded factory settings:

Opening _Linked_Component, moving it it and then making an undo will crash Blender.
Sometimes two objects disappear after the first undo and after the next one there is a crash.

Win 7:

Blender versions:
hash: 049f715, e0db647, b567835, rB6d3fdccbd580

The cmd doesn't say much:

ED_undo_push: Translate
undo Translate
Error: EXCEPTION_ACCESS_VIOLATION

Linux:
Xubuntu 15.10
Blender version: a58a8eb

The terminal
Segmentation fault (core dumped)

However, here is the crash dump:

Hi, this is Estefania, the person who reported the bug. I would like to clarify that my crash happened with 2.76b. I was not aware 2.77a version existed when it happened.
I am sorry I did not clarify it earlier, but I am not an engineer/computer scientist so I was a little intimidated by the email updates and I did not notice the report had been titled: Blender 2.77a crashes ... Anyway, I suppose you might not be able to crash 2.77a with multiple Undo commands if the bug happened in 2.76b.
Sorry for the misunderstanding. I have learned to read the reports and to log in here to look up for "my" case to offer my thoughts. Hope I will be more useful in the future.
Best regards.

@Bastien Montagne (mont29) Hello Bastien, my mistake not having given any indication about how to reproduce the issue with the simplified setup. Entry point is indeed the _Linked_component file which just contains a link to a group made up of two other linked groups (still difficult to formulate indeed). Undoing any cmd lke e.g. move or rotate is just crashing Blender 2.77a while this behaviour doen't happen with 2.76b.
This particular phenomenon was indeed well described by @Vuk Gardašević (lijenstina), thanks for this.
Hope you will be able to reproduce.

To @Estefania (estefania), thanks for your feedback and comment which are of course welcome. Just one point that I noticed though is that - at least as far as I could test - the specific problem that I reported is not appearing with 2.76b.
So I'm just wondering if the root cause of your issue would be exactly the same as the one reported here (although software bugs may sometimes lead to strange side effects).

Looking forward to your inputs,

BRGDS,

Bernard

Ah yes, now can reproduce indeed. Thanks, will try to investigate this one next week…

Well done Bastien !
I will give a try. Is your fix going to be available through the next night build ?

Thanks a lot for your efforts & involvement. Errors are only made by those who dare to act and make things moving... ; -)

Bernard

@Bernard Etiennot (beti001) Yes

@Aaron Carlisle (Blendify) Thanks Aaron.