Bug Hunting Session
Bug 97853 - SQL query crashes Base
Summary: SQL query crashes Base
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.1.0.3 release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: target:5.2.0 target:5.1.3
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2016-02-14 15:03 UTC by Andreas Säger
Modified: 2016-10-25 19:08 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
gdb on the core file (97.71 KB, text/plain)
2016-02-16 14:54 UTC, Terrence Enger
Details
Writer document with "Bibliography" form crashing LO5 (12.24 KB, application/vnd.sun.xml.writer)
2016-04-05 17:05 UTC, Andreas Säger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Säger 2016-02-14 15:03:08 UTC
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
Comment 1 Andreas Säger 2016-02-15 18:41:45 UTC
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.
Comment 2 Terrence Enger 2016-02-16 14:51:49 UTC
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.
Comment 3 Terrence Enger 2016-02-16 14:54:57 UTC
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.
Comment 4 Terrence Enger 2016-02-16 14:57:29 UTC
`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.
Comment 5 Andreas Säger 2016-04-05 17:05:59 UTC
Created attachment 124102 [details]
Writer document with "Bibliography" form crashing LO5
Comment 6 Andreas Säger 2016-04-05 17:06:39 UTC
Affects LO 5.1.1.3 on Windows too.
This is a critical bug.
Comment 7 Michael Stahl (CIB) 2016-04-13 15:58:29 UTC
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
Comment 8 Michael Stahl (CIB) 2016-04-13 16:44:13 UTC
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.
Comment 9 Commit Notification 2016-04-13 16:46:11 UTC
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.
Comment 10 Commit Notification 2016-04-14 13:52:56 UTC
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.
Comment 11 Andreas Säger 2016-04-15 14:35:37 UTC
I confirm that my queries on dBase connections do not crash 
Version: 5.1.3.0.0+
Build ID: 831668298d4486889c1414c91fb47ed6dce21db3
on Linux(x64)
Comment 12 Andreas Säger 2016-04-15 14:35:55 UTC
Thank you very much!