Bug 92483 - JRE defective message unless user installs Visual C++ 2010 runtimes
Summary: JRE defective message unless user installs Visual C++ 2010 runtimes
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
5.0.0.0.alpha0+ Master
Hardware: Other Windows (All)
: high major
Assignee: Christian Lohmaier
URL: https://gerrit.libreoffice.org/#/c/16...
Whiteboard: target:5.1.0 target:5.0.1 target:5.0.0
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-01 19:02 UTC by Christian Lohmaier
Modified: 2017-09-29 11:16 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Lohmaier 2015-07-01 19:02:32 UTC
On fresh installations, like on Windows 10 preview, the user is likely to be confronted with a "JRE defective" message, despite having installed matching JRE - the cause is explained in 

bug#50584#c2

And as a workaround the user can go to Microsoft's website and install the Visual C++ 2010 runtimes.

x86: https://www.microsoft.com/en-us/download/details.aspx?id=8328
x64: https://www.microsoft.com/en-us/download/details.aspx?id=13523

6e9b9e61ee2e1aab7abfa6a6cf01c269b3f02cb8 makes it sound like it is impossible to ship both VS2013 as well as 2010 runtimes as part of LO
But I think that referred to the 32bit and 64bit versions at the same time - which aren't needed in the 64bit-windows-version case.

(32bit Windows version would have had to install 64bit version of the runtime for the shell extension to work)
Comment 1 sawakaze 2015-07-03 11:09:21 UTC
Hi

I reproduce on Windows 10 x64,
and after install Visual Studio 2010 C++ runtime manually, I confirm that the bug is "not" caused.

Testing version :Version: 5.1.0.0.alpha1+ (x64)
Build ID: 3a6ec53eeeec71312f5ea890689f9c2ee79c2aac
TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2015-07-01_02:24:40

Testing Case: Open "Tool > Marcos >Run Macro... on Writter."

Regards.
Sawakaze.
Comment 2 Michael Stahl (CIB) 2015-07-09 13:14:41 UTC
assuming that this bug only affects 64 bit builds?

there is some code to load the MSVCR100.dll in
jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx

perhaps that needs some adapting for 64bit?
it's all rather ugly...
Comment 3 DavidO 2015-07-09 15:58:00 UTC
I don't understand how to reproduce this failure. What I did so far is:

1. Windows 7
2. Install 64 bit JDK
3. Build x64 LO on VS2013 with debug-enabled
4. Start LO from instdir/program/soffice
5. Verify that Base with Hsqldb works as expected

Apparently I had VS2010 installed on this VM?
Comment 4 Christian Lohmaier 2015-07-09 19:27:35 UTC
you don't need to have VS 2010 installed to avoid that problem, but maybe had installed another program that bundles the VS2010 runtimes for systemwide installation.

so best to look whether you have msvcr100.dll lying around (except in java installation dir)/loaded by other software already) and get rid of it.
Comment 5 DavidO 2015-07-10 04:42:45 UTC
(In reply to Michael Stahl from comment #2)
> assuming that this bug only affects 64 bit builds?
> 
> there is some code to load the MSVCR100.dll in
> jvmfwk/plugins/sunmajor/pluginlib/sunjavaplugin.cxx
> 
> perhaps that needs some adapting for 64bit?

Indeed:

    {
        static struct { char const * name; wchar_t const * wname; } msvcrts[] =
        {
            { "msvcr71.dll" , L"msvcr71.dll"  },
            { "msvcr100.dll", L"msvcr100.dll" },
        };
        char const* importName = (char *) dos_hdr + imports->Name + VAtoPhys;
        for (size_t i = 0; i < SAL_N_ELEMENTS(msvcrts); ++i)
        {
            if (0 == strnicmp(importName,
                // Intentional strlen() + 1 here to include terminating zero
                        msvcrts[i].name, strlen(msvcrts[i].name) + 1))
            {
                load_msvcr(reinterpret_cast<LPCWSTR>(Module->buffer),
                        msvcrts[i].wname);
                free(dos_hdr);
                return;
            }
        }
        imports++;
    }

So why is "msvcr71.dll" there as well? And why are we hard code the
names and not induce them from _MSC_VER?

@Stephan?
Comment 6 Stephan Bergmann 2015-07-10 07:48:34 UTC
(In reply to DavidO from comment #5)
> @Stephan?

Don't know much about that WNT-specific load_msvcr(); Tor once added it with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=debf1d0568118f52a23e6c2b2e50c11bd46ed70e> "Load msvcr71.dll needed by JVM using explicit path, see fdo#32426."
Comment 7 Michael Stahl (CIB) 2015-07-10 09:38:21 UTC
(In reply to DavidO from comment #5)
> So why is "msvcr71.dll" there as well? And why are we hard code the
> names and not induce them from _MSC_VER?

it is irrelevant what MSVC was used to build LO, what matters is what
MSVC was used to build the Oracle JRE.

(except that in the corner case of LO and JRE being
built with the same MSVC version, as was the case with LO <= 4.0
and Oracle JRE 7 it works "by accident")

the msvcr71.dll was apparently used by Oracle JRE 6,
while msvcr100.dll is used by Oracle JRE 7 (and 8, presumably
but not sure about that).
Comment 8 DavidO 2015-07-10 09:52:48 UTC
(In reply to Stephan Bergmann from comment #6)
> (In reply to DavidO from comment #5)
> > @Stephan?
> 
> Don't know much about that WNT-specific load_msvcr(); Tor once added it with
> <http://cgit.freedesktop.org/libreoffice/core/commit/
> ?id=debf1d0568118f52a23e6c2b2e50c11bd46ed70e> "Load msvcr71.dll needed by
> JVM using explicit path, see fdo#32426."

This commit looks also intresting:

http://lists.freedesktop.org/archives/libreoffice-commits/2014-May/071660.html
Comment 9 DavidO 2015-07-10 11:04:23 UTC
As pointed out in :[1], JRE installation actually provides the needed dll.
It's only place in $JAVA_HOME/bin and thus is not found by the LO process. There are also number of workarounds provided in this article. Currently, i Don't understand as for how/why this problem doesn't show up on 32bit build. Who tested it, that vanilla LO 32bit installation works on vanilla Windows 10 with only two packages installed: LO 32bit + JRE 32bit?

https://www.duckware.com/tech/java6msvcr71.html
Comment 10 Christian Lohmaier 2015-07-11 00:11:47 UTC
submitted https://gerrit.libreoffice.org/#/c/16938/ for review.

ptrdiff_t on win64bit is __int64 - as the difference of the smaller types (sections->PointerToRawData - sections->VirtualAddress) is negative, the result is an overflow (or whatever the correct term is).

And with that of course it won't read the proper libs from the jvm.dll.
Comment 11 Commit Notification 2015-07-11 14:54:24 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b4d27a3badddd2648c3f02cd234ca74c5a40e6b

tdf#92483 fix initializing JRE on Win 64bit (load java's msvcr100.dll)

It will be available in 5.1.0.

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 12 Commit Notification 2015-07-11 17:54:38 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=14bc2d237813b208a176cacece3a27a32145d3b4&h=libreoffice-5-0

tdf#92483 fix initializing JRE on Win 64bit (load java's msvcr100.dll)

It will be available in 5.0.1.

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 13 Commit Notification 2015-07-13 10:45:03 UTC
Christian Lohmaier committed a patch related to this issue.
It has been pushed to "libreoffice-5-0-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=444e9e16524af54d67f6131bba96f2faaa66b078&h=libreoffice-5-0-0

tdf#92483 fix initializing JRE on Win 64bit (load java's msvcr100.dll)

It will be available in 5.0.0.

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 14 Xisco Faulí 2016-09-15 22:10:45 UTC
Hello,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?
Comment 15 Xisco Faulí 2017-09-29 08:53:57 UTC Comment hidden (obsolete)
Comment 16 Michael Stahl (CIB) 2017-09-29 11:16:36 UTC
it looks like cloph fixed it