Actions to reproduce Launch LibreOffice On the start frame, click on File -> Menu Expected behavior : Open dialog shows up Result in startframe : Customize dialog shows up Results in applications : Calc : Show/hide draw toolbar Writer : Show/hide bullets toolsbar Impress/Draw : Show/hide alignement toolbar Base : Show/Hide report toolbar Git revision : f4710e167ded0e6a378f1bfb01ef842b726b0aac
Same thing on other iterms
Confirmed on master for me with Build ID: 79bed99d078d3fcc7445a150a70fc085fdcf3d67 Same problem on branch 4.1 (4.1.3.0.0+) but the bug is more recent that this commit : https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=d4d60f0abadf048ae203914f5b4e8b828ff76f16 Best regards. JBF
That bug seems to only appears on Unity.
It seems there is a problem with dev-install in case of we build under Ubuntu/Unity. If I launch LO from .../install/program/soffice I get the faulty behavior. But if I generate the debs and install my build as a release version, it works as expected. I tested various stages of 4.1 branch with the same behavior: bump product version to 4.1.2.0.0+ : https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=57de36c208a2a745bd40fad452d7a62871829d71 bump product version to 4.1.3.0.0+ : https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=bdcb0c43c72b0e682612c88cdc0796f921c7f67d https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=d4d60f0abadf048ae203914f5b4e8b828ff76f16 Best regards. JBF
Yep, there seems to be some voodoo in unity depending on the location/name of the binary. It makes me a bit nervous, that I dont know _which_ magic. Maybe file a bug against unity in launchpad to find out (I dont think it will get priority to be fixed quickly, but maybe we can fix/workaround it).
So I should fill a bug like use scientist technology in Unity, not voodoo technology ?
Because it happen in "dev" version, I don't think it's really important
*** Bug 81861 has been marked as a duplicate of this bug. ***
The problem lies in GtkSalMenu::GetMenuForItemCommand() In short, it's a bad idea to gchar* blah = (gchar*) OUStringToOstring(......).getStr() because the anonymous OString is destructed immediately, before the extracted gchar* can be used The reason this only shows up in a development build is because you end up with G_SLICE=always-malloc MALLOC_PERTURB_=<n> set in the "ooenv" script, which is enough to tickle the bug in a way that doesn't happen in a release build
Matthew J. Francis committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=7fc08970894aea2b771bf7be409b72845c96d10a fdo#69090 Avoid using a string after free 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.
Beautiful work Matthew! The menus are working now with Ubuntu 14.4. Thanks for fixing this.