GNOME Bugzilla – Bug 540477
When exporting via Pixbuf* exports, dia consumes large amounts of memory
Last modified: 2009-01-25 20:54:59 UTC
Please describe the problem: When trying to export a UML diagram with dia-0.95.1 or 0.96.1 (I've tried both versions), the application almost consumes the entire memory (i.e. 2GiB ram and another 2GiB swap) within 2-3 seconds. After that the system slows down so strongly, that I have to 'killall dia'. As far as I could test it, all "Pixbuf*" exports suffer from this problem. Steps to reproduce: 1. Start dia 2. Open file (to be attached) 3. Export it via "Pixbuf*" export Actual results: dia consumes lots of the system's memory Expected results: Correct export, much less memory consumption. Does this happen every time? Yes. Other information: This bug was reported at Gentoo first. Gentoo devs asked me to take this bug upstream. Original Gentoo bug report: https://bugs.gentoo.org/show_bug.cgi?id=174656
Created attachment 113526 [details] Dia file to be exported which this bug can be reproduced with
Somehow you are (or a bug in dia) produced object with a very huge bounding box. The exporters are just exporting the whole diagram. One gets a visual clue on that by looking at the placement of the scrollbars. Part of the problem is covered by: 2008-05-10 Hans Breuer <hans@breuer.org> * lib/diagramdata.c(layer_update_extents) : don't consider empty objects for the overall extents. Fixes bug #531687 and lowers priority of bug #99375. But even after deleting the empty text boxes there are huge objects remaining, namely "UML- Message". You can find them by "Show all" and "inverse selecting" in the apparently (but not really) empty space. Moving the handles into the intended range fixes the diagram. I currently have no idea how to properly avoid this without restricting perfectly valid use cases.
Hm, I see what you mean. Selecting all and zooming out shows them. Deleting them (actually they do belong to the arrows pointing away from the actor) fixes the export. So apparently, this does explain the small size of the export. But I do not understand why it should be ok that Pixbuf exports consume so much memory (4 GiB!) while for the same file with the same extents other exports (like the "normal" png export) consume much less. Am I missing something?
when exporting with "PNG (anti-aliased)" I get asked if I want to save a file with size 10000x10000 which limits the size, i.e. there *is* an arbitrary limit when exporting via normal PNG. The resulting file is as un-useable as the one produced by the other (bitmap) exporters. Only a very small part actually contains content.
Hm, ok, so the size of the resulting images in the Pixbuf exports is not really limited and thus likely causes a huge image to be generated consuming so much memory. I think, it is not reproducible for me anymore how those empty text boxes got that far "out of bounds", so how do we proceed?
As already mentioned I don't have a good idea how to "fix" this issue. Maybe some intelligence could be added for diagrams with handles far out of the field of interest, but it could be difficult to differentiate between user intention and glitches. So at the moment we could leave this report open to make it warning for other people or to get some better ideas. Or close it as wontfix.
Something more simple (like GIMP does for huge "New Image") : 2009-01-24 Hans Breuer <hans@breuer.org> * app/confirm.[ch] : new function confirm_export_size() which let's the user confirm an unusal diagram size * app/Makefile.am app/makefile.msc po/POTFILES.in : add new files * app/commands.c app/filedlg.c : use it before export and print to avoid possibly unintended numbers of pages printed or memory used for export. (Bug #540477, Martin Wegner) app/preferences.[ch] : removed obsolete print preference