Atte Kettunen's fuzz testing produced an SVG that had this:

    <pattern
       patternTransform="matrix(1.5682937,1.5682937,-1.7214781,1.721478,589.69469,-269.03292)"
       id="pattern6236-31"
       xlink:href="#pattern6204-52"
       inkscape:collect="always" />
    <pattern
       patternTransform="matrix(1.5682937,1.5682937,-1.7214781,1.721478,589.69469,-269.03293)"
       id="pattern6204-52"
       xlink:href="#pattern6188-5-69"
       inkscape:collect="always" />
    <pattern
       inkscape:stockid="Stripes 1:1"
       id="Strips1_1-39-44"
       patternTransform="matrix(2.2179022,0,0,2.4345375,229.96544,-129.83887)"
       height="1"
       width="2"
       patternUnits="userSpaceOnUse"
       inkscape:collect="always">
      <rect
         id="pattern6204-52"
         height="1"
         width="1"
         y="-0.5"
         x="0"
         style="fill:black;stroke:none" />
    </pattern>

Note two things:

1. The first pattern has an xlink:href fallback to the second pattern.

2. The *third* pattern contains a rect, whose id is the same as the *second* pattern's.

This causes librsvg's resolver to link the pattern->fallback to a rect node, which should not be possible.  The functions that fix pattern fallbacks think they are getting a pointer to an RsvgPattern, but in reality they are getting a pointer to an RsvgNodeRect.

In addition, the resolver should complain about duplicated node IDs, but it doesn't.

I'll fix the first problem by modifying rsvg_defs_add_resolver() to take in an expected_type as well, so that rsvg_defs_resolve_all() can avoid creating links to unexpected data.

I'll see what to do about the second problem; maybe just refuse to load the SVG.