Upon selection of either open/save LibreOffice quits immediately. OSX Yosemite.
Although ooo2gd is an extension, the program should be handling the potential problem (not crashing), thus my rationale for submitting it under the main program rather than 'extensions.'
Until it has been confirmed I ahve reset this to medium normal. ooo2gd is an extension installed optionally by the user (i.e. it is not bundled with LibreOffice). I doubt that this can ever be considered to be of high critical status. It might also possibly be a regression, if it can be shown not to have crashed previous versions. As to whether this is the extension's fault or the app's fault, this still remains to be determined. The default in most cases is to blame the extension, which after all, is an add on to existing functionality. It is not up to LibreOffice to remain compatible with non-bundled extensions, this is squarely up to the developers of the extension. Changing component to extension.
I would add that the extensions site states that this extension has not been updated since 2011, and that it is only deemed compatible with 3.x versions of LibreOffice.
Confirming with Version: 4.4.2.2 Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6 Locale: fr_ and ooo2gd 3.0.0 downloaded from the extensions website Apple crash trace attached
Created attachment 114584 [details] Apple crashtrace
I can't see that this extension particularly works on 3.3.0.4 (although perhaps I just didn't figure out how to configure it properly), but on the other hand it doesn't crash either, so let's call this a regression -> Keywords: regression
(In reply to Alex Thurgood from comment #4) > ooo2gd 3.0.0 downloaded from the extensions website <http://extensions.libreoffice.org/extension-center/openoffice.org2googledocs-export-import-to-google-docs-zoho-webdav/releases/3.0.0/ooo2gd_3.0.0.oxt>
(In reply to paulkubed from comment #0) > Upon selection of either open/save LibreOffice quits immediately. OSX > Yosemite. I assume with "open/save" you mean entries like "Export to Google Docs" and "Import from Google Docs" in the extension's toolbar, not the stock "File - Open..." or "File - Save" menu entries.
What I see on stderr is > 2015-06-17 11:34:25.715 soffice[65431:120838] JavaNativeFoundation: GetGlobalVM: JNI_GetCreatedJavaVMs() failed to get any VM. > 2015-06-17 11:34:25.720 soffice[65431:120838] Apple AWT Internal Exception: Unable to obtain JNIEnv for context: 0x0 > 2015-06-17 11:34:25.720 soffice[65431:120838] *** Terminating app due to uncaught exception 'Unable to obtain JNIEnv', reason: 'Unable to obtain JNIEnv for context: 0x0' when the extension is trying to display an "Import from Google Docs" dialog via Java AWT/Swing. A Java-on-Mac-OS-X-specific issue similar to <https://bz.apache.org/ooo/show_bug.cgi?id=92926> "Java AWT doesn't work (can't start)" perhaps, but hard to debug without the source code of the extension.
@sberg: The source code of ooo2gd is at https://code.google.com/p/ooo2gd/source/list. If you want to do your own build, it might be easier to use ooo2gd package from Fedora (I hope it still builds--it was retired some time ago).
Migrating Whiteboard tags to Keywords: (notBibisectable)
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
On pc Debian x86-64 with master sources updated today, I got an assert when trying to install: #3 0x00007ffff7b0f102 in __GI___assert_fail (assertion=0x7fffe73cd37d "false", file=0x7fffe73cd078 "/home/julien/lo/libreoffice/configmgr/source/access.cxx", line=1902, function=0x7fffe73d8200 <configmgr::Access::initBroadcasterAndChanges(configmgr::Modifications::Node const&, configmgr::Broadcaster*, std::__debug::vector<com::sun::star::util::ElementChange, std::allocator<com::sun::star::util::ElementChange> >*)::__PRETTY_FUNCTION__> "void configmgr::Access::initBroadcasterAndChanges(const configmgr::Modifications::Node&, configmgr::Broadcaster*, std::__debug::vector<com::sun::star::util::ElementChange>*)") at assert.c:101 #4 0x00007fffe7305126 in configmgr::Access::initBroadcasterAndChanges(configmgr::Modifications::Node const&, configmgr::Broadcaster*, std::__debug::vector<com::sun::star::util::ElementChange, std::allocator<com::sun::star::util::ElementChange> >*) (this=0x555557752b10, modifications=..., broadcaster=0x7fff2510b810, allChanges=0x0) at /home/julien/lo/libreoffice/configmgr/source/access.cxx:1902 #5 0x00007fffe7382217 in configmgr::RootAccess::initBroadcaster(configmgr::Modifications::Node const&, configmgr::Broadcaster*) (this=0x555557752b10, modifications=..., broadcaster=0x7fff2510b810) at /home/julien/lo/libreoffice/configmgr/source/rootaccess.cxx:76 #6 0x00007fffe734ca3b in configmgr::Components::initGlobalBroadcaster(configmgr::Modifications const&, rtl::Reference<configmgr::RootAccess> const&, configmgr::Broadcaster*) (this=0x7fffe74730a0 <configmgr::Components::getSingleton(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&)::singleton>, modifications=..., exclude=empty rtl::Reference, broadcaster=0x7fff2510b810) at /home/julien/lo/libreoffice/configmgr/source/components.cxx:261 #7 0x00007fffe7388e6b in configmgr::update::(anonymous namespace)::Service::insertExtensionXcuFile(sal_Bool, rtl::OUString const&) (this=0x55555b65d2a0, shared=0 '\000', fileUri="file:///home/julien/lo/libreoffice/instdir/program/../program/../user/uno_packages/cache/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lucky2lo.tmp/Addons.xcu") at /home/julien/lo/libreoffice/configmgr/source/update.cxx:104 #8 0x00007fffe1f3944d in dp_registry::backend::configuration::(anonymous namespace)::BackendImpl::PackageImpl::processPackage_(osl::ResettableMutexGuard&, bool, bool, rtl::Reference<dp_misc::AbortChannel> const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&) (this=0x55555c95aba0, doRegisterPackage=true, startup=false, xCmdEnv=empty uno::Reference) at /home/julien/lo/libreoffice/desktop/source/deployment/registry/configuration/dp_configuration.cxx:721 #9 0x00007fffe1f4322f in dp_registry::backend::Package::processPackage_impl(bool, bool, com::sun::star::uno::Reference<com::sun::star::task::XAbortChannel> const&, com::sun::star::uno::Reference<com::sun::star::ucb::XCommandEnvironment> const&) (this=0x55555c95aba0, doRegisterPackage=true, startup=false, xAbortChannel=uno::Reference to (class dp_misc::AbortChannel *) 0x55555c963888, xCmdEnv=empty uno::Reference) at /home/julien/lo/libreoffice/desktop/source/deployment/registry/dp_backend.cxx:635 If I disable the assert, I can install the extension. I could click on any of the 5 icons, no crash, I got a Java style dialog. I noticed these logs on console: warn:configmgr:317:317:configmgr/source/xcuparser.cxx:159: bad set node <prop> member in "file:///home/julien/lo/libreoffice/instdir/program/../program/../user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lucle3c1.tmp/Addons.xcu" warn:configmgr:317:317:configmgr/source/xcuparser.cxx:159: bad set node <prop> member in "file:///home/julien/lo/libreoffice/instdir/program/../program/../user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/lucle3c1.tmp/Addons.xcu" Any update?
(In reply to Julien Nabet from comment #13) > On pc Debian x86-64 with master sources updated today, I got an assert when > trying to install: Please give a link to the exact extension version you tried to install.
(In reply to Stephan Bergmann from comment #14) > ... > Please give a link to the exact extension version you tried to install. https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/ooo2gd/ooo2gd_3.0.0.oxt
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/5a522a0196aaa071bd3ac59b3088246e3fe98f34%5E%21 Related tdf#90429: Don't erroneously pop unrelated path segments It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
(In reply to Julien Nabet from comment #13) > On pc Debian x86-64 with master sources updated today, I got an assert when > trying to install: that should be fixed with the commit from comment 16
(In reply to Stephan Bergmann from comment #17) > (In reply to Julien Nabet from comment #13) > > On pc Debian x86-64 with master sources updated today, I got an assert when > > trying to install: > > that should be fixed with the commit from comment 16 Indeed, I don't reproduce the assertion with master sources updated today. Thank you! :-) There are still these logs on console: warn:io.connector:20223:20286:io/source/connector/connector.cxx:93: Connector : couldn't connect to pipe 8a2dc8e6e63bcca36ccb11abe577cf116b43ca92c231dfdaf54461efb35679(10) > accepting pipe,name=8a2dc8e6e63bcca36ccb11abe577cf116b43ca92c231dfdaf54461efb35679...connection established.warn:configmgr:20223:20286:configmgr/source/xcuparser.cxx:159: bad set node <prop> member in "file:///home/julien/lo/libreoffice/instdir/program/../program/../user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/ludtzanc.tmp/Addons.xcu" warn:configmgr:20223:20286:configmgr/source/xcuparser.cxx:159: bad set node <prop> member in "file:///home/julien/lo/libreoffice/instdir/program/../program/../user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/ludtzanc.tmp/Addons.xcu" but I suppose we could expect this since there are wrong paths in the oxt (if I well understood the comment of your commit)
(In reply to Julien Nabet from comment #18) > > accepting pipe,name=8a2dc8e6e63bcca36ccb11abe577cf116b43ca92c231dfdaf54461efb35679...connection established.warn:configmgr:20223:20286:configmgr/source/xcuparser.cxx:159: bad set node <prop> member in "file:///home/julien/lo/libreoffice/instdir/program/../program/../user/extensions/shared/registry/com.sun.star.comp.deployment.configuration.PackageRegistryBackend/ludtzanc.tmp/Addons.xcu" > warn:configmgr:20223:20286:configmgr/source/xcuparser.cxx:159: bad set node > <prop> member in > "file:///home/julien/lo/libreoffice/instdir/program/../program/../user/ > extensions/shared/registry/com.sun.star.comp.deployment.configuration. > PackageRegistryBackend/ludtzanc.tmp/Addons.xcu" > > but I suppose we could expect this since there are wrong paths in the oxt > (if I well understood the comment of your commit) Yes, ooo2gd_3.0.0.oxt from comment 15 contains an Addons.xcu with bad content.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/4c690773521517da8d9512ef1390284b59afd593 Related tdf#90429: Don't erroneously pop unrelated path segments It will be available in 6.3.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Let's put this one to FIXED since the patch has been backported in 6.3 branch
(In reply to Julien Nabet from comment #21) > Let's put this one to FIXED since the patch has been backported in 6.3 branch While my "Related tdf#90429: Don't erroneously pop unrelated path segments" fix (comment 16, comment 20) fixes the issue from comment 13, I assume it does not fix the original issue from comment 0?
(In reply to Stephan Bergmann from comment #22) > (In reply to Julien Nabet from comment #21) > > Let's put this one to FIXED since the patch has been backported in 6.3 branch > > While my "Related tdf#90429: Don't erroneously pop unrelated path segments" > fix (comment 16, comment 20) fixes the issue from comment 13, I assume it > does not fix the original issue from comment 0? Let's revert status then.
This no longer installs, I get the error: Connector : couldn't connect to pipe 31c4238691d8e475aa2d778de61c37a118bff5f835249e55aa68a38e32d5b2(10) The extension is unmaintained and there are reports of it not installing on the original github too, so I'm going to close this as not our bug as the issue in comment #0 is no longer applicable