Today I noticed a scene I’ve worked on a week ago or so can not be switched to anymore otherwise Blender Thread Dead-Locks:
Program received signal SIGINT, Interrupt.
0x00007fffeec9ffcf in pthread_cond_wait () from /lib64/libpthread.so.0
(gdb) bt #0 0x00007fffeec9ffcf in pthread_cond_wait () from /lib64/libpthread.so.0 #1 0x0000000001384e9f in BLI_task_pool_work_and_wait () #2 0x000000000116e715 in scene_update_tagged_recursive () #3 0x000000000116ecdb in BKE_scene_update_tagged () #4 0x00000000009cefc2 in wm_event_do_notifiers () #5 0x00000000009c8e40 in WM_main () #6 0x00000000009aeb83 in main ()
I tried importing the scene alone into a fresh blend file but it keeps on dead-locking. Is there a tool somewhere which is able to fsck and repair blender files? It’s really annoying if you can’t even import the scene into another file.
This is against the latest GIT version. I tried different versions before and the bug seems to be in the code base since a longer time.
Hi, if you can reproduce a crash with one file it is important for the developer to get this file and your system specs, Blender version and so forth.
Those crashers are often easy to fix because you can reproduce it.
Please follow the description and give all information you have.
A “head programmer” with a test file and a suspect of a bug in multiple versions of Blender who doesn’t use the bug reporting system visible to all users. Expected there to be a report already when you claim there’s a problem in Blender, especially if it might be corrupting the saved files.
No need to agressive. Most bug tracking systems I come across are private or semi-private with public READ but not public WRITE (aka invite only or only after acceptance check). I had an account long time ago on projects.blender but as I see it things changed and it is no more operational. I could try make another account (if this is even possible with the same email) but the test file is unfortunately project internal so I can’t give it out for testing. What I could do is doing traces or take a look at the sources but in my experience such a large code base is not suitable for a quick check. This would need a longer time invested to get enough of a grasp to do a meaningful debugging.
I asked this here to see if somebody else came across something similar or if there is a fix-script known which can check and fix certain issues (and might perhaps help) not getting flamed. I really have no time for flaming crap.
I GDBed now the situation of a new file importing the problematic scene from the original file and switching to the imported scene. Importing works but switching to the scene freezes again. The backtrace is a bit longer this time but contains the same culprit: “scene_update_tagged_recursive”. Whatever is wrong is in there.
What’s interesting is the following. I create a new blend file and removed everything from the scene. Then importing the problematic scene works but in the empty scene a camera and an armature appear from the imported scene. So it seems blender somehow messed up storing two objects in the file to belong to scene X (the problematic one) while actually belonging to another scene Y. I conclude from this that linking objects to another scene is the true culprit having messed up. I’ll see if I can somehow fix this with a python script knowing which objects must be the problem.
I also tried reactivating that old account from projects.blender.org since they claim having ported those over but to no avail, it’s broken. Login is not working and resetting password is not working (no emails received and I have full control over the mail-server). I also can not contact any admin since I find nowhere a support page nor any kind of contact field for problems (as guest without a working login). Creating a new account is also not possible since it complains about another user using the same email (what I expected). So unless you know an admin that can fix this Escher situation I’m unable to get anywhere on that website.
EDIT: Yep. If I disable this edge split modifier from the outliner before switching on the layer with the mesh on the dead-loop is gone. This modifier is the problem.
More testing. Looks like the true culprit is an import-linked mesh from another file. In this file I can trigger the same bug if I go to the scene with the mesh in it and show the layer it is located on. So this dead-lock happens during update for rendering of a certain mesh. Good news it’s only an temporary export model which I can delete and recreate from the original low-poly model but the bad news is why does blender dead-lock on such a simple mesh?
I think I get closer to the problem. Create a new blend file and imported only the problematic object. Blender dead-locks again but with a more informative stack trace:
#0 0x0000000000f282ab in bmesh_vert_separate ()
#1 0x0000000000f28e7e in BM_vert_separate_hflag ()
#2 0x0000000000f6300a in BM_mesh_edgesplit ()
#3 0x0000000000f060ec in applyModifier ()
#4 0x000000000103e4bd in mesh_calc_modifiers ()
#5 0x000000000103f430 in mesh_build_data ()
#6 0x000000000103f6ad in makeDerivedMesh ()
#7 0x000000000113251a in BKE_object_handle_data_update ()
#8 0x000000000112c816 in BKE_object_handle_update_ex ()
#9 0x000000000116e146 in scene_update_object_func ()
#10 0x0000000001385963 in BLI_task_pool_work_and_wait ()
#11 0x000000000116f015 in scene_update_tagged_recursive ()
#12 0x000000000116f5db in BKE_scene_update_tagged ()
#13 0x00000000009ceff2 in wm_event_do_notifiers ()
#14 0x00000000009c8e70 in WM_main ()
#15 0x00000000009aebb3 in main ()
So I conclude that some combination of “edge” flags causes the EdgeSplit modifier to enter a dead-loop. I think that’s now worth a bug report… if only I could make one on that developer page.