All soffice suite seems runnung ok, except the Calc application. When select any option, it crashes with the next kernel message: Jul 26 19:43:06 mypc kernel: [ 8078.894978] soffice.bin[30133]: segfault at 51 ip 00007f85d6547060 sp 00007fff671b4c68 error 4 in libuno_sal.so.3[7f85d6516000+4e000] This ocurrs selecting ANY option, even the option selected by default. Clicking over with the mouse or using the alt-letter for selecting. *** BUT, if I select [Next] button, no errors ocurrs and I can create new database. Only I can create, because if I need change with mouse, key cursors, etc, it crashes. ----------------------------------------------------------------- Linux mypc 3.10.1-gentoo #5 SMP Mon Jul 22 09:10:18 CEST 2013 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux ================================================================= Package Settings ================================================================= app-office/libreoffice-4.1.0.4 was built with the following: USE="branding cups dbus gtk mysql opengl postgres vba webdav (-aqua) -bluetooth -debug -eds -gnome -gstreamer -gtk3 -java -jemalloc -kde -odk -telepathy -test" LIBREOFFICE_EXTENSIONS="presenter-minimizer -nlpsolver -scripting-beanshell -scripting-javascript -wiki-publisher" PYTHON_SINGLE_TARGET="python2_7 -python3_3" PYTHON_TARGETS="python2_7 -python3_3"
SORRY, is not Calc, is BASE.
did you install any extension? does it crash even when you create a brand new file with hsqldb? Just to be sure it's not a problem with your profile, could you rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile) and give it a new try?
I did not remember to say it. Checked with absolutely new profile and the problem is the same. No extensions, except the mentioned in the USE variable.
GCC: gcc (Gentoo 4.7.3 p1.0, pie-0.5.5) 4.7.3 Copyright (C) 2012 Free Software Foundation, Inc. Esto es software libre; vea el código para las condiciones de copia. NO hay garantía; ni siquiera para MERCANTIBILIDAD o IDONEIDAD PARA UN PROPÓSITO EN PARTICULAR ------------- EXTENSIONS: The Libreoffice extension installed is the Presenter minimizer. I've prepared the PDF Import, but does not exist on this ebuild. List of the variables and extensions used (with the '+'): -bluetooth +branding +cups +dbus -debug -eds -gnome -gstreamer +gtk -gtk3 -java -jemalloc -kde -libreoffice_extensions_nlpsolver +libreoffice_extensions_presenter-minimizer -libreoffice_extensions_scripting-beanshell -libreoffice_extensions_scripting-javascript -libreoffice_extensions_wiki-publisher +mysql -odk +opengl +postgres +python_single_target_python2_7 -python_single_target_python3_3 +python_targets_python2_7 -python_targets_python3_3 -telepathy -test +vba
Toni: thank you for the feedback. Would it be possible you retrieve a backtrace by following this link? https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU.2FLinux:_How_to_get_a_backtrace
(In reply to comment #5) > Toni: thank you for the feedback. Would it be possible you retrieve a > backtrace by following this link? > https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#GNU. > 2FLinux:_How_to_get_a_backtrace Ok, I will recompile ALL Libreoffice... nnoooooo!! The 'debug' option is not selected (mía culpa), and the backtrace is not in use. We will wait for 15-20 minutes... :(
Toni: you can retrieve a bt without symbol at first. Perhaps it could be sufficient.
Sorry Julien, if I run the command "soffice --backtrace", it respond: "Error: Can't find the tool "gdb", --backtrace option will be ignored." I check with strace, but the error is the same.
Please wait 30 minutes more. I put the USE on a libreoffice-bin line, and recompile Libreoffice without it... I cannot believe it.
You need to install gdb, I found this link: http://packages.gentoo.org/package/sys-devel/gdb
I'm looking for gbd and dbg, but not for gdb (is because i don't found it and don't install it). I am remembering my mother...
Toni, I cannot tell exactly what you did to provoke the segfault. What kind of database connection? To what backend? What window were you on? What option did you take? I have a build of of master with debug symbols (and in just a few hours I should have a recent build with debug symbols), and I would like to try get a backtrace. Terry.
Created attachment 83118 [details] Backtrace and debug The trace from soffice --backtrace. Running Libreoffice, then select Base and select the second option, "Open exist database". And now, with "+debug" compiled, it returns: warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "SunReportBuilder" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:312: unknown component "org.openoffice.Office.UI.DbReportWindowState" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:address:evolution:local" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:address:evolution:ldap" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:address:evolution:groupwise" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:embedded:hsqldb" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "jdbc:*" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "jdbc:oracle:thin:*" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:address:kab" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "UpdateCheckJob" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "SunReportBuilder" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_es.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:312: unknown component "org.openoffice.Office.UI.DbReportWindowState" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_es.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:address:evolution:local" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_es.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:address:evolution:ldap" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_es.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:address:evolution:groupwise" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_es.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:embedded:hsqldb" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_es.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "jdbc:*" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_es.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "jdbc:oracle:thin:*" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_es.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:address:kab" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_es.xcd" warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "UpdateCheckJob" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_es.xcd" Exited with code '139'
With kernel 3.8.13 and 3.10.3, the problem persist.
All the warnings, above all this one warn:configmgr:10906:1:configmgr/source/xcuparser.cxx:939: ignoring modify of unknown set member node "sdbc:embedded:hsqldb" in "file:///usr/lib64/libreoffice/program/../share/registry/res/registry_ca.xcd" are quite strange. I wonder if LO is well installed. Peter/Michael/Bjoern: I wonder if it could be a packaging Gentoo pb, any idea? I found this page http://packages.gentoo.org/package/app-office/libreoffice but I must say I don't understand how to interpret it (tilde/"+"/different versions)
Julien, sorry, I no said that this debug warning messages returns BEFORE crash application, when I run the application (soffice or lobase) and it start apparently normal. After, when I select any lobase option and crash it, the return line is only the last: "Exited with code '139'".
Tried to take a look, but cannot do anything: - no clear & detailed (click-by-click) reproduction instructions - no attached example file that causes the crash when opened (or does it crash before opening a file?) - unclear mix of "problem with 4.1.0.4" and "here is a console long and backtrace with master" (that is, with 4.2.0.alpha), where the console log contains warnings that are most probably specific to master. - attachment 83118 [details] is without symbols -> unusable Toni, since apparently you have a very fast computer that can compile LibreOffice in only a few dozens of minutes, if you could: 1) Write us exactly what to do to reproduce the problem. 2) Attach any necessary file to reproduce the problem. 3) Do a debug and symbols build of 4.1.0.4 and show the backtrace generated with *that*. it would be most helpful. Thanks in advance!
Lionel, the problem is that the application dissapears without track visible (at exception of backtrace said by Julien). Ok, I reproduce literally the problem. # emerge libreoffice (with the upper options) looking and compiling dependences, including libreoffice-l10n (I'm spanish ;))... (dependency graph attached on next message) $ soffice -> the console showing warning messages -> starting the main menu for select for Writer, Calc, Base, etc. I select the Database (Base) and it opens the lobase main window ASSISTANT (no more error messages on the console) with THREE options: 1. Create new database (selected by default with the option widget) 2. Open existant database 3. Connect to exist database (+-, is in spanish) Now, I can do 2 METHODS for continuing: A. Select my preferred option clicking over the widget. B. Clicking on the NEXT button. If select the A method: - The window dissapears - The console show "Exited with code '139'" in continuation of warning messages and exit to bash. If select the B method: - All seems to work. Like this: - The window change to configuring path for save the dBASE files. - I select, for example, my ~ - Window: "How to proceed after saving the database" - Clicking on any widget, the console shows: "warn:vcl.control:4367:1:vcl/source/control/button.cxx:2357: No new-style group set on radiobutton, using old-style digging around" ** BUT ** it doesn't dissapear and I can continue working normally. - Select "Yes, register the database" and "Open database for edit". - The lobase is opened and seems running ok. And no more.
Created attachment 83139 [details] Dependency graph
And please, tell me how can put symbols on the backtrace. Now I've no time for investigate, sorry...
Cannot reproduce with: - my own libreoffice-4-1 development tree (4.1.1.alpha), debug build - LibreOffice 4.1.0.4 TDF official build, amd64 (x86-64) debs I click on "Open an existing database file", on "Connect to an existing database". No crash. (In reply to comment #18) > Lionel, the problem is that the application dissapears without track visible > (at exception of backtrace said by Julien). The attached backtrace (attachment 83118 [details]) is not useful because not done on a build with symbols. Please enable symbols and regenerate a backtrace. > 1. Create new database (selected by default with the option widget) > 2. Open existant database > 3. Connect to exist database (+-, is in spanish) > A. Select my preferred option clicking over the widget. > - The window dissapears > - The console show "Exited with code '139'" in continuation of warning > messages and exit to bash. That's a segfault. If you run under gdb (and with the --norestore option), it will stop in gdb (instead of exiting the application) and you can get a backtrace from there. Use "bt full", not only "bt".
(In reply to comment #20) > And please, tell me how can put symbols on the backtrace. Now I've no time > for investigate, sorry... Pass --enable-debug or at least --enable-symbols to ./autogen.sh. Since you use emerge, you may have to keep the automated Gentoo-specific package build system from stripping the object files, or install a separate package named "libreoffice-dbg" or "libreoffice-debug" or "libreoffice-symbols" or something like that. Sorry, don't know about Gentoo-specific procedures around "don't strip the built objects / install the symbols from separate package".
Changing optimization level for test. Recompiling for 3rd or 4th time...
(In reply to comment #18) > > Now, I can do 2 METHODS for continuing: > > A. Select my preferred option clicking over the widget. And what, pray tell, is your preferred option? Please help us here. There are a lot of ways your system can be different from ours. Uncertainty about what you do to provoke the crash is a complicating factor that we do not need. Terry.
Just for info, just found this http://wiki.gentoo.org/wiki/LibreOffice and above all this: http://www.gentoo.org/proj/en/qa/backtraces.xml
(In reply to comment #24) > (In reply to comment #18) > > And what, pray tell, is your preferred option? > > Please help us here. There are a lot of ways your system can be > different from ours. Uncertainty about what you do to provoke the > crash is a complicating factor that we do not need. > > Terry. Yes, my preferred option in this point is, for example, "Open an existing database". I can only select Next, because like I said, the other method crash. I can going to File/Open for the same, but with this menu works ok.
Created attachment 83152 [details] Backtrace (gcc -O0) I don't know how to make debug with extra symbols. If this file is not good, I need an explanation. I'm not developer, sorry.
(In reply to comment #26) > Yes, my preferred option in this point is, for example, "Open an existing > database". I can only select Next, because like I said, the other method > crash. I can going to File/Open for the same, but with this menu works ok. So the Database Wizard unprotects the dropdown list of recently opened database files and unprotects the <Open> icon. What do you do then? And for the existing database file that you select ... What is the connection type? What is the backend database engine? Can you attach the file?
(In reply to comment #27) > Created attachment 83152 [details] > Backtrace (gcc -O0) > I don't know how to make debug with extra symbols. If this file is not good, > I need an explanation. I'm not developer, sorry. You need to compile with "-ggdb" option to gcc, and then read http://www.gentoo.org/proj/en/qa/backtraces.xml#doc_chap1_sect3 (section "Stripping") to see how to tell portage not to remove the information added by -ggdb (that is, the symbols that gdb needs to provide a meaningul backtrace). (In reply to comment #28) > (In reply to comment #26) >> Yes, my preferred option in this point is, for example, "Open an existing >> database". > So the Database Wizard unprotects the dropdown list of recently opened > database files and unprotects the <Open> icon. What do you do then? My understanding is that Toni gets a crash even before he can select a file or click the debug icon. My understanding is that the crash happens "as soon as" he clicks on the "Open an existing database" radio choice.
(In reply to comment #29) > My understanding is that Toni gets a crash even before he can select a file > or click the debug icon. My understanding is that the crash happens "as soon > as" he clicks on the "Open an existing database" radio choice. Yes, of course that is what he said. Silly me. FWIW, I ran LibreOffice under valgrind up to that point then exited the program. Nothing in the valgrind output jumps out at me. Terry,
Thanks Julien, Lionel and Terrence. Yesterday, I'm looking for the option to pass to the compiler, but here not show it nothing: http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html and I recompile LO without -ggdb. But option is here: http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gcc/Debugging-Options.html For this reason, yesterday I don't put this option. Now yes :) Since I have never needed it, I did not know it. Thanks. And now, rrrecompiling... Because the debugging, the 6 cores late 50 minutes. My god, is summer and my room is 10°C overheated by the PC...
I think this is caused by inferior setup i put into the ebuild. We use hsqldb as default so it needs java. As the user has -java it should simply crash because it didn't find the required java/hsqldb setup to load from. But thats only my suspect.
(In reply to comment #32) > I think this is caused by inferior setup i put into the ebuild. > > We use hsqldb as default so it needs java. As the user has -java it should > simply crash because it didn't find the required java/hsqldb setup to load > from. > > But thats only my suspect. Also note I still think it should not crash but rather tell user to pick from other db engine first. (especially if the guy has mysql and postgres both build).
(In reply to comment #32) > We use hsqldb as default so it needs java. As the user has -java it should > simply crash because it didn't find the required java/hsqldb setup to load > from. What is the effect of "-java" in ebuild? It passes "--without-java" to ./autogen.sh (or ./configure)?
Compiled with +debug, -O0 and -ggdb, the gdbtrace.log seems the same (only change the pid). What I'm wrong?
(In reply to comment #35) > Compiled with +debug, -O0 and -ggdb, the gdbtrace.log seems the same (only > change the pid). What I'm wrong? As you are using gentoo it strips out the debug symbols by default. You need to put something like FEATURES="splitdebug" into your make.conf http://www.gentoo.org/proj/en/qa/backtraces.xml Also you need to compile glibc with debug symbols. But first things first, try to compile it with java enabled, I am pretty sure the problem will go away.
IMHO, Base is almost unusable without java. It is pity that it does not show any useful message here. Anyway, I agree with Thomas that you should enable java if you want to get it working.
Thanks, Tomás. Now, I'm recompiling (for 500th time) with the splitdebug feature. Also, I restore to "-debug" USE option, because other procedures recommend disabling it (the debug is for other things and it will use with careful) (?). I'm continue using the -O0 for backtrace.
Ok, compiling with java. If this work ok, the application will show warning message that the Java is not installed (because is not required for installation). Another thing, Java for wizards like that will NOT be used (or is that I think).
Well, with USE +java, works. Is possible change the language? Thank you very much.
So, now that we have understood under which conditions it crashes (namely Java disabled at build-time and then click on any choice in the base wizard), it would be nice to get a backtrace with symbols so that we can try to fix this issue. Toni: USE -java and -ggdb and *also* follow the instructions at http://www.gentoo.org/proj/en/qa/backtraces.xml#doc_chap1_sect3 to disable stripping (USE nostrip or alternatively USE splitdebug if your portage is recent enough). Then get the crash again and *then* you'll get a decent backtrace with symbols.
Created attachment 83213 [details] Basic backtrace Adding the -java crasher. Note that this happens when you click on select already existing database. If you go with creating new one, it hangs on the last step of the wizzard.
Thank you, Lionel, I compile with this feature but, because I enable the Java, now don't reproduce the symbols and no crash error... nnnooo!!!
(In reply to comment #42) > Adding the -java crasher. This looks like m_aURLPrefixes (in dbaccess/source/ui/dlg/generalpage.[ch]xx) contains a "bad" OUString with pData==0x61. Weird.
The binary package Libreoffice created was slightly higher with java than without it (obviously): 109,4 MB vs 106. I think that is important disable the java functions, minimal for the wizards (important if we want/can disable java by default, for user that don't need depend it). And now, I've the curiosity of the backtrace. I will obtain it! Regards to all.
Created attachment 83243 [details] My GDB Trace! Oh yes yes YEESS!!! :D And now I see that on Gentoo installation, it alerts that if don't select java, crashes the lobase.
Created attachment 83245 [details] My trace with all stack frames, similar to Tomás. I'm learning debugging ;) (I don't understand NOTHING of the data) Thanks a lot to all of you. This is for future detection of fails.
Thanks Toni! Your new trace (with "bt full") allowed me to see that this was already fixed in 4.2.0.alpha. I requested backport of the fix at https://gerrit.libreoffice.org/5176
Javier Fernandez committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=9b1d8d864b813ebf943b85b129335d7d55e35c41&h=libreoffice-4-1 fdo#67361 Prevent out-of-range values coming from ListBox GetSelectEntryPos. It will be available in LibreOffice 4.1.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.
Thank you very much!