Bug 127299 - FIREBIRD: base crashes if like query has blank in parameter
Summary: FIREBIRD: base crashes if like query has blank in parameter
Status: RESOLVED DUPLICATE of bug 126588
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-09-02 22:16 UTC by Wayne Davis
Modified: 2019-09-04 18:21 UTC (History)
2 users (show)

See Also:
Crash report or crash signature: ["dbtools::OPredicateInputController::implPredicateTree(rtl::OUString &,rtl::OUString const &,com::sun::star::uno::Reference<com::sun::star::beans::XPropertySet> const &)"]

Attachments
Test DB (3.25 KB, application/vnd.sun.xml.base)
2019-09-03 15:27 UTC, Wayne Davis 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Wayne Davis 2019-09-02 22:16:34 UTC 
Description:
I'm getting a crash whenever the parameter to a query has a space in it. A simplified version of the query is:

SELECT * FROM "My_Table" WHERE ( UPPER ( "Title" ) LIKE UPPER ( '%' || ? || '%' ) )

This works fine if the parameter has no spaces but with spaces there's about a 45 second hang followed by a crash. I looked for debug log options but couldn't find any. Also couldn't see the crash report when I chose to send one. Also couldn't append any info to the crash report so doubt that it's useful to developers without knowing what triggered the crash. The Windows application log just showed that soffice.bin crashed.

The table is very simple, one key integer ID field with autovalues and 6 varchar text fields. There are currently only 540 records in the table. The "Title" field used in the simplified query has no null entries and no non ascii characters that I know of.

Steps to Reproduce:
1.  Use any test table with a varchar field (not verified against any other table).
2. Create query similar to "SELECT * FROM "My_Table" WHERE ( UPPER ( "Title" ) LIKE UPPER ( '%' || ? || '%' ) )" where "Title" field is varchar.
2.  Run query, entering parameter with spaces, ex. "xxx yyy" without the quotes. Bug will not happen if parameter is in quotes or if blanks are replaced with _.

Actual Results:
Do it.

Expected Results:
~45 second freeze followed by crash.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Returned query results.

Version: 6.3.0.4 (x64)
Build ID: 057fc023c990d676a43019934386b85b21a9ee99
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 1 Alex Thurgood 2019-09-03 13:39:53 UTC 
Pretty sure that this is a known feature/limitation of the LO integrated SQL parser. The text string must be double quoted if it contains a space when using the LIKE operator. Obviously, the app shouldn't hang though, but at least provide some form of information to the user instead.
Comment 2 Alex Thurgood 2019-09-03 13:40:42 UTC 
@Wayne : please provide the type of database connection / type, and a sample DB where we can attempt to reproduce the problem.
Comment 3 Wayne Davis 2019-09-03 15:27:43 UTC 
Created attachment 153844 [details]
Test DB

Simple DB including query that reproduces bug.
Comment 4 Wayne Davis 2019-09-03 15:29:58 UTC 
Open DB, run query directly, no connection.
Comment 5 QA Administrators 2019-09-03 16:13:45 UTC Comment hidden (obsolete)
Comment 6 Robert Großkopf 2019-09-03 17:52:00 UTC 
Have downloaded the attached database.
Started the query.
Input without quotes
- a space
- t p (t, space, p)
- y m (y, space, m)
First input shows all rows.
Second input shows no row, only the empty row for input new data.
With the last option LO crashes immediately.

The last option would be a part of the field in the second row, so a returned value is expected.

My System: SUSE 15 64bit rpm Linux with LO 6.3.0.4
Comment 7 Xisco Faulí 2019-09-04 10:04:55 UTC 
(In reply to Robert Großkopf from comment #6)
> Have downloaded the attached database.
> Started the query.
> Input without quotes
> - a space
> - t p (t, space, p)
> - y m (y, space, m)
> First input shows all rows.
> Second input shows no row, only the empty row for input new data.
> With the last option LO crashes immediately.
> 
> The last option would be a part of the field in the second row, so a
> returned value is expected.
> 
> My System: SUSE 15 64bit rpm Linux with LO 6.3.0.4

With the last search ( y m ) I get Angry Moose in return, without any crash

Version: 6.4.0.0.alpha0+
Build ID: 41cd3e8e817c8c33a13608e62eeb06ce2c6977e4
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded
Comment 8 Xisco Faulí 2019-09-04 10:10:31 UTC 
issue fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=6d024a69164716f7856ec936a72d01a6630d2a7c
Closing as a duplicate of bug 126588

*** This bug has been marked as a duplicate of bug 126588 ***
Comment 9 Wayne Davis 2019-09-04 18:21:45 UTC 
Issue indeed fixed.  Thank you.  I had no idea base was getting this quality of support.

Downloaded current version 2019-09-04_13.16.18_LibreOfficeDev_6.3.2.0.0.  Tested, bug is gone.