Bug 44497 - Extension CorePolyGUI causes Calc to crash when clicked on via Addons menu OSX
Summary: Extension CorePolyGUI causes Calc to crash when clicked on via Addons menu OSX
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Extensions (show other bugs)
Version:
(earliest affected)
3.3.4 release
Hardware: x86-64 (AMD64) Mac OS X (All)
: medium normal
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: target:6.0.0
Keywords:
: 112577 (view as bug list)
Depends on: 99784
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-05 08:24 UTC by Alex Thurgood
Modified: 2017-10-05 08:18 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
Apple crash trace of corepolygui extension crash in calc (52.65 KB, text/plain)
2012-01-05 08:24 UTC, Alex Thurgood
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2012-01-05 08:24:25 UTC
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
Comment 1 Alex Thurgood 2012-01-05 08:56:29 UTC
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
Comment 2 Marcin Gutman 2012-01-05 19:25:25 UTC
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
Comment 3 Alex Thurgood 2012-01-06 01:44:49 UTC
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
Comment 4 Alex Thurgood 2012-01-06 01:51:36 UTC
More info :

http://www.oooforum.org/forum/viewtopic.phtml?t=76330


Alex
Comment 5 Florian Reisinger 2012-03-25 07:27:22 UTC
Does this error still persists??
Pleae update to a higher LibO Version.
Change status to NEW after leaving a comment.
Comment 6 Alex Thurgood 2012-03-30 00:23:12 UTC
(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
Comment 7 ign_christian 2013-07-02 08:05:00 UTC
Hi Alex, is that still persists on latest stable release? Have you tried last update of the extension?
Comment 8 Alex Thurgood 2013-07-08 15:36:56 UTC
(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
Comment 9 Alex Thurgood 2013-07-08 15:37:23 UTC
Tested on LO 4.0.3.3
Comment 10 Alex Thurgood 2013-07-08 15:39:34 UTC
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
Comment 11 Alex Thurgood 2013-07-08 15:43:29 UTC
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.
Comment 12 Julien Nabet 2014-09-01 19:51:58 UTC
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?
Comment 13 Laurent BP 2014-09-02 11:52:50 UTC
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 ;)
Comment 14 Alex Thurgood 2015-05-15 12:26:31 UTC
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
Comment 15 Julien Nabet 2015-05-15 20:21:31 UTC
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.
Comment 16 QA Administrators 2016-09-20 09:42:41 UTC Comment hidden (obsolete)
Comment 17 Alex Thurgood 2016-09-21 10:47:33 UTC
Testing currently blocked by bug 99784
Comment 18 Gaétan RYCKEBOER 2016-10-04 09:03:26 UTC
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.
Comment 19 Alex Thurgood 2016-10-04 14:55:19 UTC
(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.
Comment 20 Alex Thurgood 2017-09-28 09:45:18 UTC
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
Comment 21 Alex Thurgood 2017-09-28 09:58:45 UTC
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
Comment 22 Alex Thurgood 2017-09-28 10:02:18 UTC
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...
Comment 23 Alex Thurgood 2017-09-28 10:04:07 UTC
@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 ?
Comment 24 Jan-Marek Glogowski 2017-09-28 17:34:30 UTC
> 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.
Comment 25 Stephan Bergmann 2017-09-28 18:08:11 UTC
(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.
Comment 26 Laurent BP 2017-09-28 19:41:08 UTC
(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
Comment 27 Commit Notification 2017-10-02 06:08:01 UTC
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.
Comment 28 Telesto 2017-10-03 18:52:28 UTC
*** Bug 112577 has been marked as a duplicate of this bug. ***
Comment 29 Alex Thurgood 2017-10-05 07:57:50 UTC
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.
Comment 30 Alex Thurgood 2017-10-05 08:18:27 UTC
(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.