Bug 94265 - bootstrap exception when running C# application with LibreOffice API
Summary: bootstrap exception when running C# application with LibreOffice API
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: sdk (show other bugs)
Version:
(earliest affected)
5.0.1.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:5.4.0 target:5.2.7 target:5.3.3
Keywords: bibisectRequest, regression
: 94460 (view as bug list)
Depends on:
Blocks:
 
Reported: 2015-09-16 10:11 UTC by Stefano Fraccaro
Modified: 2017-08-21 09:15 UTC (History)
9 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 Stefano Fraccaro 2015-09-16 10:11:51 UTC

    
Comment 1 Stefano Fraccaro 2015-09-16 10:16:10 UTC
I have the exception:

System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.
   at cppu.bootstrap(Reference<com::sun::star::uno::XComponentContext>* )
   at uno.util.Bootstrap.bootstrap()

With LibO 4.x 32bit the code was running fine. Now I'm using Windows 64 bit with LibreOffice 5.0.1.2 x64 bit and the code throw this exception. Code is compiled for framework 4.5.1 64 bit.
I tried to set the UNO_PATH environment path but the problem still persist.
How can I do?

Regards
Comment 2 Ivan 2015-09-17 07:51:50 UTC
I can confirm the same exception at uno.util.Bootstrap.bootstrap from VB.NET application.
Used to work fine on LibreOffice 4.x.
This same error occurs when running LibreOffice_5.0.1_Win_x86 as well as LibreOffice_5.0.1_Win_x64.
Tried to set the UNO_PATH environment as well as copying the missing URE folder from LibreOffice 4.x but it still fails.

Any workaround suggestions until fixed?
Comment 3 Buovjaga 2015-09-20 13:03:07 UTC
NEW per comment 2.
Comment 4 APS 2016-01-13 14:54:05 UTC
*** Bug 94460 has been marked as a duplicate of this bug. ***
Comment 5 APS 2016-01-13 14:57:56 UTC
I can confirm that the bug is still present on version Fresh 5.0.4.2 Fresh

I've found a workaround adding C:\Program Files (x86)\LibreOffice 5\program to PATH environment variable or by setting it via code in this way

Environment.SetEnvironmentVariable("PATH", Environment.GetEnvironmentVariable("PATH") + @";" + unoPath, EnvironmentVariableTarget.Process);


Ref: http://stackoverflow.com/questions/31856025/bootstrap-uno-api-libreoffice-exception

P.S.: UNO_PATH environment variable seems useless.

Just to add some detail the problem can be easily reproduced creating a new VB.NET or C# project, referencing cli_uno libraries and issuing the following command

uno.util.Bootstrap.bootstrap();
Comment 6 Buovjaga 2016-01-13 15:01:49 UTC
Please don't change version to newer. Thanks.
Comment 7 Stephan Bergmann 2016-06-24 09:07:41 UTC
Is this still a problem with recent 64-bit LO 5.1 or 5.2 beta/release-candidate builds?
Comment 8 christer.bergstrom.se 2016-07-26 09:31:57 UTC
Hi,
I first reported this bug back in 2012. Please see Bug #46832. Worked for a while after it had been fixed then. However, have been unable to run later versions so instead I've been using OpenOffice. 
Today, I installed "LibreOffice_5.1.4_Win_x86.msi" on a my new 64bit Windows 10 and I still get the same exception...
Regards,
Christer
Comment 9 Buovjaga 2016-07-26 09:43:36 UTC
Throwing back to NEW.
Comment 10 christer.bergstrom.se 2016-07-26 14:36:49 UTC
Update:
Added C:\Program Files (x86)\LibreOffice 5\program to PATH. Then it works! 
Actually, I used to do this in code at the beginning (with OpenOffice) but then I remarked it since it seemed like I didn't need it anymore. Well, now it seems like I do...
Comment 11 Xisco Faulí 2016-09-13 10:30:54 UTC
Since we have a bibisect repository for windows covering the branch where this regression was introduced, adding keyword 'bibisectRequest'.
More info: https://wiki.documentfoundation.org/QA/Bibisect/Windows
Comment 12 José Hernández Moya 2017-03-02 16:57:40 UTC
Hi!

I am using windows 10 64-bit and developing a C # .Net Framework 4.5 application, which has run on x64, so, you have installed LibreOffice 5.2.3 x64 with your respective sdk.

I managed to replicate this error using the environment variable "UNO_PATH" and confirm that it still does not see fixes, but, I think the correct thing is to use the environment variable "PATH" (this is used in x86 and it works). However, when adding the environment variable as follows:

string variableEntornoPATH = Environment.GetEnvironmentVariable("PATH");
Environment.SetEnvironmentVariable("PATH", variableEntornoPATH + ";C:\\Program Files\\LibreOffice 5\\program;");


It shows me the following error:

The arithmetic operation has caused an overflow.
It is Mapping_uno2cli (_uno_Mapping * mapping, Void ** ppOut, Void * pIn, _typelib_InterfaceTypeDescription * td)
At com.sun.star.uno.Mapping.mapInterface (Mapping *, Void ** ppOut, Void * pInterface, Type * rType)
In one.util.to_cli <class with :: sun :: star :: one :: XComponentContext> (Reference <com :: sun :: star :: one :: XComponentContext> * x)
In one.util.Bootstrap.bootstrap()


The problem is that there is no information about it and the only thing I found was the method code here:

Https://github.com/LibreOffice/core/blob/master/cli_ure/source/uno_bridge/cli_bridge.cxx#L96

From what I can see in the code, it seems to me that there are problems with the pre-compilation flags. 

ptr= sri::GCHandle::ToIntPtr(sri::GCHandle::Alloc(cliI))
#ifdef _WIN32
                    .ToInt32();
#else /* defined(_WIN64) */                 .ToInt64();
#endif



Anyone have any solutions?
Comment 13 C++ Guru 2017-03-12 16:24:15 UTC
Thanks José! Thats it, you have found the bug!

The solution is trivial: It is C++ Code and _WIN32 is always defined, even in Win64.

ptr= sri::GCHandle::ToIntPtr(sri::GCHandle::Alloc(cliI))
#ifdef _WIN64
                 .ToInt64();
                 
#else /* defined(_WIN32) */
                 .ToInt32();
#endif


Thats it!


In my eyes this Bug is critical: Because no one can use the SDK in 64 bit!
Comment 14 Xisco Faulí 2017-03-12 16:27:11 UTC
(In reply to C++ Guru from comment #13)
> Thanks José! Thats it, you have found the bug!
> 
> The solution is trivial: It is C++ Code and _WIN32 is always defined, even
> in Win64.
> 
> ptr= sri::GCHandle::ToIntPtr(sri::GCHandle::Alloc(cliI))
> #ifdef _WIN64
>                  .ToInt64();
>                  
> #else /* defined(_WIN32) */
>                  .ToInt32();
> #endif
> 
> 
> Thats it!
> 
> 
> In my eyes this Bug is critical: Because no one can use the SDK in 64 bit!

Hi, it's great you found the solution.
Could you please submit a patch with the fix to gerrit ?
 https://wiki.documentfoundation.org/Development/gerrit/
Comment 15 Xisco Faulí 2017-03-12 16:28:26 UTC
Correct link: https://wiki.documentfoundation.org/Development/gerrit
Comment 16 C++ Guru 2017-03-12 16:45:14 UTC
Sorry, don't know how to do with gerrit.

I have made a pull request:
https://github.com/LibreOffice/core/pull/15
Comment 17 Buovjaga 2017-03-12 16:47:33 UTC
(In reply to C++ Guru from comment #16)
> Sorry, don't know how to do with gerrit.
> 
> I have made a pull request:
> https://github.com/LibreOffice/core/pull/15

The pull request will not be accepted. GitHub is used as a read-only mirror.
If you need help with gerrit, you can visit #libreoffice-dev https://wiki.documentfoundation.org/Website/IRC
Comment 18 Commit Notification 2017-03-22 10:23:02 UTC
ComputingDwarf committed a patch related to this issue.
It has been pushed to "master":

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

tdf#94265: Correct the error

It will be available in 5.4.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 19 Stephan Bergmann 2017-03-22 10:28:31 UTC
(In reply to C++ Guru from comment #16)
> Sorry, don't know how to do with gerrit.
> 
> I have made a pull request:
> https://github.com/LibreOffice/core/pull/15

So, as an exception, I pushed that directly now, see comment 18, as I didn't find any corresponding Gerrit change at <https://gerrit.libreoffice.org/> but wouldn't want to lose this fix.

@C++ Guru:  Even if this is a small patch, please nevertheless send a license statement mail as explained at <https://wiki.documentfoundation.org/Development/Developers#License_Statements>.  And thanks for the fix!

(Setting as tentatively FIXED.  Please somebody check it and set to VERIFIED accordingly.)
Comment 20 Aleksander Kasprzyk 2017-03-24 09:56:02 UTC
Hello,

I tested the night build:
http://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/2017-03-23_23.17.41/
It works, but only if I have both s64 installations of "LibreOffice 5.4 DEV" and "LibreOffice 5.3.1.2" and I set up the PATH environment variable for "C:\Program Files\LibreOfficeDev 5\program".
If the previous version (5.3.2.1) is not presented on my PC (Windows 10 64-bit) I have the following exception:
"'System.Runtime.InteropServices.SEHException' occurred in cli_cppuhelper.dll"
when calling "
XComponentContext localContext = uno.util.Bootstrap.bootstrap();"
(when debugging using VS 2013 under a C# library .Net 4.5 executing as 64-bit process).

My question is the following what have to be set up (what environnement variable and with which value) in order to use only LibreOffice 5.4 (or it is temporary as it is a developer version).

Thanks.
Comment 21 Buovjaga 2017-03-24 10:00:58 UTC
Apparently C++ Guru was not CC'd on the report.. fixing that now.
Comment 22 Michael Stahl 2017-03-27 19:18:50 UTC
(In reply to Aleksander Kasprzyk from comment #20)
> My question is the following what have to be set up (what environnement
> variable and with which value) in order to use only LibreOffice 5.4 (or it
> is temporary as it is a developer version).

the problem that CLI libraries can't be found sounds familiar...

https://cgit.freedesktop.org/libreoffice/core/commit/?id=814ec7640fc2a529343e358ab4fd3b9a59d645ca

the nightly builds for master do not use --enable-release-build,
which means they don't install anything in C:/Windows or the registry.

you can force it by installing with a parameter:

msiexec /i *.msi WRITE_REGISTRY=1

i hope that that should put the CLI dlls into the "GAC" thing in C:/Windows.

another way that should work for testing is to copy the cli_*.dll files from
C:/LibreOffice/program/ directory into the directory of your client .exe file.
Comment 23 Aleksander Kasprzyk 2017-03-28 16:17:36 UTC
(In reply to Michael Stahl from comment #22)
> you can force it by installing with a parameter:
> 
> msiexec /i *.msi WRITE_REGISTRY=1
> 
> i hope that that should put the CLI dlls into the "GAC" thing in C:/Windows.
> 
> another way that should work for testing is to copy the cli_*.dll files from
> C:/LibreOffice/program/ directory into the directory of your client .exe
> file.
I had already copied cli_*.dll files to excecution folder of my program. And it didn't work.
But with the option WRITE_REGISTRY=1 when installing MSI, it works :)

I mark this bug as resolved.
I'm waiting for the official release of the LibreOffice 5.4 (do you have any time-frame of this release?).
Comment 24 Buovjaga 2017-03-28 16:46:01 UTC
(In reply to Aleksander Kasprzyk from comment #23)
> I'm waiting for the official release of the LibreOffice 5.4 (do you have any
> time-frame of this release?).

https://wiki.documentfoundation.org/ReleasePlan/5.4
Comment 25 Aleksander Kasprzyk 2017-03-29 06:04:19 UTC
Thanks
(In reply to Buovjaga from comment #24)
> (In reply to Aleksander Kasprzyk from comment #23)
> > I'm waiting for the official release of the LibreOffice 5.4 (do you have any
> > time-frame of this release?).
> 
> https://wiki.documentfoundation.org/ReleasePlan/5.4
Comment 26 Commit Notification 2017-03-29 11:01:55 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":

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

cli_ure: fix another bad _WIN64 check (related tdf#94265)

It will be available in 5.4.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 27 Commit Notification 2017-03-29 12:36:46 UTC
ComputingDwarf committed a patch related to this issue.
It has been pushed to "libreoffice-5-2":

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

tdf#94265: Correct the error

It will be available in 5.2.7.

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 28 Commit Notification 2017-03-29 12:36:59 UTC
ComputingDwarf committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

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

tdf#94265: Correct the error

It will be available in 5.3.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 29 Commit Notification 2017-03-30 13:52:50 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

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

cli_ure: fix another bad _WIN64 check (related tdf#94265)

It will be available in 5.3.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 30 Commit Notification 2017-03-30 13:54:33 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=32cee6bb153ede8a79b831ed0cf7a0256d73363c&h=libreoffice-5-2

cli_ure: fix another bad _WIN64 check (related tdf#94265)

It will be available in 5.2.7.

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 31 Aleksander Kasprzyk 2017-05-11 12:57:44 UTC
Hello,

I have just tested with LibreOffice 5.2.7 and it works :)

Thanks.
Comment 32 Jan P. 2017-08-15 14:27:20 UTC
This still (or probably again) happens on 5.4.0.3.
Comment 33 Buovjaga 2017-08-15 17:16:34 UTC
(In reply to Jan P. from comment #32)
> This still (or probably again) happens on 5.4.0.3.

Aleksander: do you get the same result with 5.4?
Comment 34 Buovjaga 2017-08-19 12:04:23 UTC
(In reply to Jan P. from comment #32)
> This still (or probably again) happens on 5.4.0.3.

Jan: can you tell us more about how this happened to you?
Comment 35 Jan P. 2017-08-21 09:15:54 UTC
(In reply to Buovjaga from comment #34)

Hm. Not really. It's just like in the bug description/comments so far.

I can tell you a bit about my environment: It's .NET 4.5 on Windows 8.1 64 bit; I compile for ‘Any CPU‘. The SDK for 32 bit LibreOffice works fine. (Of course only in connection with the 32 bit LibreOffice or OpenOffice and compiled for ‘X86’.)

Perhaps you have any questions I can answer?

Cheers,

Jan