Bug 99643 - class EOleSysError on com.sun.star.ServiceManager
Summary: class EOleSysError on com.sun.star.ServiceManager
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
5.1.2.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.3.0 target:5.1.4 target:5.2.0.1
Keywords:
: 100661 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-05-03 07:45 UTC by giles
Modified: 2017-10-22 08:38 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Code example (7.04 KB, application/zip)
2016-05-31 09:49 UTC, giles
Details
Writer demo script (6.40 KB, text/plain)
2016-05-31 10:05 UTC, giles
Details
Windows vbscript demonstrating the problem (242 bytes, text/plain)
2016-05-31 10:59 UTC, Winfried Donkers
Details

Note You need to log in before you can comment on or make changes to this bug.
Description giles 2016-05-03 07:45:01 UTC
Since I have upgraded tot LO version 5.1.2.2 my delphi code is showing a "class EOleSysError" error on the line:

CreateOleObject('com.sun.star.ServiceManager');

The code has been functioning correctly up until this release.
Comment 1 Buovjaga 2016-05-06 14:04:15 UTC
Can you share the code?

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the code.
Comment 2 giles 2016-05-31 09:49:52 UTC
Created attachment 125411 [details]
Code example

Written in delphi 2009.
Comment 3 giles 2016-05-31 10:05:29 UTC
Created attachment 125412 [details]
Writer demo script

This script hails from the libreoffice website (http://api.libreoffice.org/examples/examples.html#OLE_examples)
This script fails with an identical error, while working flawlessly on Openoffice 3.3.0
Comment 4 Buovjaga 2016-05-31 10:12:51 UTC
Winfried: Michael Stahl noted on IRC that you reported a similar issue on the dev mailing list. Maybe you can confirm.
Comment 5 giles 2016-05-31 10:39:32 UTC
I have just tested the current LO v5.1.3.2 x86, which works correctly!
Yet the 64 bit version LO 5.1.3.2 x64 does not. It seems to be something to do with the 32/64 bit difference. Maby it's a compatability problem with an external DLL? (The OLE DLL)
Comment 6 Winfried Donkers 2016-05-31 10:59:04 UTC
Created attachment 125413 [details]
Windows vbscript demonstrating the problem

I confirm the problem.

The attached Windows vbscript does run without problem on Windows 7-32 and Windows7-64 with LO version 5.0.6 installed, but does produce and error when run on Windows7-64 with LO version 5.1.3.2 installed.

I don't have a machine with Windows7-32 and LO 5.1.3.2 to test.
Comment 7 Michael Stahl (CIB) 2016-05-31 11:13:31 UTC
Winfried, have you installed the 32-bit version of LO 5.1 or the 64-bit version?  If it's the 64-bit version, does it work for you if you install the 32-bit version of LO 5.1 instead?
Comment 8 Winfried Donkers 2016-05-31 11:18:30 UTC
(In reply to Michael Stahl from comment #7)
> Winfried, have you installed the 32-bit version of LO 5.1 or the 64-bit
> version?  If it's the 64-bit version, does it work for you if you install
> the 32-bit version of LO 5.1 instead?

Oops, I should have mentioned that. On the Windows-32 we use LO-32 and on the Windows-64 we use LO-64 bit (a script takes care of that).
I will install a 32-bit version of LO5.1 on a Windows-64 machine, test and report the result.
Comment 9 Winfried Donkers 2016-05-31 11:45:28 UTC
On a Windows-64 machine, with LO 5.1.3.2-32bit installed, the vbscript in attachment #125413 [details] works fine.
Comment 10 Michael Stahl (CIB) 2016-05-31 12:32:16 UTC
okay, so it looks like this never worked in 64-bit LO.

i've got no idea how this is supposed to work however...

there are a bunch of registry entries added that mention "com.sun.star.ServiceManager" here:

scp2/source/ooo/registryitem_ooo.scp

however there is no .dll listed in that file, only soffice.exe.

there is a "oleautobridge.uno.dll" built in extensions/, not
sure if that is involved here?

or does this use the "ActiveX" component, also built in extensions/ ?
there are 2 different builds of that, for 32-bit and 64-bit...
except if you build a 64-bit LO, then we ship only the 64-bit ActiveX dll...
Comment 11 Winfried Donkers 2016-05-31 13:18:52 UTC
To clarify my findings:

LO   \ Win  32   64
5.0-32      OK   OK
5.0-64      N/A  OK
5.1-32      ?    OK
5.1-64      N/A  FAIL

(I did not test LO 5.1 32 bit with Windows 32 bit.)

So the LO 64 bit version of 5.0 does work, it's 5.1 where the problem starts.
Comment 12 Michael Stahl (CIB) 2016-05-31 14:24:59 UTC
okay i think i figured out how this *should* work...

https://www.openoffice.org/udk/common/man/spec/ole_bridge.html

udkapi/com/sun/star/bridge/oleautomation/ApplicationRegistration.idl

desktop/source/app/app.cxx, Desktop::Main() calls Desktop::OpenClients_Impl(), creates the service "com.sun.star.bridge.OleApplicationRegistration"

this loads the "oleautobridgelo.dll" and creates a OleServer_Impl object.

OleServer_Impl::OleServer_Impl calls provideInstance(m_smgr, OID_ServiceManager)
and that OneInstanceOleWrapper_Impl::registerClass() and that calls
CoRegisterClassObject(OID_ServiceManager, ... CLSCTX_INPROC_SERVER | CLSCTX_LOCAL_SERVER)

OID_SerivceManager = {82154420-0FBF-11d4-8313-005004526AB4}

... not that anything there should differ between 32 and 64 bit.

there are at least 2 commits in extensions/source/ole that fix 64-bit pointer truncations to 32-bit but one of them is missing in 5.1 branch and both are missing in 5.0 branch so no idea how 5.0 ever worked...
Comment 13 Dorange-Pattoret Didier 2016-05-31 16:23:47 UTC
Hello,
The following code : 

Sub TestServiceManager
Set objServiceManager = CreateObject("com.sun.star.ServiceManager")
Set objCoreReflection= objServiceManager.createInstance("com.sun.star.reflection.CoreReflection")
Set objDesktop= objServiceManager.createInstance("com.sun.star.frame.Desktop")
Dim args()
Set objDocument= objDesktop.loadComponentFromURL("private:factory/swriter", "_blank", 0, args)
End Sub 

runs with LO Win 5.1.1.3 64 bits but not with LO Win 5.1.3.2 64 bits.
It seems the bug comes between this versions.
All is ok with LO Win 32 bits.
Comment 14 Commit Notification 2016-05-31 22:16:36 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

tdf#99643 OLE automation bridge: fix 64-bit pointer conversions

It will be available in 5.3.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 15 Michael Stahl (CIB) 2016-05-31 22:16:57 UTC
it breaks when retrieving the UNO service manager via
OneInstanceOleWrapper_Impl::CreateInstance()

okay so technically this commit "broke" it

commit 120586bb305f7bd763753a3f5a8d60e25ad3db8f
Author:     David Ostrovsky <david@ostrovsky.org>
AuthorDate: Sat Feb 20 16:47:26 2016 +0100
Commit:     Michael Stahl <mstahl@redhat.com>
CommitDate: Mon Feb 29 13:05:33 2016 +0100

    Ole: Fix WaE
    
specifically this change:

@@ -488,7 +488,7 @@ Any SAL_CALL InterfaceOleWrapper_Impl::createBridge(const Any& modelDepObject,
                     pVar->pdispVal= static_cast<IDispatch*>( this);
                     AddRef();
 
-                    retAny<<= reinterpret_cast< sal_uInt32 >( pVar);
+                    retAny<<= reinterpret_cast< sal_uIntPtr >( pVar);
                 }
             }
         }

because the caller of that function stupidly hard-codes an expected return type of TypeClass_UNSIGNED_LONG, which is sal_uInt32, but on a 64-bit platform sal_uIntPtr of course corresponds to TypeClass_UNSIGNED_HYPER.

of course the pVar is not at all guaranteed to have its thrown-away upper bits all 0 in a 64-bit build, so if this worked in 5.0 it is purely by luck.

fixed on master, by adapting the caller to expect hyper instead, plus fixing up several other callers and implementations of createBridge().

actually i checked again and *both* of the 64-bit pointer fixes mentioned in comment #12 are already in 5.1, so nothing more to backport.
Comment 16 Winfried Donkers 2016-06-01 06:25:38 UTC
(In reply to Michael Stahl from comment #15)
> fixed on master, by adapting the caller to expect hyper instead, plus fixing
> up several other callers and implementations of createBridge().
> 
> actually i checked again and *both* of the 64-bit pointer fixes mentioned in
> comment #12 are already in 5.1, so nothing more to backport.

Thanks for picking this up and for explaining the cause. 
Shouldn't the fix be backported to 5.2 and 5.1?
As I understand it, createBridge may produce an error with all 64-bit versions from 5.1.2 up to 5.3.0.
Comment 17 Commit Notification 2016-06-01 07:33:57 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=31f45d4c1709645ac42ff0ff7d068f681f37f675&h=libreoffice-5-1

tdf#99643 OLE automation bridge: fix 64-bit pointer conversions

It will be available in 5.1.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 18 Commit Notification 2016-06-07 07:24:31 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=46960352458bde1ec9e1f2307a674de9fc3bb08d&h=libreoffice-5-2

tdf#99643 OLE automation bridge: fix 64-bit pointer conversions

It will be available in 5.2.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 19 Michael Stahl (CIB) 2016-09-13 15:40:28 UTC
*** Bug 100661 has been marked as a duplicate of this bug. ***
Comment 20 giles 2017-03-14 13:31:24 UTC
When testing with Libreoffice LibreOffice_5.3.0_Win_x64 the problem unfortunately is still present.
Comment 21 Xisco Faulí 2017-07-13 09:57:22 UTC
Setting Assignee back to default. Please assign it back to yourself if you're still working on this issue
Comment 22 Xisco Faulí 2017-09-24 19:45:52 UTC
Dear gobber,
This bug has been in RESOLVED FIXED status for more than 6 months.
If the issue is still reproducible with the latest version of LibreOffice from
https://www.libreoffice.org/download/libreoffice-fresh/, please report a new
issue in https://bugs.documentfoundation.org/enter_bug.cgi providing, if
needed, the steps and documents to reproduce it.
Thanks for your understanding and collaboration.
Closing as RESOLVED FIXED