Download it now!
Bug 114702 - Loop executing direct SQL
Summary: Loop executing direct SQL
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.4.3.1 rc
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0 target:5.4.5 target:6.0.0.2
Keywords: bibisected, haveBacktrace, regression
: 114810 (view as bug list)
Depends on:
Blocks:
 
Reported: 2017-12-26 20:00 UTC by Terrence Enger
Modified: 2018-01-05 20:23 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
example .odb, embedded firebird (3.83 KB, application/vnd.oasis.opendocument.database)
2017-12-26 20:00 UTC, Terrence Enger
Details
excerpt from gdb: info threads; backtrace (15.04 KB, text/plain)
2017-12-26 21:03 UTC, Terrence Enger
Details
tail of terminal output from bibisect (2.48 KB, text/plain)
2017-12-26 23:16 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Terrence Enger 2017-12-26 20:00:15 UTC
Created attachment 138664 [details]
example .odb, embedded firebird

STR
(1) Open attached file a02_fb.odb.  Program presents main database window.
(2) In Database pane click <Queries>.
(3) In Tasks pane click <Create Query in SQL View...".  Program
    presents Query Design window.
(4) In tool bar select icon "Run SQL command directly".
(5) Close Query Design window; decline offer to Save.
(6) In main database window, take menu options Tools > "SQL...".
(7) Click "Show output of "select" statements"
(8) In Command to execute type
        select * from Table1
(9) Click <Execute>.  Program loops, using approximately 100% of one CPU.

I observe this in daily Linux dbgutil bibisect repository version
2017-12-26.
Comment 1 Terrence Enger 2017-12-26 21:03:16 UTC
Created attachment 138665 [details]
excerpt from gdb: info threads; backtrace

Looking further, I see a long running loop between
dbaccess/source/ui/dlg/directsql.cxx statements 207 and 209:

                   +-- uno::Reference to (OStatement *) 0x5555573072e8
                   |  +-- com::sun::star::uno::Reference<com::sun::star
                   |  |  ::sdbc::XMultipleResults>::operator->
                   |  |  return value = (OStatement *) 0x555557307210
                   |  | +-- OStatementBase::getMoreResults
                   |  | |   return value = 0 '\000'
                   |  | |
207: while ((hasRS=xMR->getMoreResults()) || (xMR->getUpdateCount() != -1))
                                                 | |
       com::sun::star::uno::Reference<com::sun --+ |
       ::star::sdbc::XMultipleResults>             |
       ::operator->                                |
       return value =                              |
       (OStatement *) 0x555557307210               |
                  OStatementBase::getUpdateCount --+
                  return value = 0

208: {
209:     if(hasRS)
            | 
            +-- false
210:     {
...   
214:     }
215: }


This information is from a local build of 68f7d89c, 2017-12-11,
configured
    CC=ccache /usr/bin/gcc
    CXX=ccache /usr/bin/g++
    --enable-option-checking=fatal
    --enable-dbgutil
    --enable-debug
    --without-system-postgresql
    --without-myspell-dicts
    --with-extra-buildid
    --without-doxygen
    --with-external-tar=/home/terry/lo_hacking/git/src
    --without-package-format
built and running of debian-buster.

I am setting keyword haveBacktrace.
Comment 2 Terrence Enger 2017-12-26 23:16:15 UTC
Created attachment 138671 [details]
tail of terminal output from bibisect

Working on debian-buster in the recently retired daily Linux dbgutil
bibisect repository, I see that the bug entered LO somewhere in the
41 or so commits:

          commit    date        s-h
          --------  ----------  --------
    good  e73ca17e  2017-09-24  722161e2
    bad   cc32ba82  2017-09-25  40892cd3

Commit fe0f1dba "Use a ref for arg of DirectSQLDialog::display"
catches my attention.  Julien, are you interested?

I am adding keywords regression, bibisected.
Comment 3 Julien Nabet 2017-12-27 08:01:35 UTC
On pc Debian x86-64 with master sources updated some days ago I could reproduce this.

Steps 2, 3, 4 and 5 are useless to reproduce this.
Comment 4 Julien Nabet 2017-12-27 08:05:59 UTC
Just reverting https://cgit.freedesktop.org/libreoffice/core/commit/?id=fe0f1dba1369f5d9f382ee3432833e22fe0da442 isn't sufficient, you must also revert https://cgit.freedesktop.org/libreoffice/core/commit/?id=444730a67dbd2ad6cebe666b2cd23c67d5c668f2 to prevent from looping.

I'll give it a try.
Comment 5 Julien Nabet 2017-12-27 08:34:17 UTC
I submitted a patch to review: https://gerrit.libreoffice.org/#/c/47079/1
Comment 6 Lionel Elie Mamane 2017-12-27 09:15:06 UTC
That's actually probably a bug in the embedded firebird driver. getUpdateCount() is _not_ supposed to return zero for a SELECT query (in JDBC/SDBC API terms: if the result of the query/command is a ResultSet), but to return -1.

Looking at the code, it claims to support com::sun::star::sdbc::XMultipleResults but really doesn't. I think fixing that will fix this bug. I'm preparing a patch.
Comment 7 Commit Notification 2017-12-28 08:42:13 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=3c567e55e6aed9e0da892d8b9fc09f8a0c784fcc

tdf#114702 don't use XMultipleResultset unless DatabaseMetaData says we can

It will be available in 6.1.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 8 Julien Nabet 2017-12-28 08:46:02 UTC
The bug has been fixed by Lionel, not by me.
Comment 9 Lionel Elie Mamane 2017-12-28 09:06:03 UTC
It seems to me this was never reproduced on 4.1, but only master. The bibisected commit has been cherry-picked in libreoffice-5-4 towards the 5.4.3.1 rc release, so putting that as my guess of "earliest affected version".
Comment 10 Commit Notification 2017-12-28 10:29:00 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bec82bc44813fb170602f523e8f7d541d1c94dcb&h=libreoffice-5-4

tdf#114702 don't use XMultipleResultset unless DatabaseMetaData says we can

It will be available in 5.4.5.

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 Commit Notification 2017-12-28 15:20:50 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=31b0920a8018979bd8b0b5bf804edcf61f89fd67&h=libreoffice-6-0

tdf#114702 don't use XMultipleResultset unless DatabaseMetaData says we can

It will be available in 6.0.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.
Comment 12 Terrence Enger 2017-12-29 18:36:14 UTC
The problem is fixed in daily Linux dbgutil repository version
2017-12-29.

Thank you, Lionel.  I am setting status VERIFIED FIXED.
Comment 13 Lionel Elie Mamane 2018-01-04 12:35:49 UTC
*** Bug 114810 has been marked as a duplicate of this bug. ***