Ctr-Z causes instant crash #64163

New Issue

Greshame Carr · 2019-05-05T09:20:48+02:00

Greshame Carr commented

2019-05-05 09:20:48 +02:00

{F7007002}System Information
Operating system: Windows-10-10.0.17134 64 Bits
Graphics card: GeForce GTX 1060 3GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 417.35

Blender Version
Broken: version: 2.80 (sub 60), branch: blender2.7, commit date: 2019-05-03 21:09, hash: ee0d8426ab
Worked: (optional)

Short description of error
Ctr-Z causes instant crash

Exact steps for others to reproduce the error
In blend file Buggy Toy, Join atom buggy.002 to atom buggy using ctr-j
use ctr-z to undo this join.
blender file crashes.
the crash will occur with any subsequent use of ctr-z should you not use it after this event, but after any future event.

undo steps 256 undo memory limit 0 global undo ticked.

{[F7007002](https://archive.blender.org/developer/F7007002/Buggy_Toy.blend)}**System Information** Operating system: Windows-10-10.0.17134 64 Bits Graphics card: GeForce GTX 1060 3GB/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 417.35 **Blender Version** Broken: version: 2.80 (sub 60), branch: blender2.7, commit date: 2019-05-03 21:09, hash: `ee0d8426ab` Worked: (optional) **Short description of error** Ctr-Z causes instant crash **Exact steps for others to reproduce the error** In blend file Buggy Toy, Join atom buggy.002 to atom buggy using ctr-j use ctr-z to undo this join. blender file crashes. the crash will occur with any subsequent use of ctr-z should you not use it after this event, but after any future event. undo steps 256 undo memory limit 0 global undo ticked.

Greshame Carr commented

2019-05-05 09:20:48 +02:00

Added subscriber: @The_Doctor

Garry R. Osgood commented

2019-05-05 12:51:32 +02:00

Added subscriber: @grosgood

Garry R. Osgood commented

2019-05-05 12:51:32 +02:00

I have seen this bug here using OP's file (it has been renamed to buggytoy.blend).

(gdb) set args /media/render/gosgood/twoeight/human/buggytoy.blend
(gdb) run
Starting program: /home/gosgood/git_repositories/build_linux_debug/bin/blender /media/render/gosgood/twoeight/human/buggytoy.blend 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7fffd2fff700 (LWP 1034)]...

   (omitted for brevity...)

...[New Thread 0x7fff7e3ff700 (LWP 1151)]
Thread 1 "blender" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
- 0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
- 1  0x00007fffeaccb391 in __GI_abort () at abort.c:79
- 2  0x00005555577ff18a in DEG_get_evaluated_scene (graph=0x7fff72f12c08) at /home/gosgood/git_repositories/blender/source/blender/depsgraph/intern/depsgraph_query.cc:151
- 3  0x0000555557afb780 in wm_event_do_handlers (C=0x7fffd3c58708) at /home/gosgood/git_repositories/blender/source/blender/windowmanager/intern/wm_event_system.c:3096
- 4  0x0000555557aef83d in WM_main (C=0x7fffd3c58708) at /home/gosgood/git_repositories/blender/source/blender/windowmanager/intern/wm.c:418
- 5  0x0000555557451c24 in main (argc=2, argv=0x7fffffffdb98) at /home/gosgood/git_repositories/blender/source/creator/creator.c:500
(gdb) up
#1  0x00007fffeaccb391 in __GI_abort () at abort.c:79
79	abort.c: No such file or directory.
(gdb) up
#2  0x00005555577ff18a in DEG_get_evaluated_scene (graph=0x7fff72f12c08) at /home/gosgood/git_repositories/blender/source/blender/depsgraph/intern/depsgraph_query.cc:151
151	  BLI_assert(scene_cow != NULL && DEG::deg_copy_on_write_is_expanded(&scene_cow->id));
(gdb) p scene_cow
$1 = (Scene *) 0x0
(gdb) set print pretty on
(gdb) p *deg_graph
$2 = {
  id_hash = 0x7fff643fe928, 
  id_nodes = std::vector of length 0, capacity 0, 
  time_source = 0x0, 
  need_update = true, 
  id_type_updated = '\000' <repeats 36 times>, 
  entry_tags = 0x7fff643fe8d8, 
  operations = std::vector of length 0, capacity 0, 
  lock = 1, 
  scene = 0x7fff80da4008, 
  view_layer = 0x7fff63ffb148, 
  mode = DAG_EVAL_VIEWPORT, 
  ctime = 0, 
  scene_cow = 0x0, 
  is_active = false, 
  debug_flags = 0, 
  debug_name = "SCScene :: View Layer", 
  debug_is_evaluating = false, 
  physics_relations = {0x0, 0x0, 0x0, 0x0}
}
(gdb)

Host environment:

system-info.txt

I have seen this bug here using OP's file (it has been renamed to buggytoy.blend). ``` (gdb) set args /media/render/gosgood/twoeight/human/buggytoy.blend (gdb) run Starting program: /home/gosgood/git_repositories/build_linux_debug/bin/blender /media/render/gosgood/twoeight/human/buggytoy.blend [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7fffd2fff700 (LWP 1034)]... (omitted for brevity...) ...[New Thread 0x7fff7e3ff700 (LWP 1151)] Thread 1 "blender" received signal SIGABRT, Aborted. __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 51 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt - 0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 - 1 0x00007fffeaccb391 in __GI_abort () at abort.c:79 - 2 0x00005555577ff18a in DEG_get_evaluated_scene (graph=0x7fff72f12c08) at /home/gosgood/git_repositories/blender/source/blender/depsgraph/intern/depsgraph_query.cc:151 - 3 0x0000555557afb780 in wm_event_do_handlers (C=0x7fffd3c58708) at /home/gosgood/git_repositories/blender/source/blender/windowmanager/intern/wm_event_system.c:3096 - 4 0x0000555557aef83d in WM_main (C=0x7fffd3c58708) at /home/gosgood/git_repositories/blender/source/blender/windowmanager/intern/wm.c:418 - 5 0x0000555557451c24 in main (argc=2, argv=0x7fffffffdb98) at /home/gosgood/git_repositories/blender/source/creator/creator.c:500 (gdb) up #1 0x00007fffeaccb391 in __GI_abort () at abort.c:79 79 abort.c: No such file or directory. (gdb) up #2 0x00005555577ff18a in DEG_get_evaluated_scene (graph=0x7fff72f12c08) at /home/gosgood/git_repositories/blender/source/blender/depsgraph/intern/depsgraph_query.cc:151 151 BLI_assert(scene_cow != NULL && DEG::deg_copy_on_write_is_expanded(&scene_cow->id)); (gdb) p scene_cow $1 = (Scene *) 0x0 (gdb) set print pretty on (gdb) p *deg_graph $2 = { id_hash = 0x7fff643fe928, id_nodes = std::vector of length 0, capacity 0, time_source = 0x0, need_update = true, id_type_updated = '\000' <repeats 36 times>, entry_tags = 0x7fff643fe8d8, operations = std::vector of length 0, capacity 0, lock = 1, scene = 0x7fff80da4008, view_layer = 0x7fff63ffb148, mode = DAG_EVAL_VIEWPORT, ctime = 0, scene_cow = 0x0, is_active = false, debug_flags = 0, debug_name = "SCScene :: View Layer", debug_is_evaluating = false, physics_relations = {0x0, 0x0, 0x0, 0x0} } (gdb) ``` Host environment: [system-info.txt](https://archive.blender.org/developer/F7007366/system-info.txt)

Garry R. Osgood commented

2019-05-05 19:03:09 +02:00

I believe this bug and #64175 have the same root cause.

Upon first opening 'Buggy Toy.blend', observe that there is a second open window, which happens to be showing the node editor displaying Material.002. This also sets the stage described in #64175.
If one closes that window, then follow the original poster's instructions on this bug, then no crash occurs.
Allowing the window to remain open in this bug, and following the original poster's instructions, causes the crash to occur as the original poster observed.
The backtrace in #64175 is identical to the backtrace attached to this bug. See remarks there.
@The_Doctor: Perhaps closing the other window, joining the two objects as you described, then pressing control - Z will succeed, with no crash, when there is only one open window. Please confirm and post here, and thank you in advance.

I believe this bug and #64175 have the same root cause. - Upon first opening 'Buggy Toy.blend', observe that there is a second open window, which happens to be showing the node editor displaying Material.002. This also sets the stage described in #64175. - If one closes that window, then follow the original poster's instructions on this bug, then no crash occurs. - Allowing the window to remain open in this bug, and following the original poster's instructions, causes the crash to occur as the original poster observed. - The backtrace in #64175 is identical to the backtrace attached to this bug. See remarks there. @The_Doctor: Perhaps closing the other window, joining the two objects as you described, then pressing control - Z will succeed, with no crash, when there is only one open window. Please confirm and post here, and thank you in advance.

Greshame Carr commented

2019-05-05 23:12:01 +02:00

Garry, I can confirm closing the second window resolves the issue. Don't know if it helps but I appended the buggytoy object to a new blend file, then open a second window showing the node editor. I could work on the buggytoy for about 10 minutes using ctr-z with no problem, and then suddenly the crash started occurring again.
cheers

Garry, I can confirm closing the second window resolves the issue. Don't know if it helps but I appended the buggytoy object to a new blend file, then open a second window showing the node editor. I could work on the buggytoy for about 10 minutes using ctr-z with no problem, and then suddenly the crash started occurring again. cheers

Greshame Carr commented

2019-05-06 08:20:20 +02:00

Dear Garry, this is the blend file that I created from scratch and then appended the buggytoy object from the previous blend file I sent you. With one window open I can not crash it. However, with a second window open showing the node editor, I ran it a number of times and it crashed following a random number of ctr-z undos. I ran it three times and it crashed after 37, 26, and 72 undos respectively.Buggy Toy Reproduced Bug.blend
logic would suggest that the first blend file I sent had, purely by chance, been saved at the point where a single ctr-z will crash it, so the blend file contains the primer for the crash and simply needs the subsequent trigger of one further ctr-z to set it off. This second blend file has not yet entered the state of being primed, and the number of ctr-z operations required to enter that state is random.

Dear Garry, this is the blend file that I created from scratch and then appended the buggytoy object from the previous blend file I sent you. With one window open I can not crash it. However, with a second window open showing the node editor, I ran it a number of times and it crashed following a random number of ctr-z undos. I ran it three times and it crashed after 37, 26, and 72 undos respectively.[Buggy Toy Reproduced Bug.blend](https://archive.blender.org/developer/F7009119/Buggy_Toy_Reproduced_Bug.blend) logic would suggest that the first blend file I sent had, purely by chance, been saved at the point where a single ctr-z will crash it, so the blend file contains the primer for the crash and simply needs the subsequent trigger of one further ctr-z to set it off. This second blend file has not yet entered the state of being primed, and the number of ctr-z operations required to enter that state is random.

Garry R. Osgood commented

2019-05-06 12:45:20 +02:00

Thank you, @greshame. If one needs to get to the heart of the matter by the most direct (i. e. simplest) and reliable route, then #64175 provides it. In essence:

open a window
perform some object mode edit

Cntl-Z in the original window

sends the baby out with the bath water. It seems that a number of edit/Cntl-Z cycles can be sustained in edit (i.e. mesh-manipulation) mode. That's interesting, supplemental information, but the key bit for the Blender core developer to triage this bug is a short, reliable path assured of kicking off the bug, leading to a good backtrace. I find it interesting that the depsgraph is not wholly populated and would like to follow that lead - but alas, I earn my pay on other projects and those sirens call. I think there is enough here for a core Blender developer to sort out in the fullness of time. Thank you for taking the time to report.

Thank you, @greshame. If one needs to get to the heart of the matter by the most direct (i. e. simplest) and reliable route, then #64175 provides it. In essence: - open a window - perform some object mode edit # Cntl-Z in the original window sends the baby out with the bath water. It seems that a number of edit/Cntl-Z cycles can be sustained in edit (i.e. mesh-manipulation) mode. That's interesting, supplemental information, but the key bit for the Blender core developer to triage this bug is a short, reliable path assured of kicking off the bug, leading to a good backtrace. I find it interesting that the depsgraph is not wholly populated and would like to follow that lead - but alas, I earn my pay on other projects and those sirens call. I think there is enough here for a core Blender developer to sort out in the fullness of time. Thank you for taking the time to report.

Brecht Van Lommel commented

2019-05-06 16:31:05 +02:00

Closed as duplicate of #64161

Brecht Van Lommel closed this issue

2019-05-06 16:31:05 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Ctr-Z causes instant crash #64163

Cntl-Z in the original window