Issue 125140 - Bad Allocation error, and a problem with a saved file (so 2 bugs)
Summary: Bad Allocation error, and a problem with a saved file (so 2 bugs)
Status: CLOSED DUPLICATE of issue 125159
Alias: None
Product: Calc
Classification: Application
Component: save-export (show other issues)
Version: 4.1.0
Hardware: PC Windows 7
: P3 Major (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-22 21:09 UTC by cali season
Modified: 2017-09-27 20:05 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
a germ of 7 lines, to generate a file of 1000 lines (386.35 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-06-22 21:09 UTC, cali season
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description cali season 2014-06-22 21:09:33 UTC
Created attachment 83589 [details]
a germ of 7 lines, to generate a file of 1000 lines

With this file : the file works good when 100 lines, crashes 9 times out of 10 with more than 900 lines.

The crash is particularly obvious, when adding a bitmap in the library, to fill a comment with a bitmap.

The file, with about 1000 lines is 95 Mo large, so here a link to DL it 
http://uploaded.net/file/e0vvps90

otherwise, you copy the 7 lines of the attached file, until to get 1000 lines, and you try to add a line with this page, for instance,
http://www.scientificamerican.com/article/quasicrystal-meteorite-exposes-novel-processes-in-early-solar-system/

 adding as comment the picture of the page, so importing at first the picture to the bitmap library, to fill the comment with a bitmap and you get the "bad allocation" error, when you try to save the file.

The "Bad Allocation" don't compromize the import of the bitmap, so after a crash, it's possible to add a link, and a bitmap as comment, since the library was updated.
Then to save the file is possible (but crash from time to time yet)
Then adding another link, needing previously to import a picture in the bitmap library, and the crash goes on, since the import implies a  Bad Allocation .
Btw : if you work with a test file, filled with about 1000 lines, and try to suppress all the lines, except the 8 first ones, to get a test-ini, you will save a test-ini, being also 95 Mo !!!!
So, another bug, with openoffice 4.1.0
Comment 1 cali season 2014-06-22 21:11:47 UTC
the germ of the test-ini is with the lines 2 to 8.
Comment 2 Regina Henschel 2014-06-22 22:54:09 UTC
I cannot reproduce a crash with the attached file. Copying the lines does not increase the file size, because the pictures are not stored several times. The server, where your upload the file, delivers the file very slowly, so I have not downloaded it yet.

Please set the time "Remove from memory after" to minimum in Tools > Options > OpenOffice > Memory to force an early swap out, and increase the Graphics cache to maximum. Does that help?

Please try a daily build. There had been some picture related bug fixes since the last release.
Comment 3 cali season 2014-06-23 19:04:11 UTC
Tx a lot for your help.

1 - At the moment, I increased the cache for pictures (I work with french menus, I don't know how to retrieve english menus) from its value to 70 Mo.
I get a crash again, if importing a picture.
Otherwise, i increased also the cache , memory per objet from 5 Mo to 10 Mo.


2 - if you know a better server, to UL the big file, I can UL there.
I bleeded the bitmap library, before copying the 7 lines : you are right, the size is the same with 1000 lines.

I tried to import 7 others pictures, as bitmap, before copying, filling the comments with such bitmaps : impossible to reproduce a size of 95 Mo with the germ, at the moment.

So, if you have a good server, I can upload the test file, there, and you should see the "Bad Allocation" msg, adding a line with some bitmap as comment.


3 - what is a daily build ?
Comment 4 oooforum (fr) 2017-09-27 18:49:55 UTC
See other report

*** This issue has been marked as a duplicate of issue 125159 ***