Clones - behaves strange after modifiying its OriginalMaster

[Anonymous]

I am observing some strange behavior. In the attached file there is one group in the layer "Master", which have been cloned several times. If I am now trying to modify the master (=original) according the following steps, I get strange results.
a) selecting the bitmap (png) and copying to clipboard with "ctrl-c"
a) Selecting the original (its a group), and entering the group by right click.
c) pasting the clip board content into the original group

My expectation: it should update all clones according my changes to the original group.

I have different observations:
yesterday I got a small icon within some clones with "Path to image not found", some clones where updated correctly.....
today, I tried to reproduce this error, I only get the confused screen as attached in the zip.

I am also watching the processes on my Windows 7 professional / 64 bit PC, and Inkscape is consuming some how close to 1.5 Gigabytes of RAM. My Hardware is equipped with 8 GB in total.
InkScape version is Inkscape 0.48+devel r13487

Attachments: the original SVG file named "maybe_a_bug.svg" and some screen dumps.

I could not judge if this is a InkScape problem or related to my Graphic card or anything else, but I like to report it. Maybe it is also related to the copied object, which is a one bit (b/w only) PNG with can be found in the archive too with name "potError.png".
I am also notifying, that InkScape seems to be very slow in response time for this file.

If I am entering the original group and exchange colors or other modifications, everything went well....

[su_v (suv-lp)]

Attaching "reduced" test case (108 clones of a group with a rect and the unscaled (linked) bitmap image). Place the SVG file into folder of the unpacked rar archive (the bitmap image is referenced by relative path as "potError.png").

On my system (OS X 10.7.5, 8GB RAM), trunk (r13537) doesn't manage to even open the file in meaningful time (I assume the buffer size it reserves for rendering the 108 clones of a bitmap image of the size 2887x3036 is way over 3GB: 108 * (2887 * 3036)*4 ).

Oddly though, it makes no difference whether the clones are visible or hidden (on separate layer) or the document is viewed in outline view mode.

[su_v (suv-lp)]

(note for bug triage: not a regression in trunk - the reduced testcase requires even huger amounts of memory on load with current stable too - I killed the process (like with trunk) before it brought the whole system close to a standstill)