Actions to reproduce
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 (220.127.116.11.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 18.104.22.168.0+ : https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=57de36c208a2a745bd40fad452d7a62871829d71
bump product version to 22.214.171.124.0+ : https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=bdcb0c43c72b0e682612c88cdc0796f921c7f67d
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
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":
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:
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.