Problem description: I installed the beta. I opened a writer document. Everything seemed OK. I wished to display the "about" dialog box and... bye libreoffice... everything dissapeared. After that, executing any l4dev application crashed at startup. Renaming the user profile in .config/libreoffice to .config/old_libreoffice didn't solve the issue. In fact, it doesn't get to the point of writing a new profile. Logging in as a different user, it opened writer well (empty document). I typed two "O" characters... it wrote the first one and, then, before showing the second character on screen, again, libreoffice was lost forever. Current behavior: Crash when showing libreoffice startup splash. Expected behavior: Operating System: Ubuntu Last worked in: 3.6.4.3 release
I believe this is fixed for beta2 - we were missing some SVG loading goodness there. Thanks for the report - it'd be great to verify that in b2.
I had the same crash with beta 1, but in daily build from December 20th it is fixed. Thank you!
I just installed beta2 and the problem seems not being solved. LO4.0beta2 is unusable in my system: again, after typing 2+2 in writer, LO beta2 crashed and never went past the splash screen again. ubuntu 12.10 64 bit fully updated as of today, with Spanish, Catalan and English locales installed.
Ubuntu apport (whoopsie) gave me some info in /var/crash in the format in https://wiki.ubuntu.com/Apport Maybe the call stack might prove useful. As the crash files include core dumps, etc. they are too large for this bug system to swallow. I left it in https://dl.dropbox.com/u/2981119/bugsLoDev4/_opt_lodev4.0_program_soffice.bin.1004.crash.tar.gz
Combining the info Mattias gives (works from the 20th) and that the tag for beta2 was created on the 18th I think the goodness Michael says would be fixed in RC1. Please try again on RC1 or with a daily build. (http://dev-builds.libreoffice.org/daily/libreoffice-4-0/Linux-x86_64_11-Release-Configuration/2012-12-25_20.05.38/) Please let us know what the result is.
I confirm the issue is still present with night build 2012-12-26_23.55.49, installed from dev-builds.libreoffice.org. I also confirm this bug is a duplicate of bug 58092, which also refers to Ubuntu 12.10 x64 not able to start LO. As I am a non-developer novice and I don't know what consequences "duplicate" things have (and no activity has been present in 58092 bug since 2 weeks), I leave to libreoffice-bugs people taking the right actions. LO crashes both with and without the Spanish language pack installed.
*** Bug 58092 has been marked as a duplicate of this bug. ***
Created attachment 72192 [details] Backtraces (strace, gdbtrace) logs from Bug 58092 Backtrace matches apport crash file.
Created attachment 72193 [details] gdbtrace.log from Bug 58092 Matches apport crash log
I confirm I have seen nothing like this on Ubuntu 32bit with a variety of home built master, nightly build and beta testing in 32bit Ubu 10.04. Is not a BASIC language bug though it is a bug in the basic function of creating a LanguageTag (the very first?). So far crash is reported only for 64bit Ubuntu 12.10. Crash reported for all recent 64bit versions: both betas and in nightly build from master - not clear to me what is the correct report version value but dialed it back to beta 1 as the first released version. BT info from A.S. matches bt on Bug 58092 reported against beta1; Null pointer usage is in this context in all traces: #5 0x00007ffff5f1c66b in _lt_tag_parse () ... #6 0x00007ffff5f127ca in LanguageTag::canonicalize() const () ... #7 0x00007ffff5f135e0 in LanguageTag::LanguageTag(rtl::OUString const&, bool) () ... 5 through 7 inside /opt/lodev4.0/program/libi18nisolang1gcc3.so Changed component to Linguistic.
Concerning last remark by Lemoine Castle, I confirm that the 32bit Dec26 nightly build does NOT seem to be affected by this issue in a fully-updated Ubuntu 12.10 32bit machine. Both the failing 64bit one and the 32bit one have Spanish, English and Catalan locales installed.
I submitted the min fix patch to fix a compile error I was having on Ubu 10.04 with gcc-4.4.3 Compile time type resolution was failing inside a complex nested constructor call. It is possible that the errors here are from a similar compiler problem that doesn't error out at compile time, but writes junk and errors at run-time. A bit of a shot in the dark, but the BTs here go right through at least one of the patched lines.
Here is patch: https://gerrit.libreoffice.org/1531
LeMoyne Castle committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=252136551f2c032b62f9650a06389f2b4fe6e6c1 Paren fix for Ubu 10.04 build (and fdo#58417 ?) 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.
The bug is still present in daily build: libreoffice-4-0~2013-01-08_03.34.40_LibO-Dev_4.0.0.0.beta2_Linux_x86-64_install-deb_en-US.tar.gz Apport crash log for the latest version: https://dl.dropbox.com/u/2981119/bugsLoDev4/_opt_lodev4.0_program_soffice.bin.1002.crash.tar.gz I don't know if the master patch has made its way into LO 4.0 branch, but there is nothing in master for Linux-64 bit to test.
I am marking this as NEW as it at least was a problem. Once the patch is committed to nightly please mark as RESOLVED FIXED. @LeMoyne - should A.S. already have seen the fix in today's daily build?
For your info, I tested 4.0-rc1 and the bug is present there (expectedly, I guess, as it was in the night builds it was generated from). I wonder if it's only my machine which has three languages installed (I guess that this configuration is not so common). If it's a compiler-bug issue as Lemoyne suspects, maybe it's time to leave it on hold until ubuntu packagers compile it against with a different compiler version, libraries, etc.
Hi everyone, I downloaded the final stable release's (4.0.0.3) deb files and installed. The symptons are the same: LibreOffice loads, if I click on a menu item, or type some text the app crashes. If I re-launch it quits immediately after the splash screen. If I remove the libreoffice directory in ~/.config it loads again. I'm running Ubuntu 12.10 64 bit and have several languages installed.
I’m also having this issue. It’s caused by the presence of the file /usr/share/hunspell/de_DE_frami.dic (and similarly named ones) on my system. Here’s what happens: in lingucomponent/source/lingutil/lingutil.cxx, GetOldStyleDics("DICT") attempts to load dictionaries from /usr/share/hunspell. It tries to sort them by language, using the LanguageTag class and its liblangtag backend. It also tries to be smart and turn the first '_' character of the dictionary filename into '-' if no '-' was present, in the hope of obtaining a locale string from which LanguageTag can derive a language identifier. In my case, however, this yields "de-DE_frami", which is not a valid locale. LanguageTag passes it to liblangtag, which tries to construct an error message ("Invalid character for tag: '%c'", '_') but segfaults in the process. I have not attempted to find out why liblangtag’s error handling fails, but at the core of the issue is the GetOldStyleDics code. Easy fix: after replacing the first '_' by '-' (if no '-' was present), if another '_' remains, delete it and any trailing text. I don’t have the hardware to compile and test a patch, unfortunately. By way of verification, I tried ‘mv /usr/share/hunspell /usr/share/hunspell-bck’ and LO started normally. When I moved the directory back, the crash occured again.
P.S. The following command works for me as a temporary fix: for i in /opt/libreoffice4.0/program/lib{lnth,spell,hyphen}lo.so ; do sed -i -e 's,/usr/share/hunspell,NONESUCHNONESUCHFOO,g' "$i" ; done
(In reply to comment #19) Confirmed (with variations). locale -a gives ... ca_ES.utf8 ca_ES.utf8@valencia ... and, indeed, I had in /usr/share/hunspell the offending files: ca_ES-valencia.aff ca_ES-valencia.dic Moving such files out of the hunspell folder made LO4.0 (release) work. So, I guess that the library does not segfault because of the remaining "_" character (or that there are two different causes for segfault) but because something happens interpreting ca-ES-valencia... From the stack traces, seems that lt_bool_t lt_tag_parse(lt_tag_t *tag, const char *tag_string, lt_error_t **error) does something strange (writing null vma) when fed with the wrong string from LanguageTag::canonicalize() . As I'm not a developer, I'm unable to tell anything more.
This workaround works for me as well! I moved the same ca_ES-valencia.aff ca_ES-valencia.dic files and now LO4 is working well. Thanks for the workaround!
LeMoyne Castle committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=31f2675c8f48c6e55c73e8e75bf9c7d3ac2874c7&h=libreoffice-4-0 Paren fix for Ubu 10.04 build (and fdo#58417 ?) It will be available in LibreOffice 4.0.2. 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.
LeMoyne Castle committed a patch related to this issue. It has been pushed to "libreoffice-4-0-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=75bd73e78fcb986ad47ab5309658489ddd521707&h=libreoffice-4-0-1 Paren fix for Ubu 10.04 build (and fdo#58417 ?) It will be available already in LibreOffice 4.0.1. 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.
caolanm->erack: there's a good bit of noise and conflicting bug reports bundled into this bug, but there's a general theme of liblangtag related bustage with parsing tags of... ca_ES-valencia and de_DE_frami.dic i.e. malformed bcp47
Thanks, I'll investigate.
I tried adding a temporary unit test for "ca_ES-valencia" additionally to the already existing "unreg-and-bad" in libreoffice-4-0-0 and libreoffice-4-0 (to-be 4.0.4 release) using internal liblangtag-0.4.0 but could not reproduce a failure. What version of liblangtag was used on failing Ubuntu? Is this reproducible with a recent 4.0.4 and ca_ES.utf8@valencia locale and ca_ES-valencia hunspell installed?
I just ditched my old machine and, in a new one, I installed 4.0.4 (from ppa) and ubuntu 13.10. I couldn't reproduce the bug so maybe it has been corrected in the interim.
dragging on too long, seems to have gone away as far as we can tell