The problem is apparently that the clip (in the pattern) is marking some object(s) as modified, and the object(s) is(are) marking the clip as modified, in each cycle, when nothing has changed one iota. Result, infinite loop. By dropping in DEBUG lines in the likely places in sp-canvas.cpp (no prefix) and sp-clippath.cpp (entries with SPClipPath::) this much of the loop has been mapped out (c-> is canvas->, i-> is item->):
I tried and failed to step through the entire loop, by setting a breakpoint at a known line in the loop and then sourcing a file with 100K "step" lines in it. But doing that changed something, because in the loop above the line:
DEBUG dirty i 0 j -15
started showing other values and it never got back to the original breakpoint to stop.
If the viewbox line is commented out the test file opens, does not go into an infinite loop.
Instead it does a bunch of (reasonable) stuff, gets down to:
Here is a bt from that line from a gdb run with minimal_bad.svg and a breakpoint on SPClipPath::update
#0 SPClipPath::update (this=0xba11c40, ctx=0xbffff230, flags=1) at sp-clippath.cpp:135
#1 0x08231e48 in SPObject::updateDisplay (this=0xba11c40, ctx=0xbffff230, flags=1) at sp-object.cpp:1142
#2 0x081c9398 in SPDefs::update (this=0xb9f8788, ctx=0xbffff230, flags=0) at sp-defs.cpp:55
#3 0x08231e48 in SPObject::updateDisplay (this=0xb9f8788, ctx=0xbffff230, flags=2) at sp-object.cpp:1142
#4 0x08201bb9 in SPGroup::update (this=0xa05ce00, ctx=0xbffff230, flags=2) at sp-item-group.cpp:188
#5 0x0824315c in SPRoot::update (this=0xa05ce00, ctx=0xbffff308, flags=2) at sp-root.cpp:297
#6 0x08231e48 in SPObject::updateDisplay (this=0xa05ce00, ctx=0xbffff308, flags=2) at sp-object.cpp:1142
#7 0x080d96ed in SPDocument::_updateDocument (this=0x9237f50) at document.cpp:1062
#8 0x080d982e in sp_document_idle_handler (data=0x9237f50) at document.cpp:1130
#9 0x0131c810 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#10 0x0131ed46 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0
#11 0x0131f0e5 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0
#12 0x0131f52b in g_main_loop_run () from /lib/i386-linux-gnu/libglib-2.0.so.0
#13 0x00671b8f in gtk_main () from /usr/lib/i386-linux-gnu/libgtk-x11-2.0.so.0
#14 0x00302194 in Gtk::Main::run_impl() () from /usr/lib/i386-linux-gnu/libgtkmm-2.4.so.1
#15 0x00302bcf in Gtk::Main::run() () from /usr/lib/i386-linux-gnu/libgtkmm-2.4.so.1
#16 0x08087888 in sp_main_gui (argc=1, argv=0xbffff6e4) at main.cpp:1097
#17 0x08086ef0 in main (argc=1, argv=0xbffff6e4) at main.cpp:812
Somebody who has previously worked in these code sections may want to have a look. I don't know where else to look for these changes, and the standard trick I typically use to delimit an infinite loop through a heap of code did not work in this case.
The problem is apparently that the clip (in the pattern) is marking some object(s) as modified, and the object(s) is(are) marking the clip as modified, in each cycle, when nothing has changed one iota. Result, infinite loop. By dropping in DEBUG lines in the likely places in sp-canvas.cpp (no prefix) and sp-clippath.cpp (entries with SPClipPath::) this much of the loop has been mapped out (c-> is canvas->, i-> is item->):
DEBUG idle_handler TOP item_invoke_ update TOP item 0xa362800 i->need_update 1 item_invoke_ update TOP item 0xa10bbc8 i->need_update 0 item_invoke_ update BOT item 0xa10bbc8 i->need_update 0 item_invoke_ update TOP item 0xa3628a8 i->need_update 1 item_invoke_ update TOP item 0xa39d948 i->need_update 0 item_invoke_ update BOT item 0xa39d948 i->need_update 0 item_invoke_ update TOP item 0xa39da30 i->need_update 0 item_invoke_ update BOT item 0xa39da30 i->need_update 0 item_invoke_ update TOP item 0xa39db18 i->need_update 0 item_invoke_ update BOT item 0xa39db18 i->need_update 0 item_invoke_ update TOP item 0xa3a2078 i->need_update 1 dirty_rect SETTING c->need_redraw item_invoke_ update BOT item 0xa3a2078 i->need_update 0 item_invoke_ update TOP item 0xa362950 i->need_update 0 item_invoke_ update BOT item 0xa362950 i->need_update 0 item_invoke_ update TOP item 0xa3629f8 i->need_update 0 item_invoke_ update BOT item 0xa3629f8 i->need_update 0 item_invoke_ update TOP item 0xa362aa0 i->need_update 0 item_invoke_ update BOT item 0xa362aa0 i->need_update 0 item_invoke_ update TOP item 0xa362b48 i->need_update 0 item_invoke_ update BOT item 0xa362b48 i->need_update 0 item_invoke_ update TOP item 0xa362bf0 i->need_update 0 item_invoke_ update BOT item 0xa362bf0 i->need_update 0 item_invoke_ update BOT item 0xa3628a8 i->need_update 0 item_invoke_ update BOT item 0xa362800 i->need_update 0 paint_rect TOP c->need_update 0 paint_rect_ internal TOP paint_single_ buffer TOP dirty_rect SETTING c->need_redraw item_request_ update TOP item 0xa3a2078 i->need_update 0 item_request_ update 3 item 0xa3628a8 item_request_ update TOP item 0xa3628a8 i->need_update 0 item_request_ update 3 item 0xa362800 item_request_ update TOP item 0xa362800 i->need_update 0 item_request_ update BOT item 0xa362800 i->need_update 1 item_request_ update BOT item 0xa3628a8 i->need_update 1 item_request_ update BOT item 0xa3a2078 i->need_update 1 :modified
DEBUG do_update TOP c->need_update 1
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG requestRedraw window 0,-236 1,-235 need_update 1 need_redraw 1
DEBUG dirty because of clip
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG do_update MID UNSETTING c->need_update
DEBUG paint TOP c->need_update 0 c->need_redraw 1
DEBUG dirty i 0 j -15
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG SPClipPath::show
DEBUG SPClipPath::hide
DEBUG UNSETTING c->need_redraw
DEBUG paint BOT c->need_update 0 c->need_redraw 0
DEBUG SPClipPath::update
DEBUG requestRedraw window 0,-236 1,-235 need_update 0 need_redraw 0
DEBUG dirty because of clip
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG before sp_canvas_
DEBUG sp_canvas_
DEBUG before sp_canvas_
DEBUG sp_canvas_
DEBUG before requestCanvasUpdate 0xa330040
DEBUG requestCanvasUpdate TOP SETTING c->need_update
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG sp_canvas_
DEBUG SPClipPath:
DEBUG idle_handler TOP
I tried and failed to step through the entire loop, by setting a breakpoint at a known line in the loop and then sourcing a file with 100K "step" lines in it. But doing that changed something, because in the loop above the line:
DEBUG dirty i 0 j -15
started showing other values and it never got back to the original breakpoint to stop.
If the viewbox line is commented out the test file opens, does not go into an infinite loop.
Instead it does a bunch of (reasonable) stuff, gets down to:
DEBUG UNSETTING c->need_redraw
DEBUG paint BOT c->need_update 0 c->need_redraw 0
and does NOT follow that with a
DEBUG SPClipPath::update
Here is a bt from that line from a gdb run with minimal_bad.svg and a breakpoint on SPClipPath::update
#0 SPClipPath::update (this=0xba11c40, ctx=0xbffff230, flags=1) at sp-clippath.cpp:135 :updateDisplay (this=0xba11c40, ctx=0xbffff230, flags=1) at sp-object.cpp:1142 :updateDisplay (this=0xb9f8788, ctx=0xbffff230, flags=2) at sp-object.cpp:1142 group.cpp: 188 :updateDisplay (this=0xa05ce00, ctx=0xbffff308, flags=2) at sp-object.cpp:1142 :_updateDocumen t (this=0x9237f50) at document.cpp:1062 idle_handler (data=0x9237f50) at document.cpp:1130 linux-gnu/ libglib- 2.0.so. 0 context_ dispatch () from /lib/i386- linux-gnu/ libglib- 2.0.so. 0 linux-gnu/ libglib- 2.0.so. 0 linux-gnu/ libglib- 2.0.so. 0 i386-linux- gnu/libgtk- x11-2.0. so.0 :run_impl( ) () from /usr/lib/ i386-linux- gnu/libgtkmm- 2.4.so. 1 i386-linux- gnu/libgtkmm- 2.4.so. 1
#1 0x08231e48 in SPObject:
#2 0x081c9398 in SPDefs::update (this=0xb9f8788, ctx=0xbffff230, flags=0) at sp-defs.cpp:55
#3 0x08231e48 in SPObject:
#4 0x08201bb9 in SPGroup::update (this=0xa05ce00, ctx=0xbffff230, flags=2) at sp-item-
#5 0x0824315c in SPRoot::update (this=0xa05ce00, ctx=0xbffff308, flags=2) at sp-root.cpp:297
#6 0x08231e48 in SPObject:
#7 0x080d96ed in SPDocument:
#8 0x080d982e in sp_document_
#9 0x0131c810 in ?? () from /lib/i386-
#10 0x0131ed46 in g_main_
#11 0x0131f0e5 in ?? () from /lib/i386-
#12 0x0131f52b in g_main_loop_run () from /lib/i386-
#13 0x00671b8f in gtk_main () from /usr/lib/
#14 0x00302194 in Gtk::Main:
#15 0x00302bcf in Gtk::Main::run() () from /usr/lib/
#16 0x08087888 in sp_main_gui (argc=1, argv=0xbffff6e4) at main.cpp:1097
#17 0x08086ef0 in main (argc=1, argv=0xbffff6e4) at main.cpp:812
Somebody who has previously worked in these code sections may want to have a look. I don't know where else to look for these changes, and the standard trick I typically use to delimit an infinite loop through a heap of code did not work in this case.