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.

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...

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?

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.

(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?

(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."

(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).

(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

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

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.

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.

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.

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.

Hello,
Is this bug fixed?
If so, could you please close it as RESOLVED FIXED?

it looks like cloph fixed it