Bug 42826 - unopkg.bin runtime error during installation
Summary: unopkg.bin runtime error during installation
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: Other Windows (All)
: medium blocker
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords: regression
: 43461 (view as bug list)
Depends on:
Blocks: Win-Installer-MAB mab3.5
  Show dependency treegraph
 
Reported: 2011-11-11 08:47 UTC by Rainer Bielefeld Retired
Modified: 2012-05-24 21:39 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot 'fdo#42826.png' (78.16 KB, image/png)
2011-11-14 06:57 UTC, manj_k
Details
Screenshot with more details (102.99 KB, image/png)
2011-11-24 07:28 UTC, Petr Mladek
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rainer Bielefeld Retired 2011-11-11 08:47:08 UTC
Saw that with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID:  6b0de40-0bc4ff4-ca7e6f5-9125509-ce71330)]" (111111)

During Installation I saw a message 

Runtime Error. 
Programm: C:\LOM11111\program\unopkg.bin
This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.

After <ok> I was able to terminate the installation, and it seems to run more or less without bigger problems

Related or not? Since Version 2011-11-09 a DOS Window keeps open as long as the Master LibO is running. I can't remember to have seen that before.

Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110928 Firefox/7.0.1 SeaMonkey/2.4.1
Comment 1 Rainer Bielefeld Retired 2011-11-11 08:50:58 UTC
Looks similar to "Bug 34045 - LibreOffice 3.3 runtime error during installation and startup failure with fatal error", 
"Bug 31764 - Unopkg add failed with pyUno code"

- Reported with Bug Submission Assistant -
Comment 2 manj_k 2011-11-14 06:56:15 UTC
Confirmed with 
LibO-dev 3.5.0 Build ID: 3f170f2-533e3c6-ca7e6f5-9125509-ce71330
[master~2011-11-13_04.17.45...]
on WinXP 32b

See also attached screenshot 'fdo#42826.png'

Related: 'Bug 42914 - Terminal (command) window is opened when launching any executable'
Comment 3 manj_k 2011-11-14 06:57:04 UTC
Created attachment 53529 [details]
Screenshot 'fdo#42826.png'
Comment 4 GerardF 2011-11-14 09:02:15 UTC
Confirmed with Master 2011-11-13 23-17-53 from http://dev-builds.libreoffice.org/daily/Voreppe_Win32_Tinderbox/master/

I found a bug in Calc but i don't know if i should report this bug or wait for an other version without install problem ?
Comment 5 Andras Timar 2011-11-24 01:55:34 UTC
Crash during install is a blocker.
Comment 6 Rainer Bielefeld Retired 2011-11-24 02:23:05 UTC
I' can't tell might be that it's only a nonsense message, but of course, it's inacceptable for the release
Comment 7 Petr Mladek 2011-11-24 06:41:18 UTC
unopkg is called when registering extensions. It would be interesting to find what extension causes this.
Comment 8 Petr Mladek 2011-11-24 06:43:22 UTC
(In reply to comment #4)
> I found a bug in Calc but i don't know if i should report this bug or wait for
> an other version without install problem ?

@GerardF: please, file the bug. This bug causes that one or few extensions are not installed. It should not affect the function of the application => the bug will be most likely valid even when we fix this.
Comment 9 Petr Mladek 2011-11-24 07:25:58 UTC
Adding some Windows experts.
Comment 10 Petr Mladek 2011-11-24 07:28:23 UTC
Created attachment 53832 [details]
Screenshot with more details

Hmm, I have disabled all extensions during installation and got the crash as well.

I have clicked a link to get more details, see the attached screenshot. I am not sure if it has any use.
Comment 11 Petr Mladek 2011-11-24 07:31:01 UTC
I wonder if it might be related to the new Andras's installer. It might call unopkg in a not-yet-installed system or so.

Alternatively it might be related to Stefan's clean up of the 3-layer structure.
Comment 12 Stephan Bergmann 2011-11-24 07:39:15 UTC
what might give insight is to run the whole installation process from within the Depends tool (with attaching to spawned sub-processes enabled)
Comment 13 Don't use this account, use tml@iki.fi 2011-12-01 08:26:44 UTC
Stack trace at crash:

        [bla bla related to the error dialog]
        ...
 	kernel32.dll!_RaiseException@16()  + 0x52 bytes	
 	msvcr90.dll!_CxxThrowException(void * pExceptionObject=0x0012fa64, const _s__ThrowInfo * pThrowInfo=0x4966beb8)  Line 161	C++
>	cppuhelper3MSC.dll!cppu::loadSharedLibComponentFactory(const rtl::OUString & rLibName={...}, const rtl::OUString & rPath={...}, const rtl::OUString & rImplName={...}, const com::sun::star::uno::Reference<com::sun::star::lang::XMultiServiceFactory> & xMgr={...}, const com::sun::star::uno::Reference<com::sun::star::registry::XRegistryKey> & xKey={...}, const rtl::OUString & rPrefix={...})  Line 487 + 0x9b bytes	C++
 	0255d8ce()	
 	cppuhelper3MSC.dll!cppu::ORegistryFactoryHelper::createModuleFactory()  Line 886 + 0x43 bytes	C++
        ...

The interesting part is in 	cppuhelper3MSC.dll!cppu::loadSharedLibComponentFactory()  Line 487 + 0x9b bytes, where the debugger shows that it is trying to load "file:///C:/Program/LibO-dev%203.5/program/../program/binaryurp.uno.dll" , i.e. binaryurp.uno.dll from the "program" folder even if it is in the URE\bin folder. A fallout from the Basis layer removal perhaps?

Anyway, if I move the binaryurp.uno.dll from URE\bin to program, unopkg runs without problems. (Or copy, but just having it in program should work fine.) 

How to fix this then in the build, I don't know. Just have the installer put binaryurp.uno.dll in program instead of URE\bin? That probably would work fine. Or ask whoever it was who did the Basis layer removal if he has any idea how to properly fix this?
Comment 14 Don't use this account, use tml@iki.fi 2011-12-01 08:28:22 UTC
Ah, comment #11 already guessed at this;)
Comment 15 Stephan Bergmann 2011-12-01 08:47:04 UTC
The problem apparently is that Repository.mk maps binaryurp to UNOLIBS_URE, but solenv/gbuild/WNT_INTEL_{GCC,MSC}.mk both map UNOLIBS_URE to OOO in gb_Library_LAYER, so that the binaryurp.component file will contain a uri attribute that points to the program directory instead of URE\bin on Windows.
Comment 16 Don't use this account, use tml@iki.fi 2011-12-01 10:11:58 UTC
So should UNOLIBS_URE be mapped to URELIB then instead? How comes LO itself apparently works fine even with the wrong mapping?
Comment 17 Stephan Bergmann 2011-12-01 11:31:43 UTC
"So should UNOLIBS_URE be mapped to URELIB then instead?"  Looks like it.  solenv/gbuild/platform/unxgcc.mk maps all of PLAINLIBS_URE, RTVERLBS, UNOLIBS_URE, and UNOVERLIBS to URELIB, for example.

"How comes LO itself apparently works fine even with the wrong mapping?"  soffice.bin itself does not normally need the URP bridge (except for live deployment of extensions, which are installed into an additional uno process).
Comment 18 Don't use this account, use tml@iki.fi 2011-12-01 23:52:55 UTC
> soffice.bin itself does not normally need the URP bridge

But what about all the other dlls (UNO components?) affected by this, how are they then found? Or aren't they, but nobody has tried to use a master build in such a way that they would have been needed?
Comment 19 Don't use this account, use tml@iki.fi 2011-12-01 23:58:59 UTC
So would this work?

diff --git a/solenv/gbuild/platform/WNT_INTEL_MSC.mk b/solenv/gbuild/platform/WNT_INTEL_MSC.mk
index 7a56245..22b8392 100644
--- a/solenv/gbuild/platform/WNT_INTEL_MSC.mk
+++ b/solenv/gbuild/platform/WNT_INTEL_MSC.mk
@@ -432,13 +432,13 @@ gb_Library_PLAINLIBS_NONE += \
 gb_Library_LAYER := \
        $(foreach lib,$(gb_Library_OOOLIBS),$(lib):OOO) \
        $(foreach lib,$(gb_Library_PLAINLIBS_NONE),$(lib):OOO) \
-       $(foreach lib,$(gb_Library_PLAINLIBS_URE),$(lib):OOO) \
+       $(foreach lib,$(gb_Library_PLAINLIBS_URE),$(lib):URELIB) \
        $(foreach lib,$(gb_Library_PLAINLIBS_OOO),$(lib):OOO) \
        $(foreach lib,$(gb_Library_RTLIBS),$(lib):OOO) \
-       $(foreach lib,$(gb_Library_RTVERLIBS),$(lib):OOO) \
-       $(foreach lib,$(gb_Library_UNOLIBS_URE),$(lib):OOO) \
+       $(foreach lib,$(gb_Library_RTVERLIBS),$(lib):URELIB) \
+       $(foreach lib,$(gb_Library_UNOLIBS_URE),$(lib):URELIB) \
        $(foreach lib,$(gb_Library_UNOLIBS_OOO),$(lib):OOO) \
-       $(foreach lib,$(gb_Library_UNOVERLIBS),$(lib):OOO) \
+       $(foreach lib,$(gb_Library_UNOVERLIBS),$(lib):URELIB) \
 
 gb_Library_FILENAMES :=\
        $(foreach lib,$(gb_Library_TARGETS),$(lib):$(gb_Library_SYSPRE)$(lib)$(gb_Library_PLAINEXT)) \


I see that unxgcc.mk contains a gb_Library_LAYER mapping for gb_Library_PLAINLIBS_NONE, but WNT_INTEL_MSC.mk doesn't. Should it?

Also, if this gb_Library_LAYER thing is supposed to be the same everywhere, why can't it be factored out into just one of the .mk files?
Comment 20 Stephan Bergmann 2011-12-02 00:01:48 UTC
Re comment 18, most (if not all) of the URE modules that contain .component files (like cppuhelper, javaunohelper, stoc) are still dmake-based, using the working solenv/inc/settings.mk COMPONENTPREFIX_* mechanism.
Comment 21 Stephan Bergmann 2011-12-02 00:04:52 UTC
Maybe Björn or Michael Stahl can give input on comment 19.
Comment 22 Don't use this account, use tml@iki.fi 2011-12-02 00:17:58 UTC
ah, ok, yes the fact that so much still uses dmake probably is the key here. OK, so I will make the change from comment #19 and see what happens.
Comment 23 Michael Stahl (allotropia) 2011-12-02 01:46:50 UTC
i, for one, have no idea why the layer thing maps everything to OOO on windows currently, comment #19 looks entirely plausible to me.

please check if the MinGW stuff has the same problem?
Comment 24 Jesus Corrius 2011-12-02 06:13:55 UTC
*** Bug 43461 has been marked as a duplicate of this bug. ***
Comment 25 Don't use this account, use tml@iki.fi 2011-12-05 00:00:34 UTC
Should be fixed now with:

commit a35140f245d774745b806ef12346aa77f0256395
Author: Tor Lillqvist <tlillqvist@suse.com>
Date:   Fri Dec 2 11:41:33 2011 +0200

    Fix library layer mapping for the URELIB ones, fdo#42826