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.
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.
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.
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.
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.
I submitted a patch to review: https://gerrit.libreoffice.org/#/c/47079/1
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.
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.
The bug has been fixed by Lionel, not by me.
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".
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.
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.
The problem is fixed in daily Linux dbgutil repository version 2017-12-29. Thank you, Lionel. I am setting status VERIFIED FIXED.
*** Bug 114810 has been marked as a duplicate of this bug. ***