Bug 112928 - LibreOffice 5.4.2.2 installs but will not run on Windows XP SP3 (32-bit)
Summary: LibreOffice 5.4.2.2 installs but will not run on Windows XP SP3 (32-bit)
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.4.2.1 rc
Hardware: x86 (IA32) Windows (All)
: high major
Assignee: Mike Kaganski
URL:
Whiteboard: target:5.4.3
Keywords: haveBacktrace, notBibisectable, regression
: 113222 113341 113476 (view as bug list)
Depends on:
Blocks: Splash-Screen
  Show dependency treegraph
 
Reported: 2017-10-06 09:15 UTC by Mark B
Modified: 2017-10-27 09:04 UTC (History)
15 users (show)

See Also:
Crash report or crash signature:


Attachments
XPsp3 x86 WinDbg StackTrace of crash (16.25 KB, text/plain)
2017-10-20 23:46 UTC, V Stuart Foote
Details
WinXPsp3 WinDbg stack trace with TDF symbols for 5.4.3.1 build (40.44 KB, text/plain)
2017-10-22 07:09 UTC, V Stuart Foote
Details
WinDbg stack trace using "ProcDump -w soffice.bin" for a 5.4.3.1 launch (15.41 KB, text/plain)
2017-10-22 07:55 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mark B 2017-10-06 09:15:16 UTC
I had a fully working installation of LO 5.4.1.2 on my XP system. I saw there was a new version which I downloaded and installed after uninstalling my existing version using Revo Uninstaller.
On trying to start LO the banner/logo appeared briefly and then disappeared. Nothing happened after that. I tried uninstalling and reinstalling to no avail. Then I read the release notes and saw that the Visual C++ runtime (2015) was a requirement. I didn't have it so I downloaded that and installed it successfully. Still LO 5.4.2.2 would not run. I tried reverting to 5.4.1.2 and that wouldn't run either until I uninstalled the VC++ runtime. Now I am back to where I started with a working installation.
Can you suggest how I can get 5.4.2.2 working? If you need any more diagnostic information I would be happy tp provide it.

Thanks for your time.
Comment 1 Xisco Faulí 2017-10-06 09:19:29 UTC
Microsoft Visual C++ 2015 Redistributable comes with the LibreOffice installer for Win XP as described here: https://wiki.documentfoundation.org/ReleaseNotes/5.4#Windows
Could you please try unistalling LibreOffice, unistalling Visual C++ runtime and then installing LibreOffice again?
Comment 2 Mike Kaganski 2017-10-06 09:44:05 UTC
What is the Revo Uninstaller, and why is it required to uninstall LibreOffice that has its own supported means of uninstallation? (As aside, it's *not* required to uninstall previous LibreOffice versions prior to installing new. Doing so will require you to select required components again, while installing over existing installation allows to automatically upgrade already installed components.)
Comment 3 Mark B 2017-10-06 13:33:11 UTC
Xisco,

I did as you asked and it's no better. I checked in Control Panel and the Visual C++ 2015 runtime is NOT there. Does the installer grab it from the internet because I have internet access disabled for security reasons?

Mike,

Revo is a free program that usually does a better job of uninstalling than most built-in uninstallers. You are right to say it's not needed but I have used it for years without issue. You are also right when you say about not needing to remove the old version. However, it IS necessary to do that with Linux so I usually do it that way as a matter of course.

I hope that helps.
Comment 4 Julien Nabet 2017-10-06 14:59:59 UTC
I don't think it help much since it seems to stop very early in the process but you can rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile#Windows) and give it a new try.
Comment 5 Mark B 2017-10-06 15:16:52 UTC
I should add that I had the same problem on my laptop which also runs XP. That already had the Visual C++ 2015 runtime and that did not work either. 
I downloaded a new copy, tested the checksum and tried again several times. It still didn't run after briefly flashing the banner. Task manager had no LO app running. I removed 5.4.2.2 and reinstalled 5.4.1.2 which works again. 

I had none of these issues with the Win10 64-bit version or the x86 version for Linux Mint: both run just fine. Having spent most of today trying to resolve this I've had enough and will resume tomorrow.
Comment 6 Mike Kaganski 2017-10-06 16:15:49 UTC
Reproduced on my XP VitrualBox VM.
Comment 7 nomax@arcadebelgium.be 2017-10-10 09:02:39 UTC
Encountering the same problem, also with Windows XP SP3 32-bit.
Comment 8 Philippe Rossignol 2017-10-11 10:57:19 UTC
Same problem. Version 5.4.2.2 deployed with WPKG tool on 10 XP stations and LO cannot start. Back manually with 5.4.1.2. Please test before publishing a new version !!!.
Comment 9 Julien Nabet 2017-10-11 12:12:30 UTC
(In reply to Philippe Rossignol from comment #8)
> Same problem. Version 5.4.2.2 deployed with WPKG tool on 10 XP stations and
> LO cannot start. Back manually with 5.4.1.2. Please test before publishing a
> new version !!!.

There are less and less people (dev and qa) using XP so even if it's still supported by TDF (I must recognize I would have dropped support since XP has been released in 2002), it's longer to fix the problems on it.

BTW, you can also deploy on 1 machine to test before deploying on 10 stations.
Comment 10 Philippe Rossignol 2017-10-11 12:32:49 UTC
(In reply to Julien Nabet from comment #9)
> (In reply to Philippe Rossignol from comment #8)
> > Same problem. Version 5.4.2.2 deployed with WPKG tool on 10 XP stations and
> > LO cannot start. Back manually with 5.4.1.2. Please test before publishing a
> > new version !!!.
> 
> There are less and less people (dev and qa) using XP so even if it's still
> supported by TDF (I must recognize I would have dropped support since XP has
> been released in 2002), it's longer to fix the problems on it.
> 
> BTW, you can also deploy on 1 machine to test before deploying on 10
> stations.

I fully agree about doing some preliminary tests before deploying ... but it's the first time that this type of problem occurs. 
Just one question : will the bug be fixed or do we keep 5.4.1.2 as the last LO version under XP SP3 ?.  
BTW, I know that XP iy very old and no more supported ... but in an industrial environment some embedded PCs are XP driven and cannot be replaced.
Comment 11 Julien Nabet 2017-10-11 12:58:39 UTC
(In reply to Philippe Rossignol from comment #10)
> ...
> I fully agree about doing some preliminary tests before deploying ... but
> it's the first time that this type of problem occurs. 
> Just one question : will the bug be fixed or do we keep 5.4.1.2 as the last
> LO version under XP SP3 ?.  
> BTW, I know that XP iy very old and no more supported ... but in an
> industrial environment some embedded PCs are XP driven and cannot be
> replaced.

I can't tell but perhaps Mike Kaganski (following comment 6) will find a fix.
About industrial environment, I understand, sometimes editors won't release any new version and Citrix or similar solutions may be not so easy to use (and have also a cost).
The cost to migrate may be too high so it can be difficult "to sell" the migration to the client but still:
- Microsoft doesn't support anymore XP
- there are certainly security flaws which won't be fixed
- I'm not sure antivirus are still efficient for XP
At last, you must know that for every LO major version, supported OS are debated.
So it's possible WinXP won't be supported by LO in a not so far future.
Comment 12 Mark B 2017-10-11 13:28:56 UTC
That's right. The release notes say that 5.4 will be the last version of LibreOffice supported on XP. Even so, I am very grateful it is supported at the moment. Many other people have stopped producing supported applications for XP. I can see their point but I think XP has been the 'nicest' version of Windows so far.
Comment 13 Julien Nabet 2017-10-18 16:54:10 UTC
*** Bug 113222 has been marked as a duplicate of this bug. ***
Comment 14 Julien Nabet 2017-10-18 16:57:52 UTC
Andras: as Windows installer expert, thought you might be interested in this one.

Since it's a regression and it prevents from any LO use, let's increase importance.
Comment 15 Alex 2017-10-19 06:00:46 UTC
We have near 120 machines running under WinXP. It's very sad if LO will no longer work on this version of windows.

There is same problem as topicstarter.
After installing LO 5.3.6.1 (I haven't 5.4.1.2 version distributive) at first start program shown a warning that last start of LO was unsuccessful. I hope the bug will be fixed in next version.
Comment 16 Kostas Kyriakidis 2017-10-19 15:52:53 UTC
Act1) Update LO to 5.4.2.2 from 5.4.2.1 for Win x86 (XP SP3) doesn't run.
Act2) Uninstall and re-install 5.4.2.1 also doesn't run, while was running.
Act3) Uninstall 5.4.2.1 and install 5.3.6 run.
Act4) Uninstall 5.3.6 and install 5.4.1.2 run.

Now I use 5.4.1.2.
Comment 17 Régis 2017-10-20 11:15:39 UTC
Same problem with LibreOffice 5.4.2.2.

A minor problem with LibreOffice 5.4.1.2.
(if the last Windows XP users of this discussion can confirm it see Bug 113120)

Back to LibreOffice 5.3.6.1 for me.
Comment 18 Jeff 2017-10-20 21:38:25 UTC
Same problem with LibreOffice 5.4.2.2

and I wonder if it has to do with how we installed windows updates. I've had to reinstall Windows XP Pro so I used a DVD I bought on ebay for $8 to apply all the windows updates it could offline. Could that be part of the problem?
Comment 19 Aron Budea 2017-10-20 22:43:10 UTC
(In reply to Jeff from comment #18)
> and I wonder if it has to do with how we installed windows updates. I've had

No, others have the same issue with 5.4.2 as well.
Comment 20 V Stuart Foote 2017-10-20 23:46:09 UTC
Created attachment 137174 [details]
XPsp3 x86 WinDbg StackTrace of crash

Attempted to get a SAL_LOG with a CygWin command terminal launch of TDF 5.4.2.2 x86 build.

$ SAL_LOG=1 ./soffice.exe vsf_TestDocument.odt 2> tdf112928_debug.txt

But the launch attempt crashes with .DMP file to into the LO program directory, SAL_LOG file was empty.

Attaching a WinDbg (sdk7.1) stack trace with symbols and analyze -v
Comment 21 tommy27 2017-10-21 15:34:03 UTC
It would be interesting to know if a portable LibO 5.4.2 release such the one released by winPenPack.it does run or not under WinXP.

here's the download page:
https://sourceforge.net/projects/winpenpack/files/X-LibreOffice/releases/

it could be an interesting test to do to understand if the issue is during the installation process or affects the program itself.
Comment 22 Yousuf Philips (jay) 2017-10-21 20:17:25 UTC
Was just about to report this same issue. ;D

LibreOffice 5.3.6.1 ran fine in my VM, but 5.4.2.2 wont go past showing the splash screen for a few seconds and then crashing. I assume there would be no benefit in attaching my user profile.

(In reply to tommy27 from comment #21)
> It would be interesting to know if a portable LibO 5.4.2 release such the
> one released by winPenPack.it does run or not under WinXP.

Tested it and it crashes as well.

> it could be an interesting test to do to understand if the issue is during
> the installation process or affects the program itself.

Definitely affecting the program itself as when i extract it, the same result happens, and when it didnt work i decided to install it and still it didnt work.
Comment 23 V Stuart Foote 2017-10-22 05:41:23 UTC
*** Bug 113341 has been marked as a duplicate of this bug. ***
Comment 24 V Stuart Foote 2017-10-22 07:09:08 UTC
Created attachment 137198 [details]
WinXPsp3 WinDbg stack trace with TDF symbols for 5.4.3.1 build

Attaching a WinDbg stack trace and analysis of miniDump of crash on launch of 5.4.3.1 rc1 on WinXpsp3 with more complete TDF symbols.

On a different Windows 10 host OS with another WinXPsp3 VM. Had pulled a full .reload of TDF symbols prior to uninstall of 5.4.0.3, they look fairly complete for this run against 5.4.3.1 build.
Comment 25 V Stuart Foote 2017-10-22 07:55:07 UTC
Created attachment 137199 [details]
WinDbg stack trace using "ProcDump -w soffice.bin" for a 5.4.3.1 launch

A trace with bit different approach, rather than just using the Breakpad miniDump, used "ProcDump -w soffice.bin" to wait and get a better look at the issue.

This looks more helpful.
Comment 26 Julien Nabet 2017-10-22 08:28:33 UTC
Stephan/Mike: last V Stuart Foote's bt indicates the pb is:
00e3f78c 002d9eed kernel32!CreateFileW+0x35f
00e3f7c0 013844c4 sal3!osl_openFile(struct _rtl_uString * strPath = 0x02e2b4b0, void ** pHandle = 0x02e8c914, unsigned long uFlags = 1)+0x7d [c:\cygwin64\home\buildslave\source\libo-core\sal\osl\w32\file.cxx @ 737]
thought you might be interested in this bugtracker.

Here's the line:
720      HANDLE hFile = CreateFileW(
721          o3tl::toW(rtl_uString_getStr(strSysPath)),
722          dwAccess, dwShare, nullptr, dwCreation, 0, nullptr);
See https://opengrok.libreoffice.org/xref/core/sal/osl/w32/file.cxx#720

I tried to unwind this:
"rtl_uString_getStr" returns "sal_Unicode *" 
see https://opengrok.libreoffice.org/xref/core/include/rtl/ustring.h#1414

then "sal_Unicode" is "wchar_t" for SAL_W32
138  #elif defined(SAL_W32)
139      typedef wchar_t sal_Unicode;
see https://opengrok.libreoffice.org/xref/core/include/sal/types.h#137

o3tl::toW takes for input char16_t * and returns wchar_t *
https://opengrok.libreoffice.org/xref/core/include/o3tl/char16_t2wchar_t.hxx#15

It seems we call o3tl::toW with an arg which is already wchar_t, could the implicit conversion to char16_t be the culprit?
Comment 27 Mike Kaganski 2017-10-22 13:16:47 UTC
(In reply to Julien Nabet from comment #26)

While you are probably correct in where the problem is seen (my debug from last night indicates the failure of file operation inside dp_manager::PackageManagerImpl::create when it tries to access absent items in %userprofile%\LibreOffice\4\user\extensions\shared), there's no o3tl::toW in the failing code. What you see in code at your links is for master, while failing is code for 5.4, which is here:

https://gerrit.libreoffice.org/gitweb?p=core.git;a=blob;f=sal/osl/w32/file.cxx;h=d7ef5623cd4ea17cb52fb4b73e96cf57f65c334d;hb=refs/heads/libreoffice-5-4#l737

Second: the code in LibreOffice uses  LIBO_INTERNAL_ONLY && __cplusplus path in types.h, so sal_Unicode *is* char_16t for us. If it weren't, the code wouldn't compile.

I'll continue debugging this.
Comment 28 Mike Kaganski 2017-10-22 13:43:08 UTC
(actually, my suspicion is on osl_getSystemPathFromFileURL_ and https://cgit.freedesktop.org/libreoffice/core/commit/?id=6abbad3c44809d9f8116992475c5efcaafc23dbf&h=libreoffice-5-4)
Comment 29 Julien Nabet 2017-10-22 17:02:32 UTC
(In reply to Mike Kaganski from comment #28)
> (actually, my suspicion is on osl_getSystemPathFromFileURL_ and
> https://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=6abbad3c44809d9f8116992475c5efcaafc23dbf&h=libreoffice-5-4)

Thank you for your feedback.
Feel free to revert this commit if you think it's wrong but it's curious how something in sc part could impact LO in the whole.
Comment 30 Mike Kaganski 2017-10-22 17:03:47 UTC
(In reply to Julien Nabet from comment #29)

No need to do that; my suspicion was clearly wrong :)
Comment 31 Mike Kaganski 2017-10-23 08:02:55 UTC
Well, the CreateFileW seems to be innocent. It fails as before, and further, the fileaccess::throw_handler is called from fileaccess::TaskManager::endTask. That's expected, and worked before, reaching exception handler down the call stack.

The problem is that now it fails to initialize required data *before* the exception is thrown. An access violation system (not c++) exception (=SIGSEGV) in s_stub_computeObjectIdentifier *after* cppu_cppenv_getStaticOIdPart() - which seems to return uninitialized string (aRet.makeStringAndClear seems to be optimized away???). No idea what made this change of behaviour.

Stephan, could you please take a look at this?
Comment 32 Adolfo Jayme 2017-10-23 19:39:42 UTC
https://gerrit.libreoffice.org/43721/
Comment 33 V Stuart Foote 2017-10-24 05:05:15 UTC
Testing cloph's gerrit 43721 TB62 build 5.4.4.0.0+ on one of the same WinXPsp3, LODev comes up fine and all modules seem functional.

=-ref-=

http://dev-builds.libreoffice.org/daily/libreoffice-5-4/Win-x86@62-TDF/gerrit_43721/

Windows 10 Pro with VMWare workstation 12.5.7 host
Windows XPsp3 x86, version 5.1 (buld 2600.xpsp_sp3_qfe.130503-00418) vm with
Version: 5.4.4.0.0+
Build ID: 5ecedd1648c49741448a0e10b7f5b20a80668421
CPU threads: 2; OS: Windows 5.1; UI render: default; 
Locale: en-US (en_US); Calc: group
Comment 34 Commit Notification 2017-10-24 07:57:36 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c6ce662b444d713e45a2c326a81fc45685adbfb&h=libreoffice-5-4

tdf#112928: don't use "magic statics" for 5.4 (fails on WinXP)

It will be available in 5.4.4.

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.
Comment 35 Mike Kaganski 2017-10-24 08:04:41 UTC
Backport request for 5-4-3: https://gerrit.libreoffice.org/43739
Comment 36 Commit Notification 2017-10-24 11:11:33 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "libreoffice-5-4-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d8522a7e0f98fb17ee0f1233b074bd8ba4089fde&h=libreoffice-5-4-3

tdf#112928: don't use "magic statics" for 5.4 (fails on WinXP)

It will be available in 5.4.3.

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.
Comment 37 Adolfo Jayme 2017-10-24 11:16:57 UTC
Done; 5.4.3 RC2 should have the fix. Thanks for the patch, Mike!
Comment 38 Xisco Faulí 2017-10-27 09:04:59 UTC
*** Bug 113476 has been marked as a duplicate of this bug. ***