| Summary: | LibreOffice crashes on startup after Java upgrade | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | seatrout |
| Component: | Installation | Assignee: | Not Assigned <libreoffice-bugs> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | critical | CC: | sberg.fun |
| Priority: | high | ||
| Version: | 3.5 Daily | ||
| Hardware: | x86 (IA32) | ||
| OS: | Windows (All) | ||
| Whiteboard: | |||
| Crash report or crash signature: | Regression By: | ||
upped importance to "high" since this will catch everyone running 3.5 on Windows who upgrades their Java *** This bug has been marked as a duplicate of bug 38913 *** |
Expected behaviour: detect and silently correct for an upgrade from Java 6.x to Java 7.x Actual Behaviour: fail to detect the change; crash without warning or explanation on all subsequent startups. A couple of days ago LO started crashing hard every time it was opened, in any module: the Windows event log showed Faulting application name: soffice.bin, version: 3.5.4.2, time stamp: 0x4fbc7fd1 Faulting module name: MSVCR90.dll, version: 9.0.30729.6161, time stamp: 0x4dace5b9 Exception code: 0xc0000417 Fault offset: 0x0002e9f4 Faulting process id: 0x1754 Faulting application start time: 0x01cd5a1a811603aa Faulting application path: C:\Program Files\LibreOffice 3.5\program\soffice.bin Faulting module path: C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.6161_none_50934f2ebcb7eb57\MSVCR90.dll Report Id: 656fdd56-c671-11e1-b9ee-001fd09f75e0 This happened every single time I tried to open it, wuth any file or in any module, running 32 bit Windows 7, home edition, completely patched. Poking around on Google revealed the cause. If Oracle Java on Windows has been updated to version 7 (as happens automatically), Libre Office 'loses' the installation. The file C:\Users\{username}\AppData\Roaming\LibreOffice\3\user\config\javasettings_Windows_x86.xml is not updated with the result that the program crashes hard and without explanation every single time you try to open it. The workaround is to rename the user directory, and start LO up again. At this point it reconstructs the user directory with a correct link to the new Java installation in javasettings...xml. That can then be copied over to the old user directory and then the whole lot recopied back, preserving the original settings. But it is grotesque to expect normal users to do this.