In Writer or Calc hit F4 and right-click open the built-in Bibliography.odb which is connected to a dBase directory in the user profile. Run the following query: SELECT CONCAT( "Identifier", ' | ', "Author" ) "Concat" FROM "biblio" The result is a crash. Works fine with LO4.4.7
After some more testing it seems to be an issue with some built-in functions for file based databases. These functions are documented here: > http://www.openoffice.org/dba/specifications/file_based_functions.html I tested some of the functions with dBase, spreadsheets and csv and found that substring and concat make LO5.1 crash. left, right, mid, char, upper, lower work as expected.
Thank you, Andreas, for taking the time to help us improve LibreOffice. Can you please tell us what operating system you were using when you saw the problem? In the linux daily dbgutil bibisect repository version 2016-02-12, I have provoked three instances of the terminal messages (whitespace added) ... warn:xmloff.core:20963:1:xmloff/source/core/xmlimp.cxx:938: exception caught warn:legacy.osl:20963:1:xmloff/source/core/xmlimp.cxx:939: caught an exception! in function:virtual void SvXMLImport::setTargetDocument (const com::sun::star::uno::Reference<com::sun::star::lang ::XComponent>&) type: com.sun.star.lang.NotInitializedException context: N8dbaccess17ODatabaseDocumentE with the following steps ... (1) Open instdir/user/database/biblio.odb from the command line. Program presents window "biblio.odb - LibreOfficeDev Base 5.2 ...". (2) Click <Queries>. (3) Select "Create Query in SQL View...". Program presents window "biblio.odb : Query1 - LibreOfficeDev Base: Query Design ...". (4) Paste the query string from the bug description. (5) Type "<F5>". Program quits abruptly, but without leaving a core file. However, I shall soon attach a backtrace with a longer set of steps, presumably matching more closely what Andreas saw. I am setting bug status NEW. I am think that the priority should be MEDIUM CRITICAL because this is a crash, but it does not affect a log of users; however I lack the permission to do that.
Created attachment 122690 [details] gdb on the core file `backtrace full` is at line 43. This is from a local build of commit f705570, fetched 2016-02-12 18:44 UTC, configured ... CC=ccache /usr/bin/gcc CXX=ccache /usr/bin/g++ --enable-option-checking=fatal --enable-dbgutil --enable-debug --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src built and running on debian-stretch. The steps I took were ... ( 1) Run Calc from the command line. ( 2) A couple of times type "<F4"> and then respond to the error message. (I may get around to reporting the error message as a separate bug.) ( 3) Take menu options File > New > "Text document". Program presents Writer window. ( 4) Type "<F4>". Program opens database pane. ( 5) Expand "Bibliography". ( 6) On each item, right-click and dismiss the pop-up menu. ( 7) Right-click Bibliography and select "Edit...". Program presents window "biblio.odb - LibreOfficeDev Base 5.2 ...". ( 8) Click <Queries>. ( 9) Select "Create Query in SQL View...". Program presents window "biblio.odb : Query1 - LibreOfficeDev Base: Query Design ...". (10) Paste the query string from the bug description. (11) Type "<F5>". KABOOM. Note that frame 12, dbaccess::ORowSet::execute_NoApprove_NoNewConn has variable aNames so badly screwed up that emacs stutters after the backtrace is pasted in. The nonsense starts with the parameter being a std::__debug::vector of length -10, and it just gets worse from there, filling about 25 screensful in the terminal.
`backtrace full` is at line 43. This is from a local build of commit f705570, fetched 2016-02-12 18:44 UTC, configured ... CC=ccache /usr/bin/gcc CXX=ccache /usr/bin/g++ --enable-option-checking=fatal --enable-dbgutil --enable-debug --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src built and running on debian-stretch. The steps I took were ... ( 1) Run Calc from the command line. ( 2) A couple of times type "<F4"> and then respond to the error message. (I may get around to reporting the error message as a separate bug.) ( 3) Take menu options File > New > "Text document". Program presents Writer window. ( 4) Type "<F4>". Program opens database pane. ( 5) Expand "Bibliography". ( 6) On each item, right-click and dismiss the pop-up menu. ( 7) Right-click Bibliography and select "Edit...". Program presents window "biblio.odb - LibreOfficeDev Base 5.2 ...". ( 8) Click <Queries>. ( 9) Select "Create Query in SQL View...". Program presents window "biblio.odb : Query1 - LibreOfficeDev Base: Query Design ...". (10) Paste the query string from the bug description. (11) Type "<F5>". KABOOM. Note that frame 12, dbaccess::ORowSet::execute_NoApprove_NoNewConn has variable aNames so badly screwed up that emacs stutters after the backtrace is pasted in. The nonsense starts with the parameter being a std::__debug::vector of length -10, and it just gets worse from there, filling about 25 screensful in the terminal. ** comment 03 keywords : regression bibisected haveBacktrace body ---- Working in the daily linux dbgutil bibisect repository, I see the segfault came into the program between versions ... cd5fd7c23803cd176ec1ad1f34849868432856ee 2015-10-01: source-hash-4f1dca5083c5a301181786b563b165f19a9dec7f and ... 4b91c933fde354f727c53392ecea5aa3517668c5 2015-09-30: source-hash-ef1bafb588eb20a5d35df14e79a1a948885c721a I am setting keywords regression, bibisected, haveBacktrace.
Created attachment 124102 [details] Writer document with "Bibliography" form crashing LO5
Affects LO 5.1.1.3 on Windows too. This is a critical bug.
if i backport this to libreoffice-5-0 and rebuild connectivity it crashes, regression from: commit ac9671f94800b647f82b12e718968311a025e87e Author: Oliver Specht <oliver.specht@cib.de> AuthorDate: Tue Sep 29 11:00:09 2015 +0200 tdf#94559: second step to remove rtti.hxx replaced use of PTR_CAST, IS_TYPE, ISA in chart2, connectivity, editeng, extensions, filter, forms, framework, idl
valgrind finds this use-after-free: ==31261== Address 0x666d2350 is 0 bytes inside a block of size 32 free'd ==31261== at 0x4C29CF0: free (vg_replace_malloc.c:530) ==31261== by 0x4E5657A: rtl_freeMemory_SYSTEM(void*) (alloc_global.cxx:279) ==31261== by 0x4E5685E: rtl_freeMemory (alloc_global.cxx:349) ==31261== by 0x793E7210: connectivity::file::OCode::operator delete(void*) (fcode.hxx:55) ==31261== by 0x794416B5: connectivity::file::OStopOperand::~OStopOperand() (fcode.hxx:177) ==31261== by 0x794358C7: connectivity::file::ONthOperator::Exec(std::stack<connectivity::file::OOperand*, std::__debug::deque<connectivity::file::OOperand*, std::allocator<connectivity::file::OOperand*> > >&) (fcode.cxx:370) fixed on master.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=49d320c6202a569f996c27fd824239f5f1f8a036 tdf#97853 connectivity: fix inverted condition It will be available in 5.2.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2deebf81db15688abfe1db059f73da4b8e410c25&h=libreoffice-5-1 tdf#97853 connectivity: fix inverted condition It will be available in 5.1.3. 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.
I confirm that my queries on dBase connections do not crash Version: 5.1.3.0.0+ Build ID: 831668298d4486889c1414c91fb47ed6dce21db3 on Linux(x64)
Thank you very much!