Created attachment 55176 [details] Apple crash trace of corepolygui extension crash in calc How to reproduce : Mac OSX 10.6 Download and install the CorePoly GUI extension from : http://extensions.libreoffice.org/extension-center/improved-trend-lines/releases/1.0.1 Restart LibreOffice. Open a new Calc document. Navigate to Tools > Add-ons > Polynomial Regression Expected result : Extension Tool should start up Actual result : LibreOffice crashes Apple crash trace provided. Alex
Also tested on : 3.4.3 3.4.4 3.5-dev nightly build 3.6 own build from master The extension causes the first 3 versions to crash, as with 3.3.4, and my dev build to turn into a zombie soffice process, requiring forced kill. Alex
Please run LibreOffice from a text terminal using "soffice" command in [.../libreoffice3.4/program] catalog. Then try to run CorelPolyGUI and post obtained messages. You should obtain something like this: ================ dispatch: CorelPolyGUI: start startGUI: .name.mgplldz.corelpolygui.gui.GUI.startGUI(GUI.java:513) getLocaleStr: .name.mgplldz.corelpolygui.ooohelp.OfficeHelp.getLocaleStr(OfficeHelp.java:101) ..name.mgplldz.corelpolygui.gui.GUI.startGUI(GUI.java:516) getLocale: .name.mgplldz.corelpolygui.ooohelp.OfficeHelp.getLocale(OfficeHelp.java:79) ..name.mgplldz.corelpolygui.ooohelp.OfficeHelp.getLocaleStr(OfficeHelp.java:105) ... ... =============== Marcin
Might not help you much I'm afraid, but anyway : /Applications/LibO-dev.app/Contents/MacOS/soffice dispatch: CorelPolyGUI: start 2012-01-06 10:34:48.182 soffice[18788:903] Apple AWT Java VM was loaded on first thread -- can't start AWT. terminate called after throwing an instance of 'com::sun::star::uno::RuntimeException' Abort trap This looks like the age old Java VM instantiation/management on Mac with OOo/LibO problem to me, I don't think that a cure has been found for it yet. Look up other LibO/Mac/Java bugs in bugzilla, you'll probably find a few discussions about it. Alex
More info : http://www.oooforum.org/forum/viewtopic.phtml?t=76330 Alex
Does this error still persists?? Pleae update to a higher LibO Version. Change status to NEW after leaving a comment.
(In reply to comment #5) > Does this error still persists?? > Pleae update to a higher LibO Version. > Change status to NEW after leaving a comment. Florian, Please re-read Comment 1 where I mention that I tested it against the master build (3.6 alpha). Alex
Hi Alex, is that still persists on latest stable release? Have you tried last update of the extension?
(In reply to comment #7) > Hi Alex, is that still persists on latest stable release? Have you tried > last update of the extension? Hi, Yes, unfortunately, the problem is still present. The app goes into spinning beachball mode and I have to force kill it to regain control. Tested with CorePolyGUI 1.4.5 Alex
Tested on LO 4.0.3.3
On LO 4.2.0 alpha master build from source, the extension will not install : (com.sun.star.uno.RuntimeException) { { Message = "javaloader error - no mapping from java to C++ ", Context = (com.sun.star.uno.XInterface) @0 } } Alex
Running CorePoly from within gdb with LO 4.0.3.3 : 2013-07-08 17:41:34.790 soffice[18326:f0b] Apple AWT Java VM was loaded on first thread -- can't start AWT. libc++abi.dylib: terminate called throwing an exception Program received signal SIGABRT, Aborted. 0x958c5a6a in __pthread_kill () 0x958c5a6a in __pthread_kill () (gdb) backtrace full #0 0x958c5a6a in __pthread_kill () No symbol table info available. #1 0x9239eb2f in pthread_kill () No symbol table info available. #2 0x923d54ec in abort () No symbol table info available. #3 0x9a6607e0 in abort_message () No symbol table info available. #4 0x9a65e249 in default_terminate () No symbol table info available. #5 0x9a65e289 in safe_handler_caller () No symbol table info available. #6 0x9a65e2f1 in std::terminate () No symbol table info available. #7 0x9a65f3e6 in __cxa_throw () No symbol table info available. #8 0x03fd8d14 in gcc3::raiseException () No symbol table info available. #9 0x03fd68c5 in (anonymous namespace)::cpp2uno_call () No symbol table info available. #10 0x03fd6fa2 in cpp_vtable_call () No symbol table info available. #11 0x03fdf3e8 in privateSnippetExecutorVoid () No symbol table info available. #12 0x0f4ca79f in framework::MenuBarManager::Select () No symbol table info available. #13 0x01aaae12 in Menu::Select () No symbol table info available. #14 0x01aa5698 in Menu::ImplCallSelect () No symbol table info available. #15 0x01b2011f in ImplWindowFrameProc () No symbol table info available. #16 0x01b30933 in AquaSalInstance::Yield () No symbol table info available. #17 0x017cea40 in Application::Yield () No symbol table info available. #18 0x017ceb2c in Application::Execute () No symbol table info available. #19 0x00077cfd in desktop::Desktop::Main () No symbol table info available. #20 0x017d7308 in ImplSVMain () No symbol table info available. #21 0x01b2ff5b in AquaSalInstance::handleAppDefinedEvent () No symbol table info available. #22 0x01b6e54b in -[VCL_NSApplication sendEvent:] () No symbol table info available. #23 0x969e262c in -[NSApplication run] () No symbol table info available. #24 0x969855f6 in NSApplicationMain () No symbol table info available. #25 0x01b314f7 in ImplSVMainHook () No symbol table info available. #26 0x017d7371 in SVMain () No symbol table info available. #27 0x000a8bd5 in soffice_main () No symbol table info available. #28 0x00001f0e in main () No symbol table info available. #29 0x00001872 in _start () No symbol table info available. #30 0x00001799 in start () No symbol table info available.
With MacOs 10.9.4, testing last release of the extension (1.4.5) with 4.3 sources updated 2 weeks ago, I got this: * thread #29: tid = 0x42e74, 0x0000000128503ab3, name = 'Java: AWT-EventQueue-0', stop reason = signal SIGSEGV frame #0: 0x0000000128503ab3 -> 0x128503ab3: movl 0xc(%rdx), %r8d 0x128503ab7: movl 0xc(%r12,%r8,8), %ebx 0x128503abc: movl 0x10(%rsi), %r11d 0x128503ac0: movl 0xc(%r12,%r11,8), %ebp java version "1.8.0_11" Java(TM) SE Runtime Environment (build 1.8.0_11-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.11-b03, mixed mode) Stephan: I know that compatibility of the extension indicates 4.0 and perhaps jumbo4444 (the author of the extension may help) but perhaps you already encountered this kind of error and have some hints about this?
CorelPolyGUI 1.4.5 works well on Win 7 with master Version: 4.4.0.0.alpha0+ Build ID: 37b9ea92ba81d74764a2345a9c75c65bfd272d2b TinderBox: Win-x86@42, Branch:master, Time: 2014-08-26_09:37:01 I had more difficulties with Version: 4.3.2.0.0+ Build ID: 02bcf0d5abff100289d01c29eee2ed0685eb64ca TinderBox: Win-x86@42, Branch:libreoffice-4-3, Time: 2014-08-23_08:23:00 After a crash during install, restart, activate extension, restart, finally CorelPolyGUI works fine. Actually, from LibO 4.2, CorelPolyGUI is much less useful as forced intercept, polynomial and moving average trendlines are now included in LibO itself. There were always difficulties on Mac OS, but I have no Mac systems to test. You should use standalone version of CorelPolyGUI as indicated on extension page: http://extensions.libreoffice.org/extension-center/improved-trend-lines/releases/1.4.5/CorelPolyGUI_1-4-5_standalone.zip By the way, I'm not the author of this marvelous extension, but only one of the main QA tester. It is Marcin Gutman who coded it: standing ovation for him ;)
Tested on OSX 10.10.3 The latest version of the extension available from the download site still causes Version: 5.0.0.0.alpha1+ Build ID: 135755ed9e64d4208ef5b578c9b43ad23bb4ed66 Locale : fr-FR (fr.UTF-8) to enter an infinite loop, requiring forced kill. The solution of using the standalone Java jar indicated for download in comment 13 doesn't work - when you start up the GUI, it looks for an application directory containing the LO executable, however, no matter which directory you choose, it still fails to find an executable on next startup : - pointed to /Applications/LibreOffice.app : failed to find LO installation - pointed to /Applications/LibreOffice.app/Contents/MacOS : failed to find LO installation - pointed to /Applications/LibreOffice.app/Contents/bin : failed to find LO installation
It seems the extension tries to connect to something when installing. I noticed this console log: accepting pipe,name=28e53cd0eaf4f40229bbc87619bb53f1d69c04449fa1093a918cf73dda81bb2...connection established or perhaps I'm misinterpreting this? (pc Debian x86-64 with master sources updated today + extension version 1.4.5) Anyway, after about 20/30 seconds, it's ok whereas I thought first there was a hanging.
** 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.5 or 5.2.1 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-20160920
Testing currently blocked by bug 99784
Similar problem with the "VRTnetworkequipment 1.2.0" extension, still on MacOS 10.11, LO 5.0. The installation of the extension silently hangs the whole libreoffice. It works great on windows or linux, same LO release, same extension release.
(In reply to Gaétan RYCKEBOER from comment #18) > Similar problem with the "VRTnetworkequipment 1.2.0" extension, still on > MacOS 10.11, LO 5.0. > > The installation of the extension silently hangs the whole libreoffice. > That is probably unrelated to this particular bug report, and in fact relates more generally to bug 99784, which affects all OXT files.
Version 1.4.5 still crashes LibreOffice on installation : Version: 6.0.0.0.alpha0+ Build ID: 4bf3b4ee48c4e3556e257aa77940f68c13b05b54 CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group
lldb backtrace from the crashing thread : * thread #12, name = 'dp_gui_extensioncmdqueue', stop reason = signal SIGABRT * frame #0: 0x00007fff92fcfd42 libsystem_kernel.dylib`__pthread_kill + 10 frame #1: 0x00007fff930bd457 libsystem_pthread.dylib`pthread_kill + 90 frame #2: 0x00007fff92f35420 libsystem_c.dylib`abort + 129 frame #3: 0x0000000100407d3d libcomphelper.dylib`comphelper::GenericSolarMutex::doRelease(this=<unavailable>, bUnlockAll=<unavailable>) at solarmutex.cxx:0 frame #4: 0x000000010558af62 libvcllo.dylib`SalYieldMutex::doRelease(this=0x000000010c2368f0, bUnlockAll=true) at salinst.cxx:313 frame #5: 0x0000000105303d9e libvcllo.dylib`SolarMutexReleaser::SolarMutexReleaser(this=0x0000700009135588) at svapp.hxx:1479 frame #6: 0x00000001054f8953 libvcllo.dylib`vcl::SolarThreadExecutor::execute(this=0x000000010c3ed230) at threadex.cxx:58 frame #7: 0x000000018434c05a libdeploymentgui.dylib`vcl::solarthread::detail::GenericSolarThreadExecutor<std::__1::__bind<short (dp_gui::LicenseDialog::*)(), dp_gui::LicenseDialog*>, short>::exec(func=<unavailable>)(), dp_gui::LicenseDialog*> const&) at threadex.hxx:63 frame #8: 0x000000018434b166 libdeploymentgui.dylib`dp_gui::LicenseDialog::execute(this=<unavailable>) at license_dialog.cxx:294 frame #9: 0x00000001843193ca libdeploymentgui.dylib`dp_gui::ProgressCmdEnv::handle(this=0x0000000183e02420, xRequest=0x0000700009135810) at dp_gui_extensioncmdqueue.cxx:399 frame #10: 0x0000000100a5c9a1 libdeploymentmisclo.dylib`dp_misc::interactContinuation(request=0x0000700009135918, continuation=<unavailable>, xCmdEnv=<unavailable>, pcont=0x00007000091358b7, pabort=0x00007000091358b6) at dp_interact.cxx:112 frame #11: 0x00000001844edeec libdeployment.dylib`dp_registry::backend::bundle::(anonymous namespace)::BackendImpl::PackageImpl::checkLicense(this=0x0000000183eb8490, xCmdEnv=0x0000700009135a30, info=0x00007000091359a0, alreadyInstalled=false) at dp_package.cxx:664 frame #12: 0x00000001844eaa25 libdeployment.dylib`dp_registry::backend::bundle::(anonymous namespace)::BackendImpl::PackageImpl::checkPrerequisites(this=0x0000000183eb8490, (null)=<unavailable>, xCmdEnv=0x0000700009135a30, alreadyInstalled='\0') at dp_package.cxx:706 frame #13: 0x0000000184496b9c libdeployment.dylib`dp_manager::ExtensionManager::doChecksForAddExtension(this=0x0000000180291010, xPackageMgr=<unavailable>, properties=<unavailable>, xTmpExtension=0x0000700009135c58, xAbortChannel=0x0000700009135d20, xCmdEnv=0x0000700009135d00, out_existingExtension=<unavailable>) at dp_extensionmanager.cxx:574 frame #14: 0x00000001844979ea libdeployment.dylib`dp_manager::ExtensionManager::addExtension(this=0x0000000180291010, url=0x00000001841410a8, properties=0x0000700009135d08, repository=0x00000001841410b0, xAbortChannel=0x0000700009135d20, xCmdEnv=<unavailable>) at dp_extensionmanager.cxx:650 frame #15: 0x0000000184498c5a libdeployment.dylib`non-virtual thunk to dp_manager::ExtensionManager::addExtension(this=<unavailable>, url=<unavailable>, properties=<unavailable>, repository=<unavailable>, xAbortChannel=<unavailable>, xCmdEnv=0x0000700009135d00) at dp_extensionmanager.cxx:0 frame #16: 0x000000018431c3be libdeploymentgui.dylib`dp_gui::ExtensionCmdQueue::Thread::_addExtension(this=<unavailable>, rCmdEnv=0x0000700009135e48, rPackageURL=<unavailable>, rRepository=<unavailable>, bWarnUser=<unavailable>) at dp_gui_extensioncmdqueue.cxx:852 frame #17: 0x000000018431bd0e libdeploymentgui.dylib`dp_gui::ExtensionCmdQueue::Thread::execute(this=0x000000018413aa70) at dp_gui_extensioncmdqueue.cxx:731 frame #18: 0x000000010105e60b libuno_salhelpergcc3.dylib.3`salhelper::Thread::run(this=0x000000018413aa70) at thread.cxx:40 frame #19: 0x000000010105e77f libuno_salhelpergcc3.dylib.3`::threadFunc(param=0x000000018413aa70) at thread.hxx:185 frame #20: 0x00000001000c0aba libuno_sal.dylib.3`osl_thread_start_Impl(pData=0x000000018413b670) at thread.cxx:234 frame #21: 0x00007fff930ba93b libsystem_pthread.dylib`_pthread_body + 180 frame #22: 0x00007fff930ba887 libsystem_pthread.dylib`_pthread_start + 286 frame #23: 0x00007fff930ba08d libsystem_pthread.dylib`thread_start + 13
Not quite sure why, in frame 3 : frame #3: 0x0000000100407d3d libcomphelper.dylib`comphelper::GenericSolarMutex::doRelease(this=<unavailable>, bUnlockAll=<unavailable>) at solarmutex.cxx:0 this<> and bUnlockAll<> should be unavailable...
@Addin Jan-Marek and Michael to CC. Any ideas ? Does this by any chance have anything to do with the recent disabling of the mutex lock wrt the main thread ?
> solarmutex.cxx:0 Nice. As for most of my clean-ups, I have dropped a few workarounds and exchanged them for std::abort() calls, so instead of ignoring the problem and hoping for the best, LO quits / crashs. In this case we try to release the SolarMutex we don't own, which is forbidden AKA undefined. Either the Mutex is locked by an other thread, or not locked at all. If frame #3 had a valid line number, one would know which of these two is the problem here. My guess: somewhere in this BT we must grab the SolarMutex, so we can correctly release it. Since we're doing GUI stuff, we definitely need it.
(In reply to Alex Thurgood from comment #20) > Version 1.4.5 still crashes LibreOffice on installation : Do you have a working link to the extension? <http://extensions.libreoffice.org/extension-center/improved-trend-lines/releases/1.0.1> from comment 0 only leads to <https://extensions.libreoffice.org/extensions>, and searching there for "CorePoly" or "trendlines" turns up nothing.
(In reply to Stephan Bergmann from comment #25) > Do you have a working link to the extension? https://extensions.libreoffice.org/extensions/improved-trend-lines/1.4.5
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f5415276307603df6de364091435e81883ea10fb tdf#44497 run LicenseDialog with SolarMutex locked It will be available in 6.0.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.
*** Bug 112577 has been marked as a duplicate of this bug. ***
Well, it doesn't crash LO any more after Jan-Mareks' commit, but it fails to install with a java.lang.reflect.InvocationTargetException error message.
(In reply to Alex Thurgood from comment #29) > Well, it doesn't crash LO any more after Jan-Mareks' commit, but it fails to > install with a > > > java.lang.reflect.InvocationTargetException > > > error message. So, after trying to install it again, it does actually register as an extension in the list of extensions, but the extension is disabled. Attempting to enable the extension with the appropriate "Enable" button in the Extensions Manager GUI, brings up the java.lang.reflect.InvocationTargetException error message again and the extension is not enabled, despite a message from LO informing the user to restart the application.
Now working in master alpha 6.0 with Java 9 JDK using an added parameter in the Java setup to include the xml.bind module
I'm having no luck installing the standalone version on macOS 10.13.6. Here are my exact steps: 1) Download CorelPolyGUI_1-4-5_standalone.zip and unarchive it 2) In the resulting CorelPolyGUI_1-4-5_standalone folder double-click the CorelPolyGUIOffice.jar file 3) The jar launcher tries to open it but shortly produces the message "The Java JAR file "CorelPolyGUIOffice.jar" could not be launched". I'm advised to check the Java console for possible error messages but so far I haven't found a way to display the console (In the Java Control Panel, I have checked the "Show Console" option but have never seen it appear). When I try to launch the file in Terminal with: java -jar /Users/uname/Downloads/CorelPolyGUI_1-4-5_standalone/CorelPolyGUIOffice.jar I get the message: no main manifest attribute, in /Users/uname/Downloads/CorelPolyGUI_1-4-5_standalone/CorelPolyGUIOffice.jar
(In reply to Rob Lewis from comment #32) > I'm having no luck installing the standalone version on macOS 10.13.6. Here > are my exact steps: > > 1) Download CorelPolyGUI_1-4-5_standalone.zip and unarchive it Via the <https://extensions.libreoffice.org/extensions/improved-trend-lines/1.4.5/@@download/file1/CorelPolyGUI_1-4-5_standalone.zip> "CorelPolyGUI_1.4.5.oxt" link at <https://extensions.libreoffice.org/extensions/improved-trend-lines>? Please contact the author of that extension about the purpose of that "standalone" zip file and how to use it.