Created attachment 116012 [details] Test document with cropped images Writer crashes when pasting several cropped images as GDI MetaFile in Writer (bad allocation). To reproduce the error open the attached file and select all graphics. Create a new writer document. Press Ctrl + Shift + V and select "GDI MetaFile". Sometimes I combine text and graphics and pasting as GDI MetaFile is the only effective method because text and graphics can be resized. Pasting as bitmap results in a low resolution picture.
I use Windows 8.1 x64 and 6 GB of RAM.
Created attachment 116018 [details] backtrace WinDbg
Hi, Bugs generally need to be reproduced by QA before being set to NEW - setting back to UNCONFIRMED so we know it still needs triage (Not reproduced on Linux, LO 4.4.2.2 / 5.1 master)
Selected all with ctrl-a. Pasted as GDI metafile to Writer. No crash. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: be8512f99bc9ab18e55aabe01cc0ab1e6baea9e6 TinderBox: Win-x86@39, Branch:master, Time: 2015-06-08_05:58:40 Locale: fi-FI (fi_FI)
I started with a new profile: no crash. LO crashes on my computer when the extension "language tool" is activated.
Bug reproduced after installing LanguageTool (version 2.9.1) with LibreOffice version 4.4.3 and Win7. No new user profile needed.
(In reply to Harald Koester from comment #6) > Bug reproduced after installing LanguageTool (version 2.9.1) with > LibreOffice version 4.4.3 and Win7. No new user profile needed. Setting to NEW
Took a look and found a reason. In ImplWriteDIBBody the contained graphics get written to the metafile as DIBs. The 1st one is 4210x6180 pixels in 24 bit, so the written graphic size is 78065760 bytes. Same for the others, so 234197837 bytes are used. This explains why it is not always reproducable. It is sometimes too much mem for 32bit versions. It *should* always work on 64bit LO versions. It will sometimes work on 32bit versions, too, more probable when selecting only one of the graphics. 32bit version means mainly windows, but also small still used amounts of 32bit linux versions. AFAIK there is no more 32bit Mac version, so should not happen there. I saved some of the original graphics (PNGs) selecting them and using 'save image...' from the context menu (that saves the orig graphics). Also extracted from the original bugdoc, the images are the same. This ensures that they did not get blown up at load time from the office. As a workaround I would suggest to use bitmap graphic tooling to reduce image size, in this case 24bit is not needed. I would guess that it is scanned from some paper, it should be scanned as 1bit image. Fixing for 32bit versions is hard - I have no direct clue. Reducing mem usage somehow, suggesting reduction at load time, ...?
Discussed internally. Please use 64bit win version which is available. Also possible is to reduce graphic size at scan or using tools (1bit would be better here). Also possible to copy the bitmaps one-by-one. It cannot really be fixed - maybe mem usage can be reduced internally (probably at the cost of runtime), but there will again the point be reached (e.g. adding more scenned graphics) where this will happen again. Bug status: there seems to be no flag like '32bit only'?
(In reply to Armin Le Grand from comment #9) > Bug status: there seems to be no flag like '32bit only'? Well, there is the hardware field, but its use is somewhat anarchic. You can always invent a new whiteboard to make it explicit: needs32bit
@Beluga: How do I 'invent a new whiteboard' ...?
(In reply to Armin Le Grand from comment #11) > @Beluga: How do I 'invent a new whiteboard' ...? Well, I already did it for you :D I can even add it and we will see, if it will catch on. I just meant that the Whiteboard field accepts any words (different words must be separated with spaces unlike Keywords). Keywords, however, are pre-defined and you cannot invent them on a whim.
@Beluga: Ah, thanks!