Summary: | "Bad allocation" on Windows 7 x64 when working with master document | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Darius Daniel Grigoras <daniel.grigoras> |
Component: | Presentation | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEEDINFO --- | QA Contact: | |
Severity: | major | ||
Priority: | high | CC: | jbfaure, jmadero.dev, qubit, serval2412, todventtu |
Version: | 4.3 Daily | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Windows (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Darius Daniel Grigoras
2014-09-14 14:09:16 UTC
Not sure if the bug is in LibreOffice ;-) What amount of RAM do you have under W7 ? Did you play with graphic cache parameter : menu Tools > Options > LibreOffice > Memory ? Set status to NEEDINFO. Please set it back to UNCONFIRMED once you have provided requested informations. Thank you for your understanding. Best regards. JBF Another thing to have in mind, LO is build on 32 bits only on Windows so even if you're on Win7 64 bits, you might have some limitations. What's the physical size of your whole doc (master and subdocuments)? Now there are still memory leaks fixed on LibreOffice. For the test, you may give a try to daily master sources, see http://dev-builds.libreoffice.org/daily/master/Win-x86@51-TDF/current/ My system is equipped with a Core i7-4770, 256GB SSD, 8GB of RAM and runs Windows 7 x64. The total size of the subdocuments is 114 MB, and growing. I have set the memory setting for LibreOffice to the maximum allowed and I still receive "Bad allocation" in just a few seconds after inserting the subdocuments into the master document. As mentioned before, this is not an issue on Ubuntu. I can only work on Ubuntu because of this. Following your last comment I put it back to UNCONFIRMED. (In reply to Julien Nabet from comment #4) > Following your last comment I put it back to UNCONFIRMED. Why would you do that? This is a real issue. I remember creating a sample master doc a while ago, which you can download from here: https://www.dropbox.com/s/vz43d9x0v1t3fxr/master_for_support.zip?dl=0 (In reply to Darius Daniel Grigoras from comment #5) > (In reply to Julien Nabet from comment #4) > > Following your last comment I put it back to UNCONFIRMED. > > Why would you do that? This is a real issue. Perhaps but you can't confirm your onw bug reports. Each bug report must be confirmed independently. Best regards. JBF Also not a blocker - blockers are reserved for truly cases where the vast majority of users would be affected, as we as of now have a single unconfirmed case....not meeting this criteria. Setting to Major - High. What are the exact steps to reproduce? Just download the document and watch a memory leak? Opens fine here on a system about half as powerful as the reporter's. Win 7 64-bit Version: 4.4.0.0.alpha2+ Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827 TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08 (In reply to Joel Madero from comment #8) > What are the exact steps to reproduce? Just download the document and watch > a memory leak? Darius: 1) Can you still reproduce the problem with 4.4.x and/or 4.5.x builds? 2) As Joel asked, could you be a bit clearer about what steps are required to reproduce the problem? Status -> NEEDINFO (Please change status back to UNCONFIRMED after you test with 4.4.x and/or 4.5.x, and provided simple steps for reproduction. Thanks!) Darius: for the test, could you rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile#Windows) and give it a new try? |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.