Summary: | Base crashes with Oracle ODBC driver when sorting/filtering | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | grongo2 |
Component: | Base | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | NEW --- | ||
Severity: | major | CC: | barta, ilmari.lauhakangas, lionel, raal, serval2412 |
Priority: | medium | Keywords: | haveBacktrace |
Version: | 4.4.2.2 release | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Windows (All) | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Bug Depends on: | |||
Bug Blocks: | 104790, 133092 | ||
Attachments: |
callstack of crash with 5.1.1.1 testing
bt Windows (windbg) |
Description
grongo2
2015-04-08 14:59:53 UTC
works also with MS odbc driver for oracle Hello, where can I download Oracle ODBC driver? Is downloadable from oracle site (you need to register). It's in the "oracle client" package. I've done a bit more debugging, however, and the problem seems due to a combination of driver bug and incorrect LO handling of SQLGetData. Oracle ODBC driver < 11.2.0.1.0 has a bug (Bug 6801797), returning wrong length in SQLGetData last parameter (read as pcbValue by LO). This bug is amplificated by LO incorrect behavior. OTools::getStringValue tries to read a column with more than 2048 bytes by iterating over SQLGetData, but uses only pcbValue to detect when stopping, instead of looking also at the function return value. Further, it iterates even with fixed-length column, while ODBC allows iterating only over variable lenght columns (eg VARCHAR). Calling multiple times SQLGetData on a fixed lenght columns results in the driver doing nothing but returning SQL_NO_DATA for calls after the first. When opening the filter/sort dialog for the first time, LO apparently asks the driver about supported data types, thus getting CHAR data and triggering the bug. AFAIK the sequence is 1. first call to SQLGetData. Buggy oracle driver returns 2048 in pcbValue 2. LO thinks the column has more than 2048 bytes and tries to read another chunk - this time the call to SQLGetData returns SQL_NO_DATA and does nothing, but pcbValue still contains 2048 from previous result 3. LO ignores the return value and looking only at pcbValue copies another 2048 bytes (of garbage) in the result buffer, then tries to read another chunk repeat steps 2 and 3 until crash So a workaround would be resetting pcbValue to zero just before calling SQLGetData. Something like while ((pcbValue == SQL_NO_TOTAL ) || (pcbValue >= nMaxLen) ) { pcbValue = 0; <--- insert 0 here OTools::ThrowException(_pConnection, (*(T3SQLGetData)_pConnection->getOdbcFunction(ODBC3SQLGetData))( _aStatementHandle, (SQLUSMALLINT)columnIndex, SQL_C_CHAR, &aCharArray, nMaxLen, &pcbValue), A better fix should be check SQLGetData return value and act accordingly, but perhaps LO does things this way as a workaround to other driver bugs ? (In reply to Alex Thurgood from comment #4) > Is this a duplicate of bug 87370 ? No, I think not. Bug 87370 involves the jdbc driver instead of odbc and the callstack seems different, involving connectivity::ORowSetValue::operator= instead of connectivity::odbc::OTools::getStringValue Could you try with these instructions: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg Maybe try with the latest version 5.1.1 will be released this week. You can install the release candidate right now separately with this tool: https://wiki.documentfoundation.org/SI-GUI Set to NEEDINFO. Change back to UNCONFIRMED after further testing. Created attachment 123181 [details]
callstack of crash with 5.1.1.1 testing
The bug is still present in 5.1.1.1, I've attached a callstack as requested. Error callstack and probable cause is unchanged from my first bug report. As you can see, in comment #3 is outlined a possibile fix, but I don't know enough of the LO codebase to know if the code knowingly ignores SQLGetData return values as a workaround for another buggy driver or not. Perhaps the best solution would be checking SQLGetData return values, but at least pcbValue should be cleared between calls. Lionel: thought you might be interested in the Grongo2's analysis about this crash (above all at comment 3) has anyone tried latest LibO 5.2.7 or 5.3.2? is issue still present? A git log grep of the source code tree doesn't appear to show any changes in SQLGetData later than 2012, so it is unlikely that this behaviour has changed in the meantime. Hmm, from commit 2f54f2a4ac508de3984d2865da984b9ecf30f602 it would appear that at least some of the problem was addressed by Lionel already back in 2012 Give the already quite detailed analysis, setting to NEW Also seems that https://cgit.freedesktop.org/libreoffice/core/commit/?id=ee5e1bca4b1d0f972eb3f9ab0ec79cf6423fd642 might be relevant ** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug Dear grongo2, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug grongo2: following Alex's comment about https://cgit.freedesktop.org/libreoffice/core/commit/?id=ee5e1bca4b1d0f972eb3f9ab0ec79cf6423fd642 author Lionel Elie Mamane <lionel@mamane.lu> 2012-12-05 06:07:11 +0100 committer Lionel Elie Mamane <lionel@mamane.lu> 2012-12-06 19:20:16 +0100 commit ee5e1bca4b1d0f972eb3f9ab0ec79cf6423fd642 (patch) tree 76f91df8a8bdf29ffb249d44c0a85df6f742a985 parent a62e53830c95eb3db5976232d3375add94749896 (diff) ODBC: clean up our use of SQLGetData do you still reproduce this with LO 6.4.3? Created attachment 161037 [details]
bt Windows (windbg)
On Win10 with master sources updated today, I got an assertion.
Indeed, I did:
diff --git a/dbaccess/source/ui/browser/brwctrlr.cxx b/dbaccess/source/ui/browser/brwctrlr.cxx
index 4fb84775099a..9873e334aefe 100644
--- a/dbaccess/source/ui/browser/brwctrlr.cxx
+++ b/dbaccess/source/ui/browser/brwctrlr.cxx
@@ -1590,7 +1590,9 @@ FeatureState SbaXDataBrowserController::GetState(sal_uInt16 nId) const
}
catch(const Exception& )
{
- DBG_UNHANDLED_EXCEPTION("dbaccess");
+
+ //DBG_UNHANDLED_EXCEPTION("dbaccess");
+ assert(false);
}
to retrieve a bt more easily
Bugs of the foundation and base are fit for the antigen for the realms. Paths of the bug and https://www.bestessay.com/buy-college-essays/ are fit or the regulations for the team. Nature is fit for the movement for all issues. my windows 11 also does not respond perfectly to the driver i installed its a bug for windows or some integration problem OBDC drivers manually intalled also not respond perfectly https://youtube.thumbnail-download.net/ registry files also not respond correctly.. Dear grongo2, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug To tell the truth, the handling of this bug is disheartening: eight year ago I reported it, carrying out a detailed analysis and suggesting a fix. After that, no action, only a "please try with the latest release", even if the source code remains unchanged. Anyway, the bug is still present. Reproducing is simple: open an oracle database via odbc, do a query with a varchar2 field, click on autofilter/filter and see the memory usage grow until crash. I've tried with oo x64 on windows 10, connecting with oracle 19c odbc driver to a 19c database with codepage WE8MSWIN1252 hosted on a linux x64 machine (I donĀ“t think the bug depends on the database details, however) Version: 7.6.3.2 (X86_64) / LibreOffice Community Build ID: 29d686fea9f6705b262d369fede658f824154cc0 CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: it-IT (it_IT); UI: en-US Calc: threaded (In reply to grongo2 from comment #22) > To tell the truth, the handling of this bug is disheartening: eight year ago Welcome to how open-source works. This is a 10 million line codebase with only a handful of maintainers. Identifying the problem is great, but often only the first step in a much larger process. Feel free to get involved and submit a code fix. I'd be happy to review/approve a well-tested patch along the lines of the discussion below. Put me as reviewer on gerrit, and feel free to ping me every week by email if I don't respond. (In reply to grongo2 from comment #3) > OTools::getStringValue tries to read a column with more than 2048 bytes by > iterating over SQLGetData, but uses only pcbValue to detect when stopping, > instead of looking also at the function return value. Good point. Looking also at the function return value would make the code more robust and would be a welcome improvement. > Further, it iterates even with fixed-length column, while ODBC allows > iterating only over variable lenght columns (eg VARCHAR). Not 100% sure what you mean by "fixed-length column", but I note that https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqlgetdata-function#retrieving-variable-length-data-in-parts explicitly allows it for SQL_CHAR, SQL_WCHAR and SQL_BINARY. In the context of this bug, you say the data being read is SQL_CHAR so the iteration seems legit. However, there does seem to be a codepath where indeed LibreOffice will try to do that iteration on SQL_DECIMAL and SQL_NUMERIC: in OResultSet.cxx, method OResultSet::fillColumn Plus anytime any code (even user-written LibreOffice Basic, Python or other API binding) calls getString on a non-string column but only on a DatabaseMetadataResultSet, not on a regular ResultSet. > So a workaround would be resetting pcbValue to zero just before calling > SQLGetData. While I'm generally wary of driver-specific work-arounds, something like that could indeed be seen as a general robustification of the code, so I could be tempted to approve it. One could discuss whether one should set it to some other value than zero, such as e.g. a constant not allowed to be written there by the driver (such as a constant chosen to be different than all valid "Length and Indicator Values", or one valid only for SQLPutData and not SQLGetData). > A better fix should be check SQLGetData return value and act accordingly, > but perhaps LO does things this way as a workaround to other driver bugs ? In the absence of a comment in the code that specifically says so, any such putative driver bug is lost to time immemorial, and could have been fixed since then. I wouldn't let that keep us from moving forward with that better fix. (In reply to grongo2 from comment #22) > To tell the truth, the handling of this bug is disheartening: eight year ago > I reported it, carrying out a detailed analysis and suggesting a fix. > After that, no action, only a "please try with the latest release", even if > the source code remains unchanged. > Anyway, the bug is still present. You mean in the same eight years, Oracle has (also) not fixed their bug? > Reproducing is simple: Well, no. It requires an Oracle database, which is not quite an "apt-get install" away, and I expect requires agreeing to a bizarre funky anti-social agreement forbidding use for any purpose on any machine one wants and/or sharing it with one's neighbour and/or improving it and/or sharing one's improvements? The first download page I could find https://www.oracle.com/database/technologies/xe-downloads.html also doesn't have any download for any source code (so I cannot compile/install it), nor for binaries for my main work machine (GNU/Linux on ppc64le). |