Libreoffice runtime error soffice bin

Description

narayanaras

2012-06-20 02:18:13 UTC

Whenever I start LO, it gives the following error:

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program: C:Program FilesLOdev 3.6programsoffice.bin

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.


---------------------------
OK   
---------------------------

I removed both LO and the VC++ 2010 SP1.
Then I restarted the PC, and installed both.
I restarted the PC after re-installing each.
Yet the result is the same.

Comment 1

narayanaras

2012-06-20 21:07:46 UTC

P.S. I have two computers with Windows 7. 

Out of those, one works perfectly with LO 3.6 Beta1.
But the other computer has the starting trouble as described above.

I have installed the latest JRE6 on both computers because LO had trouble with JRE7. (Just clarifying, in case this is a significant factor.)

Comment 2

Masaki Tamakoshi

2012-06-23 20:13:11 UTC

I installed 3.6 beta 2, but the dialogue of the C++ run-time error is displayed and cannot start at all today.
All the run time is installed. 
3.5.* can start without a problem.

Windows 7 Home Premium(64bit) sp1
Dell Studio 1557
Intel Core i7 Q720 1.60GHz
4GB RAM

Comment 3

Korrawit Pruegsanusak

2012-06-23 22:19:34 UTC

Thanks for the bug report!

I didn't test this, but as Masaki can confirm this bug, I set this as NEW.

Also, I change the version and platform fields because (1) version field should be the earliest version with the problem, and (2) we don't have 64bit version for Windows.

Comment 4

narayanaras

2012-06-25 01:54:21 UTC

UPDATE for BETA-2:

Beta2 behaves exactly same as beta1: 
* In the PC where Beta1 worked, beta2 also works. 
* In the PC where beta1 did not start, beta2 also does not start.

Comment 5

Petr Mladek

2012-06-27 07:00:54 UTC

Andras, Tor, any idea here?

Comment 6

Andras Timar

2012-06-27 07:21:56 UTC

VC++ 2010 SP is not related. LibreOffice uses VC++ 2008 runtime.

Comment 7

narayanaras

2012-06-27 08:34:33 UTC

When I say VC++ 2010 SP1, I mean the VC++ runtime only. (Not MS Visual Studio)

The Redistributable Package is downloadable from here:
http://www.microsoft.com/en-us/download/details.aspx?id=5555

This classes in the 2010 version should be compatible with 2008 version.
And if they are not, then LibreOffice should not use a 4 year old product.
(It should use the latest version)

Comment 9

Masaki Tamakoshi

2012-07-07 21:01:23 UTC

I installed LibO-Dev_3.6.0.0.beta3_Win, but cannot start by the same error.

Comment 10

Masaki Tamakoshi

2012-07-13 11:42:17 UTC

LibO_3.6.0.1_Win_x86 cannot start by the same error too

Comment 11

Michael Meeks

2012-07-19 13:07:58 UTC

Thanks - it turns out we need to re-distribute this for Java support - I suspect this is fixed by Andras in bug#50584.

Andras - this sounds really serious for 3.6.0 - what are we doing to get the patch in 50584 back-ported ? :-)

Comment 12

Andras Timar

2012-07-19 13:18:32 UTC

(In reply to comment #11)
> Andras - this sounds really serious for 3.6.0 - what are we doing to get the
> patch in 50584 back-ported ? :-)

Masaki Tamakoshi has all versions of MSVC runtime installed, and still has the bug, so it must be different.

Comment 13

narayanaras

2012-07-19 14:47:38 UTC

Since the other bug mentioned JRE7, I'd like to clarify that I have installed JRE6 precisely because earlier versions of LO were not working with JRE7. 

As a result, my PC has both JRE6 and JRE7.

That said, since my LO is not even starting, I cannot use the program options to select a particular JRE version.

Thanks.

Comment 14

Claude

2012-07-20 19:33:09 UTC

The same ocurred to me when installed Libo 3.6.0.1 in a Windows XP SP3 system but not in a Windows 7 home premium system.
As it was said on discussion lists, the problem disappears by erasing the user folder (alas, loosing your customizations).  Trying to pinpoint de offender I was able to trace it down to the uno_packages directory.
Hope this helps....

Claude

Comment 15

manj_k

2012-07-21 19:12:38 UTC

*** Bug 52341 has been marked as a duplicate of this bug. ***

Comment 17

Masaki Tamakoshi

2012-07-22 03:19:14 UTC

LibO_3.6.0.2_Win_x86　cannot start by the same error!
In this situation I cannot use it even if LibreOffice3.6 is released as a stable edition.

Created attachment 64505 [details]
Error message, complete

Contains full text of error message, more info about erromsg and contents of error report

I just installed version 3.6.0.2 in a different directory than previous installation - version 3.5.5.

OS: XP sp3

I got the same error. as described.

Situation of installation of LibO:
 Previous version of LibO was 3.5.5
 Previous version was not uninstalled prior to installation of 3.6.0.2
 Version 3.6.0.2 was installed in a different directory than previous version.
 Local help pack for version 3.6.0.2 was installed too.

I did not run LibO between installation of main application and installation of local help pack.

I get this error on first time run. I have not yet restart the computer and can therefore not tell if the result will be the same then.

I haven't tried to erase files in user dir, but can give it a try.

I attach the full error report in a text file. I hope that can help to fix the error

[OT]
Uploading an attachment here is a very confusing process. The site tells me to comment the attachment, but whan I look after it have deletet my entire original comment and replaced that with the short comment for the attachment.

Thanks to a program I have that saves contents from clipboard, I didn't lost the contents I was about to post.

Hi again.

I've done following and get LibO 3.6.0.2 to work:

1: Installed "Microsoft Visual C++ 2010 Redistributable Package (x86)" to my computer.
2: Deleted all files and subdirs under "C:Documents and Settings<my username here>ProgramdataLibreOffice3user".

I'm pretty sure that action 1 was not neccesary because after installing MSVC2010 I still got the same error message.

But after deleting all previous settings, the program seems to work just fine.

I could share my settings if that would help, but then I cannot upload a compressed zip/rar/7z file because of limits on this site.

Comment 21

Andras Timar

2012-07-22 19:48:05 UTC

(In reply to comment #20)
> I could share my settings if that would help, but then I cannot upload a
> compressed zip/rar/7z file because of limits on this site.

You can upload it to Dropbox or to any other free cloud storage service and post the link here. Many thanks for your help. The attached error message does not contain useful information.

Comment 22

narayanaras

2012-07-23 05:50:42 UTC

Now that two people have confirmed that deleting the user folder solves this issue, can someone please debug in that direction?

BTW what is the workaround to avoid losing the settings? I have done a lot of customization, and would hate to lose all that hard work. Is there some way to export the settings and import them after the new version starts working?

I Googled to look for solution, but they only talk about copying the user folder; which probably will start the issue once again!

Comment 23

V Stuart Foote

2012-07-24 17:25:31 UTC

*** Bug 52439 has been marked as a duplicate of this bug. ***

Comment 24

Mikeyy — L10n HR

2012-07-24 19:37:33 UTC

+1 Deleted user folder on my Win7 64bit and LibreOffice started without problems.

I reported duplicate of this bug 52439.

Comment 25

Masaki Tamakoshi

2012-07-24 22:19:28 UTC

Hi!

3.6 was not able to start so far in C++ runtaime error, but was able to start when I deleted "C:Documents and SettingsusernameApplication DataLibreOffice" and installed it.

I thank all all of you

However, I think that a correction is necessary early because this method is not a thing recommended to all people.

Comment 26

Petr Mladek

2012-07-25 08:25:37 UTC

We are going to track down this bug with high priority. Unfortunately, it is not easy, so it might take some time. It affects only selected group of users with some particular setting => it should not block the release for others => slightly reducing the severity.

Comment 28

Stephan Bergmann

2012-07-25 09:15:49 UTC

There are a few things an affected user can do to help us track down the root cause for this issue:

For one, providing a zip of LibreOffice's per-user configuration data (typically located at something like "C:Documents and Settings<username>Application DataLibreOffice3user") might help.  (It can also help workaround this issue to move that directory away, see previous comments.  LibreOffice will automatically re-create default configuration data upon the next start, but for tracking down this issue, it would be necessary to zip the original, failing data.)  That data should not normally contain any really sensitive data, but you can always arrange to send the zip directly to a trustworthy developer instead of attaching it here.  Alternatively, one particular file within the per-user configuration data known to be notorious is userregistrymodifications.xcu.  It might already help to only make available that one file (and it might in turn already help to just move away that one file to workaround this issue; again, it is automatically re-created with default data upon the next start).

For another, one can install the Dependency Walker tool (depends.exe, see <http://www.dependencywalker.com/>) and run LibreOffice from within it.  This often gives useful information.  To do so, start depends.exe, load programsoffice.exe from the LibreOffice installation into it ("File - Open..."; depending on your Windows settings, the ".exe" extension might not show, in which case there can be multiple files just named "soffice" in the program directory; the soffice.exe one has the white LibreOffice document icon).  Then "Profile - Start Profiling...", make sure "Automatically open and profile child processes" is checked, then "OK".  This will start an additionl window within Dependency Walker for the soffice.bin sub-process (which is the one actually of interest to us), it is typically named all-caps "SOFFICE" (whereas the original window for soffice.exe is named all-lowercase "soffice", also see the "Window" menu).  Click through all the error messages indicating that LibreOffice cannot start.  In that window for soffice.bin, the bottom frame should give lots of output (leading up to some "Exited 'SOFFICE.BIN' (process ...) with code ..."), copy all that output and make it available for inspection.

For a third, the next LibreOffice 3.6.0.3 rc will hopefully show a somewhat more detailed "Fatal Error" message box with some "Uncaught exception" information when a user is hit by this issue.

Comment 30

Stephan Bergmann

2012-07-25 09:31:57 UTC

*** Bug 52439 has been marked as a duplicate of this bug. ***

Comment 32

Mikeyy — L10n HR

2012-07-25 12:31:16 UTC

I zipped my LibreOffice folder and it's 47MB, where do you want that sent? :)

Comment 33

beimaginativeegroup

2012-07-25 12:44:57 UTC

After deleting the LibreOffice folder, it works!

Comment 34

Stephan Bergmann

2012-07-25 13:35:18 UTC

(In reply to comment #32)
> I zipped my LibreOffice folder and it's 47MB, where do you want that sent? :)

You can send it to me directly, sbergman at redhat dot com.  Thanks.

Comment 35

Stephan Bergmann

2012-07-26 11:18:15 UTC

I now understand what is going on, know how to reproduce the problem, and have found a solution.  There are various factors that are involved:

1  The LO 3.6.0 installation set needs to contain a share/prereg/bundled directory (containing pre-registered information about bundled extensions, that is later copied into per-user configuration data, when a user starts LO).  This is automatically created (via "unopkg sync") for standard installation sets when those installation sets are created in instsetoo_native.  However, it is not created for the "make dev-install" installation set (at least not on Linux), in which case one needs to create it manually to reproduce this problem, calling "install/program/unopkg sync --verbose" (and watch out for errors, see next).

2  The LO 3.6.0 build must not be configured --enable-ext-barcode (to include the Barcode extension as a bundled extension in LO installation sets).  Registering that extension as a bundled extension is broken.  (Quoting from a recent mail to Kami:  "The problem (building with --enable-ext-barcode leads to a broken bundled Barcode extension) is still there with Barcode version 1.3.5, but I now found out why that is so:  If you start with a fresh user installation (i.e., after 'rm -rf ~/.config/libreoffice' on Linux), LO tries to register bundled extensions' components in an environment where bundled extensions' configuration data is not available.  But Barcode's barcode-loader.py requires Barcode's Barcode.{xcs,xcu} to be registered (def getpath: 'config = getconfig( ctx, 'org.openoffice.%sSettings/ConfigNode'%classname )'), which raises an exception that is unhelpfully swallowed by the try: ... except: debugexception() in barcode-loader.py.  Using passive component registration for Barcode should work around that problem.")  That in turn causes "unopkg sync" (whether called automatically in insetsetoo_native or manually, see above) to silently fail mid-way, leading to a half-populated share/prereg/bundled that might or might not allow to reproduce the problem.

3  At least on Linux (other than on Windows) the problem cannot currently be reproduced because <http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfbece50ebaeaf45ea3f016d911b5de7c878afc5> "Make --help and --version work even without $DISPLAY" added UNX-only code that already creates the service manager very early (at the start of soffice_main), before Desktop::Init decides whether or not to copy share/prereg/bundled into the per-user configuration data.  That inadvertently hides this problem.  (But it leads to issues of its own, like bundled extensions not working properly on first start.  Those issues are fixed with the fix for this issue, too, namely to not copy share/prereg/bundled into per-user configuration data, see below)  To work around that reproduction hindrance, one can temporarily disable that code in LO 3.6.0, by replacing the "#ifdef UNX" in soffice_main (desktop/source/app/sofficemain.cxx) with "#if 0".

4  One needs a LO 3.5.x installation (or maybe even older) including some bundled extension X (that contains UNO components), and that same extension also as an oxt.  Also, the LO 3.6.0 installation set needs to bundle that extension (in a higher version), too.  For example, I used the LO 3.5.4 that comes bundled with Fedora 17 as /usr/lib64/libreoffice/program/soffice.  It bundles Presenter Console 1.1.0, and the LO 3.6.0 installation set bundles Presenter Console 1.1.1.  (To produce an oxt of Presenter Console 1.1.0, one can do "(cd /usr/lib64/libreoffice/share/extensions/presenter-screen && zip -r ~/old-presenter-screen.oxt *)".)

5  Produce a clean starting point by removing any old per-user configuration data, "rm -rf ~/.config/libreoffice".

6  Start the LO 3.5.x (/usr/lib64/libreoffice/program/soffice), "Tools - Extension Manager...", "Add...", select the old-presenter-screen.oxt, install it for the current user only.  (It will replace the bundled version for this user, the Extension Manager will display it without a lock now.)

7  Make sure the LO 3.6.0 share/prereq/bundled/lastsynchronized is newer than the corresponding ~/.config/libreoffice/3/user/extensions/bundled/lastsynchronized: "touch install/share/prereq/bundled/lastsynchronized" (or wherever that installation is).

8  Now start the LO 3.6.0 soffice.  It will fail to start, reporting some "UNO Exception: InvalidRegistryException: file:///.../opt/program/../share/extensions/presenter-screen/components.rdb: duplicate <implementation name='com.sun.star.comp.Draw.framework.PresenterScreenJob'>."

9  The problem is that LO is careful to only ever have a single instance of an extension actually installed for a given user (even if instances of that extension are installed both bundled and per-user), but the logic to copy share/prereg/bundled into the per-user configuration data bluntly shortcuts that and breaks that carefully maintained invariant.  The irony is that share/prereg/bundled is only an optimization, to save a little time at first start of LO (when started for the very first time for a user, or after an upgrade).  For functionality it is not needed---rather, it is demonstrated here to be harmful, at least in its current implementation (see both this problem and the issues mentioned under (3)).  Therefore, I propose to fix this by disabling the share/prereg/bundled feature.  The simplest way to do so for LO 3.6.0 is by adding "if (false)" before the call to copy_bundled_recursive in Desktop::Init (desktop/source/app/app.cxx).  (That way, compiling does not cause spurious warnings about unused code.)

10  However, once a user ran into this problem (which in turn can only happen if she ever ran a LO snapshot up to LO 3.6.0 rc3), her per-user configuration data is broken, and fixing LO 3.6.0 as per (9) will not help.  In such a case, it is necessary to manually remove the "extensions" directory from the per-user configuration data once: "rm -rf ~/.config/libreoffice/3/user/extensions".  That per-user information about bundled (and shared) extensions is strictly a cache; it is recreated upon the next start of LO without any loss of functionality.

11  I explained the above in the context of Linux, but I verified that it all works exactly the same on Windows.

Comment 37

Caolán McNamara

2012-07-26 11:50:37 UTC

FWIW see fdo#37195 for the last time copy_bundled_recursive tripped us up.

Comment 38

narayanaras

2012-07-26 12:48:41 UTC

Assuming that the bug is not yet resolved, here's another idea:

I have a PC that has the problem. 
I have another PC that does NOT have problem in installing 3.6 betas.
Both PCs are running WIn 7.

So what I could do is-

1. Compare the user profile folders from both PCs, find differing files, and send only these files.

2. Compare the user profile folder in failed PC before and after installing 3.6.

Within this set, if some subfolders are expected to change, we can exclude them from the comparison.

Comment 39

Stephan Bergmann

2012-07-26 13:54:51 UTC

*** Bug 52495 has been marked as a duplicate of this bug. ***

Comment 41

Rainer Bielefeld Retired

2012-07-26 20:53:39 UTC

*** Bug 52017 has been marked as a duplicate of this bug. ***

Comment 43

narayanaras

2012-07-27 08:46:22 UTC

From which version will this patch be working?

Can we assume that either RC3 (if it is released) or the final release 3.6 will have this patch?

Comment 44

Michael Meeks

2012-07-27 23:07:08 UTC

> From which version will this patch be working?

   Good question - don't get confused by the above automated version comment :-)

> Can we assume that either RC3 (if it is released) or the final release 3.6
> will have this patch?

   No - however we delayed 3.6.0 and re-spun an RC4 primarily to fix this bug - thank you so much for the QA input: extremely valuable ! :-) The earlier we can do testing the more likely we can stick to our release plan though :-)

Comment 45

narayanaras

2012-07-28 04:03:59 UTC

@earliest-possible feedback:
My home PC works fine with 3.6.0.x, but my workplace PC has the problem.
Therefore I can give a feedback only when I go to work on Monday morning (approx 7 AM WET). 

Others may be able to provide the feedback earlier than that, though.

But RC4 is not available yet!
http://www.libreoffice.org/download/pre-releases/

Thanks for the lightening-fast responses!

Comment 46

V Stuart Foote

2012-07-29 20:50:29 UTC

Reesponding to Fridrich Strba's Dev list posting, Sat, 28 Jul 2012 22:57, that 3.6.0 RC4 build was available:

>http://dev-builds.libreoffice.org/pre-releases/

>If you've a bit of time, please give them a try & report *critical*
>bugs not yet in bugzilla here, so we can incorporate them into the
>release notes. Please note that it takes approximately 24 hours to
>populate the mirrors, so that's about the time we have to collect
>feedback.
>
>NOTE: This build is in a release configuration and _will_ replace your
>existing LibreOffice install on Windows.

Unfortunately, the entire bug may not be completely quashed at least for Windows users, and it will require a work around be published in the know issues in the release notes for 3.6.0.

Specifically, following installation of 3.6.0.4 where on first launch
per-user, the splash screen opens with configuring "enabling" extensions scrolling across its bottom, but nothing further after the splash screen closes.  No errors, no log entries that I could find. But LO comes up fine for each user on subsequent launch attempts.

On this system, prior to installation, LO 3.6.0.2 was fully uninstalled and Windows registry cleared of all LibreOffice configuration. Per-user profile settings had all been manually deleted--so pretty much a new install.

Accessibility and desktop icon selected during install.

Version 3.6.0.4 (Build ID: 932b512)
Windows 7, 64-bit
JRE 1.7u5
Java Access Bridge  2.02 

(Note: NVDA 2012.2.1 fully functional in 3.6.0.4 once it is relaunched.)

Comment 47

Andras Timar

2012-07-29 21:21:45 UTC

(In reply to comment #46)
> Specifically, following installation of 3.6.0.4 where on first launch
> per-user, the splash screen opens with configuring "enabling" extensions
> scrolling across its bottom, but nothing further after the splash screen
> closes.  No errors, no log entries that I could find. But LO comes up fine for
> each user on subsequent launch attempts.

It was expectable. Bug 43989 came back because the band aid fix (comment 42) did not fix the underlying bug, just avoided the situation, when it was triggered.

Comment 48

V Stuart Foote

2012-07-30 02:04:35 UTC

Andras,

Reading through the https://bugs.freedesktop.org/show_bug.cgi?id=43989 issue, I should add that during this (and most of my installs) I run the MSI package as Administrator, either from command line or from explorer shell. I didn't grab an installer log in this case, but could back it all out and run again if it would be helpful to see status of the components as they are being registered. I'm not clear on how one would capture state of the LO registry and extensions as they are being registered at the initial LO launch following install.

Any chance that the resurgence of 43898 bug, as you'd fixed by running unopkg.exe with elevated privileges during installation,  is now being being borked by the MSI installer custom action bundling of MS Visual C++ 2010 Runtime done for https://bugs.freedesktop.org/show_bug.cgi?id=50584#c4 -- rather than Stephan's comment 42 patch.

Fortunately the work around (remove per-user profiles, and an initial relaunch of LO per-user) seem fairly reliable. But should 43898 be reopened?

Stuart

Comment 49

narayanaras

2012-07-30 02:12:46 UTC

Comment #46 states that-

"Per-user profile settings had all been manually deleted--so pretty much a new
install."

This workaround was already available, but as we discussed in this bug, the
user loses all customizations, and therefore it is NOT a good solution at all. 

Therefore we were waiting for a bugfix that allows us to install RC4 without
first removing the user profile left behind by RC2.

Does RC4 have that bugfix?

Thanks.

Comment 50

narayanaras

2012-07-30 06:11:06 UTC

I installed 3.6.0.4 (RC4) on a PC that had problems with earlier betas.
This PC runs Windows 7. 

I opened the 3.6 installation folder and ran the soffice.exe file.

Immediately I got this new error:
---------------------------
Fatal Error
---------------------------
Unhandled exception:
InvalidRegistryException: file:///C:/Program%20Files/Util/LibreOffice%203.6/program/../share/extensions/NLPSolver/components.rdb: duplicate <implementation name="com.sun.star.comp.Calc.NLPSolver.DEPSSolverImpl">
---------------------------
OK   
---------------------------

When I pressed OK, I got the usual error:

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program: C:Program FilesUtilLibreOffice 3.6programsoffice.bin

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

---------------------------
OK   
---------------------------

I clicked on the OK button.

After that, Windows popped up an error message: 
----------------------------------------------------------------
LibreOffice 3.6 has stopped working. 

Windows can check online for a solution for the problem.

> Check online for a solution and close the program.
> Close program
                         +Details
----------------------------------------------------------------

I clicked on the "Details" button, and got the following details:

Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	soffice.bin
  Application Version:	3.6.0.104
  Application Timestamp:	5012ee18
  Fault Module Name:	MSVCR90.dll
  Fault Module Version:	9.0.30729.6161
  Fault Module Timestamp:	4dace5b9
  Exception Code:	40000015
  Exception Offset:	0005beae
  OS Version:	6.1.7601.2.1.0.256.48
  Locale ID:	16393
  Additional Information 1:	da1d
  Additional Information 2:	da1ded6ec030c928f1fd6b1823bcd02d
  Additional Information 3:	41b4
  Additional Information 4:	41b4943b8cf2e97327d72b2da8a7828e

*****************

After that, I tried to run the executables for Impress, Writer, and Calc.
Each of them has the same three error responses. 

Strangely, even the non-Calc apps report problem with a Calc plugin (maybe it is shared??). 

TO CONCLUDE: 
RC4 also has the same old problem. In fact, it is WORSE than RC2, because now there is an additional unhandled exception.

Comment 51

Stephan Bergmann

2012-07-30 07:09:41 UTC

(In reply to comment #49)
> Comment #46 states that-
> 
> "Per-user profile settings had all been manually deleted--so pretty much a new
> install."
> 
> This workaround was already available, but as we discussed in this bug, the
> user loses all customizations, and therefore it is NOT a good solution at all. 
> 
> Therefore we were waiting for a bugfix that allows us to install RC4 without
> first removing the user profile left behind by RC2.
> 
> Does RC4 have that bugfix?

No.  RC4 only prevents the startup failure for users that never installed an earlier RC towards LO 3.6.0.  If you did install such an earlier RC, you manually need to remove the "extensions" directory from the per-user configuration data once, see point 10 of comment 35.

Comment 52

narayanaras

2012-07-30 08:03:52 UTC

ok I did install the earlier betas..

However, point 10 of comment #35 talks about Linux installation. Mine is for Windows 7. So I am not clear what to do next.

I searched for a similar folder structure, and the nearest match is here:
C:Users<myUserName>AppDataRoamingLibreOffice3userextensions.

This folder has three subfolders: Bundled, shared, tmp.
So which folders should I delete?

Thanks in advance!

-Narayan

Comment 53

narayanaras

2012-07-30 08:17:32 UTC

(In reply to comment #52)
> ok I did install the earlier betas..
> 
> However, point 10 of comment #35 talks about Linux installation. Mine is for
> Windows 7. So I am not clear what to do next.
> 
> I searched for a similar folder structure, and the nearest match is here:
> C:Users<myUserName>AppDataRoamingLibreOffice3userextensions.
> 
> This folder has three subfolders: Bundled, shared, tmp.
> So which folders should I delete?

I went ahead and deleted the "extensions" folder. 

When I started LibO, it went through the starting screen (The green rectangle with LibO logo and "LibreOffice" title, which shows progress bar at bottom to show which activity is going on.) However, at the end, the Soffice GUI did NOT appear. Process Explorer also did not show soffice process running.

So I launched LibO once again, and this time it launched properly. I can open old documents and create new docs and save them.

Comment 54

Stephan Bergmann

2012-07-30 08:38:24 UTC

(In reply to comment #53)
> (In reply to comment #52)
> > ok I did install the earlier betas..
> > 
> > However, point 10 of comment #35 talks about Linux installation. Mine is for
> > Windows 7. So I am not clear what to do next.
> > 
> > I searched for a similar folder structure, and the nearest match is here:
> > C:Users<myUserName>AppDataRoamingLibreOffice3userextensions.
> > 
> > This folder has three subfolders: Bundled, shared, tmp.
> > So which folders should I delete?
> 
> I went ahead and deleted the "extensions" folder. 

Yes, removing the complete "extensions" folder with all its subfolders is fine.  ("That per-user information about bundled (and shared) extensions is strictly a cache; it is recreated upon the next start of LO without any loss of functionality.")

> When I started LibO, it went through the starting screen (The green rectangle
> with LibO logo and "LibreOffice" title, which shows progress bar at bottom to
> show which activity is going on.) However, at the end, the Soffice GUI did NOT
> appear. Process Explorer also did not show soffice process running.
> 
> So I launched LibO once again, and this time it launched properly. I can open
> old documents and create new docs and save them.

That silent termination upon firststart is odd.  It is in line with comment 46, and comment 47 suggests that this is due to bug 43989.  However, that bug is fixed for quite a while now, so it must be something different.  I will have a look.

Comment 55

Andras Timar

2012-07-30 09:02:15 UTC

(In reply to comment #54)
> That silent termination upon firststart is odd.  It is in line with comment 46,
> and comment 47 suggests that this is due to bug 43989.  However, that bug is
> fixed for quite a while now, so it must be something different.  I will have a
> look.

You fixed it only on master and you did not want to backport it to 3-6 and 3-5.

Comment 56

Stephan Bergmann

2012-07-30 09:10:46 UTC

(In reply to comment #55)
> (In reply to comment #54)
> > That silent termination upon firststart is odd.  It is in line with comment 46,
> > and comment 47 suggests that this is due to bug 43989.  However, that bug is
> > fixed for quite a while now, so it must be something different.  I will have a
> > look.
> 
> You fixed it only on master and you did not want to backport it to 3-6 and 3-5.

Ach, you are right.  (I had started to become confused by the various fixes mentioned in bug 43989, not all of which indeed had been backported consistently.  And, to speed things up, I had tested the fix for *this* issue only on master on Windows, so didn't notice that gotcha.)

Comment 57

narayanaras

2012-07-30 09:18:48 UTC

So how do we conclude? 

1. Do you need any more tests/validations?
2. What's the strategy for 3.6 final?

Will some users (esp. those who tried out the 3.6 RCs) still have to manually find and delete the extension folder? (Desired: The installer should handle that.)

Thanks,
-Narayan

Comment 58

Stephan Bergmann

2012-07-30 09:28:03 UTC

(In reply to comment #57)
> 1. Do you need any more tests/validations?

No, I don't think so.

> 2. What's the strategy for 3.6 final?

Leave it at the current state, I would say.  While that "silent termination upon firststart" issue is unfortunate, I think it is only a minor annoyance with trivial workaround (just start LO anew) that does not warrant yet another RC5.  (I will see to get my fix for issue 43989 backported for LO 3.6.1, though.)

> Will some users (esp. those who tried out the 3.6 RCs) still have to manually
> find and delete the extension folder? (Desired: The installer should handle
> that.)

Yes, users who tried out 3.6 RC < RC4 and ran into this issue will still need to manually remove the extensions folder.  My hope would be that only a small circle of users is affected and that those users are capable of doing that manually (as demonstrated by having installed an RC in the first place).

That's my take on it, anyway.

Comment 59

Mikeyy — L10n HR

2012-07-30 11:38:46 UTC

Tested it on my 3.5.5 WinXP installation which failed before.
After 3.6.0.4 installation, I started LO. It took about 1,5-2 minutes to pass loading screen.

It stoped longest on Loading: Presentation console and Wiki publisher.

When it finished all it just "crashed", not showed anything after.

After running LO again, it run normally.

Comment 60

narayanaras

2012-07-30 12:37:14 UTC

Comment #59 mentions that the progress bar screen took a long time to complete. I too observed that, but it may not be significant: Even GIMP takes a long time to register the components when started for the first time.

****
I have another observation:

I have done the same installations on two different PCs, including the RCs. But yet the RCs failed in one PC consistently, where as they worked in the other consistently.

This does not match the theory that data corruption leads to this problem. Even if that did happen, it should happen in both PCs. Then why does it happen in one PC only? :S

Comment 61

Stephan Bergmann

2012-07-30 14:21:04 UTC

(In reply to comment #60)
> Comment #59 mentions that the progress bar screen took a long time to complete.
> I too observed that, but it may not be significant: Even GIMP takes a long time
> to register the components when started for the first time.

This is unfortunate indeed.  (And relatively slow first start was the reason the---inherently broken---preregistration mechanism was introduced in the first place.  However, this should be addressed by seeing to speed up extension registration in general, not by working around it by adding an inherently broken preregistration mechanism.)

> ****
> I have another observation:
> 
> I have done the same installations on two different PCs, including the RCs. But
> yet the RCs failed in one PC consistently, where as they worked in the other
> consistently.
> 
> This does not match the theory that data corruption leads to this problem. Even
> if that did happen, it should happen in both PCs. Then why does it happen in
> one PC only? :S

In all the cases I have seen so far, whether the problem occurred depended on whether certain extensions (that are also bundled) had been installed per-user.

Comment 62

ribotb

2012-07-30 14:37:03 UTC

I got the same error message (as narayanaras) in this case :
- Previous version 3.5.5
- Previous version was not uninstalled prior to installation of 3.6.0.4
- Version 3.6.0.4 was installed in a different directory LibreOffice 3.6) than previous version (LibreOffice 3.5)

What I did :
- Uninstall 3.6.0.4
- Reinstall the 3.5.5 version
- Uninstall this version
- Install 3.6.0.4

It's OK

Comment 63

ribotb

2012-07-30 14:56:20 UTC

I forgot :
My configuration is 
- Windows 7 32bits SP1
- JRE 1.7u5

Comment 64

narayanaras

2012-07-30 15:12:47 UTC

> In all the cases I have seen so far, whether the problem occurred depended on
> whether certain extensions (that are also bundled) had been installed per-user.

So do you want to isolate the addons (extensions) that may have caused this
crash? 

Then I am in a position to give you good data:
As I mentioned earlier, I one "ok" PC and one "not ok" PC.
Presumably the culprit addon exists in the "not ok" PC only.

Please let me know hot to export the list, and I will send you lists from both PCs.

Apart from the bundled extensions, I have installed some additional extensions
from http://extensions.libreoffice.org. Both PCs have a little different set of
extensions.

So comparing the list would probably trap the culprit.

What do you think?

Comment 65

Stephan Bergmann

2012-07-30 15:17:41 UTC

(In reply to comment #64)
> So do you want to isolate the addons (extensions) that may have caused this
> crash? 

There is no more need for that from my end.  Potentially problematic is any extension that is both bundled and installed per-user.

Comment 66

narayanaras

2012-08-02 09:23:01 UTC

Thanks, Stefan and all!

Comment 67

manj_k

2012-08-07 22:19:40 UTC

*** Bug 52412 has been marked as a duplicate of this bug. ***

Comment 68

David Clayton

2012-08-09 08:23:58 UTC

Hi,

This still looks to be an issue.

Windows 7x64.  previous 3.5.5 installed. 
Ran 3.6.0 setup - get Runtime Error part way through install, and on LO startup.
Deleted C:Users...AppDataRoamingLO as per recommendation for this bug.

re-ran setup (repair) which completes without the error.
Open LO, part way through loading get: Runtime error in soffice.bin R6025 pure virtual function call.

I'm going to try a full un-install and re-install.

David

Comment 69

Stephan Bergmann

2012-08-09 08:36:25 UTC

(In reply to comment #68)
> This still looks to be an issue.

The fact that you removed the complete AppDataRoamingLibreOffice and the "pure virtual function call" make that look like another problem, unrelated to this issue.

Comment 70

David Clayton

2012-08-09 08:53:19 UTC

(In reply to comment #69)

Hi Stephan, thanks for your quick reply. I tried a full in-stall, deleted user profile, re-installed. When you start LO it hangs on the step 'Enabling Presenter console'. David

Comment 71

narayanaras

2012-08-09 09:04:43 UTC

IMHO the common symptoms reported by several users in THIS bug is already addressed successfully.

Your symptom seem to be totally different (although that too prevents LO from starting). Therefore could you file another bug?

Thanks!

Comment 72

David Clayton

2012-08-09 09:49:48 UTC

Stephan, 

I did an experiment and tried with my anti-virus service stopped, LO installed and started without any errors. I'm going to try on another Win 7 PC to be sure, and might see if the AV vendor has seen this behaviour before.

David

Comment 75

bfoman (inactive)

2012-10-04 20:29:34 UTC

*** Bug 53690 has been marked as a duplicate of this bug. ***

Comment 76

bfoman (inactive)

2013-06-24 11:55:04 UTC

*** Bug 62253 has been marked as a duplicate of this bug. ***