Bug Hunting Session
Bug 65653 - EDITING: Base crashes with queries with keyword "LIKE" in GUI-Mode
Summary: EDITING: Base crashes with queries with keyword "LIKE" in GUI-Mode
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.1.0.1 rc
Hardware: All All
: high blocker
Assignee: Tamás Zolnai
URL:
Whiteboard: target:4.2.0 target:4.1.0.1
Keywords: regression
: 65216 65619 (view as bug list)
Depends on:
Blocks: mab4.1
  Show dependency treegraph
 
Reported: 2013-06-11 13:44 UTC by ribotb
Modified: 2013-07-01 09:46 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
apple crash trace using LIKE in UI query design (77.96 KB, text/plain)
2013-06-12 08:06 UTC, Alex Thurgood
Details
hs_err log, when LO crashes on Debian Testing AMD64 (116.66 KB, text/x-log)
2013-06-12 11:38 UTC, Thomas Hackert
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ribotb 2013-06-11 13:44:55 UTC
Hi,

With queries containing a parameter in criteria (in the SQL statement: LIKE :xxx) :
- crash when editing the queries with the Query Editor (no crash when editing with the SQL Editor);
- crash when running these queries;
- crash when saving a new such query.

Version: 4.1.0.0.beta2
Build ID: 33224f4f11a05cfad2249e812fcc2975fbb61f6
Windows 7 32bits

Regards,
Bernard Ribot
Comment 1 Robert Großkopf 2013-06-11 14:46:39 UTC
I can confirm this behavior for Linux 64bit rpm. Will change the status to "New". It isn't the parameter, which produces the crash. It's SQL "LIKE", when using the GUI of the query-editor (not directly SQL).
Will also change the title of this bugreport, because "parameter" is used in Base for a query, which allows input of a variable before executing the query.
Comment 2 Thomas Hackert 2013-06-11 15:21:29 UTC
Hello ribotb, robert, *,
I can confirm it with LO Version: 4.1.0.0.beta1+
Build ID: 94c59899d91852e5efbe29f85d57fd780e4c4e5
TinderBox: Linux-x86_64@31-Release-Configuration-RHEL5-Baseline, Branch:libreoffice-4-1, under Debian Testing AMD64 ... If it would be of any help, I can attach an hs_err_pid log file from OpenJDK to this issue, which I got, when I tried to insert the "LIKE" parameter in LO's GUI.
Sorry for the inconvenience
Thomas.
Comment 3 Alex Thurgood 2013-06-12 07:42:49 UTC
Adding Lionel to CC
Comment 4 Alex Thurgood 2013-06-12 08:06:04 UTC
Confirming also on OSX 10.8.4 with LO master 

Version: 4.2.0.0.alpha0+
Build ID: c2530b02311c46529eed53ee688bf6c83ce4b86


Apple crash stack included.


Alex
Comment 5 Alex Thurgood 2013-06-12 08:06:49 UTC
Created attachment 80714 [details]
apple crash trace using LIKE in UI query design
Comment 6 Alex Thurgood 2013-06-12 08:07:28 UTC
Also adding Julien to CC.
Comment 7 Alex Thurgood 2013-06-12 08:09:15 UTC
(In reply to comment #2)

Hi Thomas,


> Branch:libreoffice-4-1, under Debian Testing AMD64 ... If it would be of any
> help, I can attach an hs_err_pid log file from OpenJDK to this issue, which
> I got, when I tried to insert the "LIKE" parameter in LO's GUI.
> Sorry for the inconvenience


Yes, please do attach the pid error log if you have one.

Alex
Comment 8 Alex Thurgood 2013-06-12 08:15:48 UTC
running under gdb, when I click on "execute query" after having entered a like constraint, I see :

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x19b535b3 in (anonymous namespace)::columnMatchP ()


(gdb) info frame 
Stack level 0, frame at 0xbfffe220:
 eip = 0x19b535b3 in (anonymous namespace)::columnMatchP(connectivity::OSQLParseNode const*, connectivity::SQLParseNodeParameter const&); saved eip 0x19b57485
 called by frame at 0xbfffe2c0
 Arglist at 0xbfffe218, args: 
 Locals at 0xbfffe218, Previous frame's sp is 0xbfffe220
 Saved registers:
  ebx at 0xbfffe20c, ebp at 0xbfffe218, esi at 0xbfffe210, edi at 0xbfffe214, eip at 0xbfffe21c
Comment 9 Alex Thurgood 2013-06-12 08:17:08 UTC
(gdb) backtrace
#0  0x19b535b3 in (anonymous namespace)::columnMatchP ()
#1  0x19b57485 in connectivity::OSQLParseNode::impl_parseLikeNodeToString_throw ()
#2  0x19b56ca8 in connectivity::OSQLParseNode::impl_parseNodeToString_throw ()
#3  0x19b586ed in connectivity::OSQLParseNode::parseNodeToStr ()
#4  0x19b589cb in connectivity::OSQLParseNode::parseNodeToStr ()
#5  0x1c3b9d65 in (anonymous namespace)::GenerateCriterias ()
#6  0x1c3c2dbb in dbaui::OQueryDesignView::getStatement ()
#7  0x1c3d09b2 in dbaui::OQueryViewSwitch::getStatement ()
#8  0x1c3a3554 in dbaui::OQueryController::translateStatement ()
#9  0x1c3a4262 in dbaui::OQueryController::executeQuery ()
#10 0x1c3adfbc in dbaui::OQueryController::Execute ()
#11 0x1c248743 in dbaui::OGenericUnoController::executeChecked ()
#12 0x1c2417ac in dbaui::OGenericUnoController::dispatch ()
#13 0x0b8e19d4 in framework::GenericToolbarController::ExecuteHdl_Impl ()
#14 0x01afaadd in ImplWindowFrameProc ()
#15 0x01b07768 in AquaSalInstance::Yield ()
#16 0x017c7dd4 in Application::Yield ()
#17 0x017c7e8c in Application::Execute ()
#18 0x0006c71a in desktop::Desktop::Main ()
#19 0x017ce322 in ImplSVMain ()
#20 0x01b06b71 in AquaSalInstance::handleAppDefinedEvent ()
#21 0x01b4456b in -[VCL_NSApplication sendEvent:] ()
#22 0x96c9b62c in -[NSApplication run] ()
#23 0x96c3e5f6 in NSApplicationMain ()
#24 0x01b07437 in ImplSVMainHook ()
#25 0x017ce351 in SVMain ()
#26 0x0009c0a5 in soffice_main ()
#27 0x00001f4e in main ()
Comment 10 Alex Thurgood 2013-06-12 08:20:28 UTC
(gdb) info register
eax            0x0	0
ecx            0x0	0
edx            0xbfffe1f8	-1073749512
ebx            0x19b5358e	431306126
esp            0xbfffe1b0	0xbfffe1b0
ebp            0xbfffe218	0xbfffe218
esi            0x100	256
edi            0xbfffe3cc	-1073749044
eip            0x19b535b3	0x19b535b3 <(anonymous namespace)::columnMatchP(connectivity::OSQLParseNode const*, connectivity::SQLParseNodeParameter const&)+51>
eflags         0x10246	66118
cs             0x1b	27
ss             0x23	35
ds             0x23	35
es             0x23	35
fs             0x0	0
gs             0xf	15
Comment 11 Alex Thurgood 2013-06-12 08:26:02 UTC
Note that on OSX, I also see the problem in the SQL query editor if I add a LIKE constraint to a query, with the same output in gdb at the same place.



Alex
Comment 12 Julien Nabet 2013-06-12 10:35:53 UTC
Thank you Alex for the bt, according to this one, I think it's a dup of fdo#65619 (put in see also).
Comment 13 Thomas Hackert 2013-06-12 11:38:23 UTC
Created attachment 80722 [details]
hs_err log, when LO crashes on Debian Testing AMD64

Hello Alex, *,
attached you will find my hs_err log from OpenJDK 6.0_27-b27 under Debian Testing AMD64, when I insert "LIKE" in GUI mode and try to save it.
Thanks for all your work in this bug and reminding me
Thomas.
P.S.: I will add it to bug 60270 afterwards ... ;)
Comment 14 Julien Nabet 2013-06-12 11:56:34 UTC
thackert: thank you for your feedback, I noticed this line here too:
C  [libdbtoolslo.so+0x137043]  (anonymous namespace)::columnMatchP(connectivity::OSQLParseNode const*, connectivity::SQLParseNodeParameter const&)+0x53
Comment 15 Julien Nabet 2013-06-14 15:52:44 UTC
I put fdo#65216 in see also but according to the bt, it could be a dup.
(crashes at columnMatchP method, line 143).
Comment 16 Julien Nabet 2013-06-14 19:58:38 UTC
See Terrence's comment https://bugs.freedesktop.org/show_bug.cgi?id=65619#c7 which gives some precious information
(and so put him in cc)

Lionel: do you think "see also" fdos are dup or is it too early to tell?
Comment 17 Commit Notification 2013-06-15 09:10:30 UTC
Zolnai Tamas committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=10777b37536be16c6d2e167b59e9e31e37ba3517

fdo#65653, fdo#65619, fdo#65216: Missing check



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 18 Commit Notification 2013-06-15 09:18:45 UTC
Zolnai Tamas committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=90c240cf503147d6e2d3996dbea5492e8126bed8&h=libreoffice-4-1

fdo#65653, fdo#65619, fdo#65216: Missing check


It will be available in LibreOffice 4.1.

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 19 Tamás Zolnai 2013-06-15 11:39:13 UTC
*** Bug 65619 has been marked as a duplicate of this bug. ***
Comment 20 Tamás Zolnai 2013-06-15 11:39:41 UTC
*** Bug 65216 has been marked as a duplicate of this bug. ***
Comment 21 Terrence Enger 2013-06-15 17:07:46 UTC
Just for those without the fix, I note that I have found a workaround
for the crash I encountered in "Creqte Query in SQL View...".  Within
the SQL view window, in menu Edit, select "Run SQL command directly".
Comment 22 Tamás Zolnai 2013-06-15 17:28:49 UTC
(In reply to comment #21)
> Just for those without the fix, I note that I have found a workaround
> for the crash I encountered in "Creqte Query in SQL View...".  Within
> the SQL view window, in menu Edit, select "Run SQL command directly".

Yes, that works. The problem was with LO own sql parser. The "Run SQL command directly" option makes LO to skip its own syntax check and send statement to the underlying database directly.
Comment 23 Alex Thurgood 2013-06-17 10:35:09 UTC
Verified on master for OSX :

Version: 4.2.0.0.alpha0+
Build ID: 1780b582cc880538c98796a67f64a0bdd696ea2


Alex
Comment 24 Alex Thurgood 2013-06-17 10:36:20 UTC
Thanks Tamás !

Alex
Comment 25 ribotb 2013-06-17 11:10:07 UTC
Thanks for the correction.

Available in next beta or RC 4.1, for test ?

Bernard Ribot
Comment 26 tim 2013-06-17 11:34:29 UTC
I'm try to work out whether this fix is in the latest Linux master.  Can someone explain how to do this?

I have the information from the build:

tinderbox: pull time 2013-06-17 04:13:35
tinderbox: git sha1s
core:99eee227ac5a96a2657e26d64b8fbf228fd10bf2

I have information from the patch:
commit	 10777b37536be16c6d2e167b59e9e31e37ba3517 (patch) (side-by-side diff)
tree	 20023dee58eddd11dcfd65d9d14d7f0dee992218
parent	 a99f20c5c29e0dff5fd9d6c6b474eb0a788cd6b8 (diff)
download core-10777b37536be16c6d2e167b59e9e31e37ba3517.zip
core-10777b37536be16c6d2e167b59e9e31e37ba3517.tar.gz

and

Change-Id: Ibbdaa758dbbce4b76094e6cc120022ef276b30c4

But I don't know how to work out whether the core number of the build includes this patch.
Comment 27 Alex Thurgood 2013-06-17 11:43:27 UTC
Hi Tim,


New commits:
commit 90c240cf503147d6e2d3996dbea5492e8126bed8
Author: Zolnai Tamás
Date:   Sat Jun 15 11:02:32 2013 +0200


It went in on June 15th, at 11:02, so it should be in that build, from what I understand.


Alex
Comment 28 Tamás Zolnai 2013-06-17 14:03:15 UTC
Hi Tim,

> But I don't know how to work out whether the core number of the build
> includes this patch.

I found this article, which maybe help you too:
http://stackoverflow.com/questions/1419623/how-to-list-branches-that-contain-a-given-commit

Using git branch --contains <commit> returns a list with branches that has the commit with id <commit>.
Comment 29 Tamás Zolnai 2013-06-17 14:05:41 UTC
(In reply to comment #25)
> Thanks for the correction.
> 
> Available in next beta or RC 4.1, for test ?
> 
> Bernard Ribot

Yes, it will work in RC1.
Comment 30 Tamás Zolnai 2013-06-17 14:16:29 UTC
Hi Tim,

> > But I don't know how to work out whether the core number of the build
> > includes this patch.
> 
> I found this article, which maybe help you too:
> http://stackoverflow.com/questions/1419623/how-to-list-branches-that-contain-
> a-given-commit
> 
> Using git branch --contains <commit> returns a list with branches that has
> the commit with id <commit>.

Oh, sorry. You don't use git. :)

Alex is right. The latest master contains this patch.
Comment 31 tim 2013-06-17 17:09:13 UTC
It seems a little strange that ordinary users, such as myself, who raise a bug report and are keen to help reasonably early testing, can't find out for themselves whether a daily release has a fix or not.

No matter.  Thanks for the information that it is in the new Master.  Unfortunately I don't have a system on which I can easily install the rpm version (I've only got 32 and 64 bit debian/ubuntu systems).  So I'll have to wait until a deb version of 4.1 or 4.2 is available, and hopefully one that lists bug report numbers (such as a beta or RC).
Comment 32 Julien Nabet 2013-06-17 18:27:08 UTC
Tim: 3 things which may help (or I would say 2 in fact :-)):
1) Whiteboard, you can see target:4.2.0 target:4.1.0.1 so you can be sure the fix will be in 4.2.0 and 4.1.0.1
but you talked about daily build, so point 2)

2) Comment 17 (https://bugs.freedesktop.org/show_bug.cgi?id=65653#c17) has been generated automatically and includes this:
"
The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours
"

3) If you want to be sure, you can take a look to http://cgit.freedesktop.org/libreoffice/core/log/, select "range" instead of "log msg" and put the commit id of the patch then the one of the build.


Now I agree, it could be interesting to have a file which lists the list of commits since previous build.
Comment 33 tim 2013-06-17 19:43:14 UTC
Thanks.  I appreciate people are trying to help (as am I in trying to test a related bug), but since I am a user, not a developer, I lack sufficient knowledge to comprehend most of the advice. 

1) I don't know what the Whiteboard 'bibisectrequest' means, and don't know whether it refers to full and final release versions, RCs, betas or what.

2) The 'should be' doesn't really help me, since I can't be 100% certain what I am testing, and there are often (even usually) no builds for platforms I can run.  (To download, install, faff around trying to ensure I can run the new version without breaking my normal runtime version, and then run several types of test, will take me several hours).

3) I tried the range several times, but I don't understand the result. I am also not sure whether to concatenate the two ids, or separate with a space, or what. To be clear about the level of ignorance on my part, I have little idea what git is, let alone how to use it.

So, with apologies for wasting people's time, I had better wait until I can see something I understand that says that #65216 and/or #65653 is fixed in a particular deb release.  I'll try to take a look once a week or so in the hope of catching a pre-release with the fix in.

(I was a programmer once, but that was quite a long time ago ....)
Comment 34 Julien Nabet 2013-06-17 20:00:10 UTC
Tim: I think these links may interest you:
- https://wiki.documentfoundation.org/QA
- https://wiki.documentfoundation.org/BugReport_Details
About range, one commit filled gives just the one you search at the top of the list. However, I never succeeded in putting a range.

About bibisect, you can have a look to this link: https://wiki.documentfoundation.org/Bibisect

About the "should be", you must keep in mind that the main goal of daily builds is testing and not for day to day use on important documents. 

There are still a lot of things that I don't know but no need to be an expert to contribute:-)
If you need more help, there are different mailing lists here: http://nabble.documentfoundation.org/LibreOffice-f1639495.html
Comment 35 tim 2013-06-17 21:38:56 UTC
Thanks.  I've read the Q&A & Bug reporting articles before but they don't seem to address my question.  

For the git range it was said I should put in 2 commit ids, but I don't see how to do that.  I still get pages of results whichever id I put in, and whichever version I select, and I can't tell what it means.

I'm afraid I can't comprehend the video, partly because I am a bit deaf - sorry.  

I know that the daily builds are for testing, that's why I wanted to use them - to test whether the bug I reported had been fixed.  I had hoped to be of some use.

I suspect I am missing a lot of basic knowledge to help me understand how this stuff fits together. I'll try looking at the mailing lists, but for this report let's leave it at that.
Comment 36 Lionel Elie Mamane 2013-06-18 10:54:59 UTC
I've added instructions on how to use the "range" search at https://wiki.documentfoundation.org/QA/FAQ
Comment 37 Commit Notification 2013-06-18 11:06:17 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=20499497b0c513f181d0a482c5b9e38c346a8aa1

fdo#65653 make columnMatchP safer



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 38 Commit Notification 2013-06-18 11:14:58 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=ed9f8387201b1b70ea14af47d25e9133c7bfcd3c

Revert "fdo#65653, fdo#65619, fdo#65216: Missing check"



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 39 Julien Nabet 2013-06-18 11:34:03 UTC
(In reply to comment #36)
> I've added instructions on how to use the "range" search at
> https://wiki.documentfoundation.org/QA/FAQ

Very clear and useful, thank you Lionel!
Comment 40 Commit Notification 2013-06-18 12:05:48 UTC
Lionel Elie Mamane committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

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

fdo#65653 make columnMatchP safer


It will be available in LibreOffice 4.1.

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 41 tim 2013-06-18 16:59:36 UTC
(In reply to comment #36)
> I've added instructions on how to use the "range" search at
> https://wiki.documentfoundation.org/QA/FAQ

Thanks a lot.  It's much clearer now.

The helpfulness and patience of people involved in this endeavour never ceases to amaze me.

Tim
Comment 42 tim 2013-06-22 16:54:27 UTC
Tested in "Index of /daily/libreoffice-4-1/Linux-x86@34-Release-Configuration-RHEL5-Baseline/2013-06-21_18.46.32"

Problem fixed (as is the original related #65216) both in the test database I created to demonstrate the problem, and in my full system.

Thanks to all.
Comment 43 ribotb 2013-06-27 16:57:23 UTC
Hi,

Tested with LO 4.1.0.1 under Win 7. It works.

Thanks,
Bernard
Comment 44 tim 2013-07-01 09:41:21 UTC
The problem has re-appeared in the ubuntu pre-release PPA version RC1

Version: 4.1.0.1
Build ID: 410m0(Build:1)

This is strange, since it was OK in the 4.1.0.1 I downloaded from the website a few days ago.
Comment 45 tim 2013-07-01 09:44:29 UTC
Sorry - wrong but report.  Lest haste required.
Comment 46 tim 2013-07-01 09:46:18 UTC
Not my day.  I should have written:

"Sorry - wrong bug report.  Less haste required."