Certain Pdf uses exteme amount of memory and time on import and rendering

[RayJW]

Describe the bug
Memory leak while trying to load PDF embedded into Rnote document.

To Reproduce
Steps to reproduce the behavior:

1. Importing the PDF already takes multiple minutes on my relatively performant laptop.
2. Once it is loaded, viewing the PDF works fine but uses a lot of memory until reaching the third page, Rnote now takes over 10 Gb's of memory and reliably gets killed because it's taking down my other processes.

Expected behavior
This obviously shouldn't happen, and I think it's fair to talk about a memory leak, although this is a Rust application I suspect the PDF library might not be. This PDF is only 3 pages, 2 Mb and works fine in all other PDF applications (Firefox, Evince, and Okular in my case).

Console Output

2024-03-30T19:17:47.148322Z DEBUG rnote: .. tracing subscriber initialized.
2024-03-30T19:18:23.031656Z ERROR rnote_engine::store::render_comp: Generating stroke images failed stroke while regenerating rendering in viewport `Aabb { mins: [-123.06843938144867, 720.3065966056062], maxs: [917.8854437199712, 1943.2992129587522] }`, stroke key: StrokeKey(3v1), Err: read stream to rsvg loader failed.

Caused by:
    cannot load more than 1000000 XML elements

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: __clone
2024-03-30T19:19:06.073044Z ERROR rnote_engine::store::render_comp: Generating stroke images failed stroke while regenerating rendering in viewport `Aabb { mins: [-94.61117261757015, 1369.3988513674444], maxs: [888.9508093859195, 2309.5973792545474] }`, stroke key: StrokeKey(3v1), Err: read stream to rsvg loader failed.

Caused by:
    cannot load more than 1000000 XML elements

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: __clone
2024-03-30T19:19:09.358355Z ERROR rnote_engine::store::render_comp: Generating stroke images failed stroke while regenerating rendering in viewport `Aabb { mins: [-106.23008855306122, 2129.054488715916], maxs: [900.742625856165, 3184.715993711962] }`, stroke key: StrokeKey(3v1), Err: read stream to rsvg loader failed.

Caused by:
    cannot load more than 1000000 XML elements

Stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: <unknown>
   8: <unknown>
   9: __clone
[1]    207130 terminated  flatpak --env=RUST_LOG=rnote=debug --env=RUST_BACKTRACE=1 run

Desktop (please complete the following information):

• OS: Fedora 39
• App Version: Rnote v0.10.1
• Installation Source: Flatpak
• Desktop Environment: Gnome 45.5
• Display Server: Wayland
• Input Source: Touchscreen

Additional context
I tried repairing the PDF with Ghostscript to make sure it's not corrupted or anything and while that did reduce file size, Rnote still has the same behaviour. Also, since other applications work fine, I doubt it's necessarily only a problem with the PDF.

Sadly, I cannot share the PDF publicly on GitHub since it contains some personal information of other people, but I can share it privately with a developer. However, I know that the PDF has been generated with Notability on an iPad. I will see, so I can possibly get another export from that person for diagnosis.

[flxzt]

Reads like the Pdf contains an excessive amount of Xml elements, which librsvg can't handle.

It's not necessarily a memory-leak, maybe a recursion in the internally converted Svg.

By the way: Rust does not have any guarantees to prevent leaks, for example: Box::leak

[RayJW]

Reads like the Pdf contains an excessive amount of Xml elements, which librsvg can't handle.

Certainly seems like it.

It's not necessarily a memory-leak, maybe a recursion in the internally converted Svg.

I was wondering as well if it might be some recursive issue or something else. Because it's just handwritten text and all other PDF applications don't really seem to slow down or increase memory usage when loading page three. So it doesn't seem like an "it's simply too much data" kinda situation.

By the way: Rust does not have any guarantees to prevent leaks, for example: Box::leak

You are of course totally right, there are many ways to leak memory without necessarily creating memory safety issues.