Steps to reproduce: 1/ build the master with wiki-publisher extension enabled 2/ set the virtual memory to 3 Go : ulimit -S -v 3000000 2/ launch the master with --writer option ==> LO crashes immediately with JRE error message like this one: # # There is insufficient memory for the Java Runtime Environment to continue. # pthread_getattr_np # An error report file with more information is saved as: # [...]/hs_err_pid7719.log [error occurred during error reporting , id 0xb] The same limitation of the virtual memory on LO 4.1 does not lead to a crash. Best regards. JBF
Created attachment 88182 [details] JRE crash log
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f924cf3c2203be22631e6a3c631f712558fd8161 Related fdo#70919 Missing instdir redirect ini-file The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
That some process instantiated a JVM on every start of soffice from a master instdir installation was unrelated to wiki-publisher and Writer. It has been fixed as described in comment 2 now. Adapting this issue's summary accordingly and closing as FIXED. That a JVM fails if you artificially limit virtual memory size via ulimit -v is NOTABUG or at least NOTOURBUG.
(In reply to comment #3) > That some process instantiated a JVM on every start of soffice from a master > instdir installation was unrelated to wiki-publisher and Writer. It has > been fixed as described in comment 2 now. Adapting this issue's summary > accordingly and closing as FIXED. > > That a JVM fails if you artificially limit virtual memory size via ulimit -v > is NOTABUG or at least NOTOURBUG. Sure, but it seems that 3 Go should be enough to open an empty text document. If 3 Go of virtual memory is too small, I think it is the sign that something went wrong. Perhaps some option used to start the JVM. What made me incriminating Wiki Publisher extension is that if I remove it the JVM crash disappears. Best regards. JBF
(In reply to comment #4) > Sure, but it seems that 3 Go should be enough to open an empty text > document. If 3 Go of virtual memory is too small, I think it is the sign > that something went wrong. Perhaps some option used to start the JVM. I think that would be better suited as an issue against Java implementations, given that $ ulimit -S -v 3000000 $ java -version Error occurred during initialization of VM Could not reserve enough space for object heap Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. > What made me incriminating Wiki Publisher extension is that if I remove it > the JVM crash disappears. ...which is odd. I have no idea why presence of that extensions would trigger JVM instantiation for you on Linux. But a first step to find that out would be to run LO under strace (strace -f soffice >log 2>&1) to see from the generated log file which process it is that fails to instantiates the JVM to begin with.
Seems that toolbar creation load java implementation. I have this trace on 4.1.2, and will produce a new one with debug symbols : http://pastebin.com/fRwuTEz7
(In reply to comment #6) > Seems that toolbar creation load java implementation. I have this trace on > 4.1.2, and will produce a new one with debug symbols : "framework::AddonsToolBarManager::FillToolbar" -> you apparently have a Java extension installed that hooks into a toolbar
Before createJVM ?
(In reply to comment #8) > Before createJVM ? Not sure what you mean with that.