Bug 36495

I cannot reproduce the crash here - update works fine for me.

Can you please verify with Beta4 if the crash still happens for you?

If yes: did you install any additional extensiosn od did you have an OOo installed on the same machine with installed extensions?

In reply to André Schnabel:
When 3.3 Final release came out problem ceased.
However 3.4Beta3 and 3.4Beta4 are once again showing same behaviour. I reported problems on installation with the rebasegui.exe file given the bug number 36679 for beta 3 and problem has persisted with beta 4.
Whether or not the virus detected is a false positive is probably not resolved finally but it does seem that rebasegui.exe has given rise to some problems over the years. 
In my updated  comments submitted earlier today I note that Extension Manager Update does not crash LibO if the file is replaced by the version in the last stable release (3.3), although giving an error message without LibO crashing..
OOo is no longer installed on the PC I am using for this, but there could be some stray entries somewhere.

Created attachment 46517 [details]
Error massage during update

I'm using LO 3.4 Beta4 on Win7 SP1 32bit German

I start the extension manager, choose Update.
For the extension "OOOP-templates-unified-de-2.6" from OxygenOfficeProfessional, I get an error "link does not exist", after confirming this massage and marking the checkbox "Show all updates" the system "silently closes".

This behaviour is reproduceable.

Hi all,

I get the same error message as attached to the bug after installing OOOP-accessories-2.8.0.0.

This indicates that LibO can not find, or parse, the required XML. It may therefore be that the extension is wrongly packaged with regard to the new extension framework developed for 3.3.x.


I can also confirm the crash. I am enclosing an Apple stacktrace.

The app crashes here by the looks of it :

Thread 0 Crashed:  Dispatch queue: com.apple.main-thread
0   libdeploymentmiscmxi.dylib    	0x003a6d95 dp_misc::DescriptionInfoset::DescriptionInfoset(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, com::sun::star::uno::Reference<com::sun::star::xml::dom::XNode> const&) + 21

I must add, however, that the crash appears to be specific to this extension. I tried with the mysql connector extension, for example, with an old version, that was then suggested to be updated by the extensions manager, and it worked fine. This OOOP extension is the only one so far that caused LibO to die.

The title of the bug ought to be changed to reflect that, unless there are other extensions which cause the same behaviour.

Alex

Created attachment 46521 [details]
Apple crash stack trace for OOOP extension caused crash

This is Kami's stuff as far as I can recall.


Alex

Created attachment 46556 [details]
simple extension to crash LibO on update

the crash happens everytime, when the update URL is not accessible. 

So we are at risk to crash anytime the extension website has a timout or user is just behind a firewall.

As testcase you may use the very simple crash_me.oxt.

- download and install crash_me.oxt
- close and restart LibreOffice 3.4
- go to extension manager and check for updates
- click away the error message
- click "show all updates"
- wait 2 seconds

-> crash

LibO 3.3 correctly displays a warning for the extension and that there was an unkown error with it. LibO 3.3 did *not* crash.

Changing title again to reflect the circumstances

Alex

blocker for 35673 ?

Alex

One more reason to remove this extension update stuff from LibreOffice?

Wow; it is late to notice this - and yes it should have been proposed as a 'most annoying bug' long ago - to get some more visibility; thanks for the report !

Reproduced, debugging this now.

Isn't the title of this bug misleading, if it is only when checking the "show all updates" box that the crash happens... (It was quite hard to even find that box, at first I thought I couldn't reproduce the problem...)

(In reply to comment #15)
> Isn't the title of this bug misleading, if it is only when checking the "show
> all updates" box that the crash happens... (It was quite hard to even find that
> box, at first I thought I couldn't reproduce the problem...)

Well it defines both the problem and the circumstance under which the problem occurs in nearly a single line of verbiage ;-) maybe I ought to start honing my Perl mongering skills ;-)) but feel free to change to something you think is more relevant.


Alex

Stack at crash:

deploymentguimi.uno.dll!std::vector<dp_gui::UpdateDialog::DisabledUpdate,std::allocator<dp_gui::UpdateDialog::DisabledUpdate> >::operator[](unsigned int _Pos=0x00000000)  Line 785	C++
 	deploymentguimi.uno.dll!dp_gui::UpdateDialog::selectionHandler(void * __formal=0x066df468)  Line 1266 + 0x13 bytes	C++
 	deploymentguimi.uno.dll!dp_gui::UpdateDialog::LinkStubselectionHandler(void * pThis=0x066defa8, void * pCaller=0x066df468)  Line 1238 + 0xf bytes	C++


The line in dp_gui_updatedialog.cxx:

bInserted = showDescription( m_disabledUpdates[pos].aUpdateInfo );

and m_disabledUpdates is invalid, null or whatever the right term is, at least the MSVS debugger displays its value as [0x00000000](). Or does that just mean m_disabledUpdates (a std::vector) is empty?

Created attachment 46950 [details] [review]
Suggested patch

This seems to help.

Patch pushed to master, -3-4 and -3-4-0.