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 DEBUG do_update TOP c->need_update 1 DEBUG sp_canvas_item_invoke_update TOP item 0xa362800 i->need_update 1 DEBUG sp_canvas_item_invoke_update TOP item 0xa10bbc8 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa10bbc8 i->need_update 0 DEBUG sp_canvas_item_invoke_update TOP item 0xa3628a8 i->need_update 1 DEBUG sp_canvas_item_invoke_update TOP item 0xa39d948 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa39d948 i->need_update 0 DEBUG sp_canvas_item_invoke_update TOP item 0xa39da30 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa39da30 i->need_update 0 DEBUG sp_canvas_item_invoke_update TOP item 0xa39db18 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa39db18 i->need_update 0 DEBUG sp_canvas_item_invoke_update TOP item 0xa3a2078 i->need_update 1 DEBUG requestRedraw window 0,-236 1,-235 need_update 1 need_redraw 1 DEBUG dirty because of clip DEBUG sp_canvas_dirty_rect SETTING c->need_redraw DEBUG sp_canvas_item_invoke_update BOT item 0xa3a2078 i->need_update 0 DEBUG sp_canvas_item_invoke_update TOP item 0xa362950 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa362950 i->need_update 0 DEBUG sp_canvas_item_invoke_update TOP item 0xa3629f8 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa3629f8 i->need_update 0 DEBUG sp_canvas_item_invoke_update TOP item 0xa362aa0 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa362aa0 i->need_update 0 DEBUG sp_canvas_item_invoke_update TOP item 0xa362b48 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa362b48 i->need_update 0 DEBUG sp_canvas_item_invoke_update TOP item 0xa362bf0 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa362bf0 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa3628a8 i->need_update 0 DEBUG sp_canvas_item_invoke_update BOT item 0xa362800 i->need_update 0 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_paint_rect TOP c->need_update 0 DEBUG sp_canvas_paint_rect_internal TOP DEBUG sp_canvas_paint_single_buffer TOP 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_dirty_rect SETTING c->need_redraw DEBUG sp_canvas_item_request_update TOP item 0xa3a2078 i->need_update 0 DEBUG before sp_canvas_item_request_update 3 item 0xa3628a8 DEBUG sp_canvas_item_request_update TOP item 0xa3628a8 i->need_update 0 DEBUG before sp_canvas_item_request_update 3 item 0xa362800 DEBUG sp_canvas_item_request_update TOP item 0xa362800 i->need_update 0 DEBUG before requestCanvasUpdate 0xa330040 DEBUG requestCanvasUpdate TOP SETTING c->need_update DEBUG sp_canvas_item_request_update BOT item 0xa362800 i->need_update 1 DEBUG sp_canvas_item_request_update BOT item 0xa3628a8 i->need_update 1 DEBUG sp_canvas_item_request_update BOT item 0xa3a2078 i->need_update 1 DEBUG SPClipPath::modified 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 #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.