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
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.
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.
Adding Lionel to CC
Confirming also on OSX 10.8.4 with LO master Version: 4.2.0.0.alpha0+ Build ID: c2530b02311c46529eed53ee688bf6c83ce4b86 Apple crash stack included. Alex
Created attachment 80714 [details] apple crash trace using LIKE in UI query design
Also adding Julien to CC.
(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
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
(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 ()
(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
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
Thank you Alex for the bt, according to this one, I think it's a dup of fdo#65619 (put in see also).
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 ... ;)
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
I put fdo#65216 in see also but according to the bt, it could be a dup. (crashes at columnMatchP method, line 143).
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?
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.
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.
*** Bug 65619 has been marked as a duplicate of this bug. ***
*** Bug 65216 has been marked as a duplicate of this bug. ***
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".
(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.
Verified on master for OSX : Version: 4.2.0.0.alpha0+ Build ID: 1780b582cc880538c98796a67f64a0bdd696ea2 Alex
Thanks Tamás ! Alex
Thanks for the correction. Available in next beta or RC 4.1, for test ? Bernard Ribot
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.
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
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>.
(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.
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.
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).
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.
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 ....)
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
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.
I've added instructions on how to use the "range" search at https://wiki.documentfoundation.org/QA/FAQ
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.
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.
(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!
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.
(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
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.
Hi, Tested with LO 4.1.0.1 under Win 7. It works. Thanks, Bernard
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.
Sorry - wrong but report. Lest haste required.
Not my day. I should have written: "Sorry - wrong bug report. Less haste required."