When using the "find record" function from the form navigation toolbar (in a database form) LO crashes if I escape the function immediately (i.e. without performing any search). Actions: 1) open base-document 2) open form 3) click on "find record"-Button (-> dialog opens) 4) don't enter anything into the dialog, just press <ESC> expected reaction: "find record"-dialog simply closing actual reaction: LO shows messagebox title: "LibreOffice 5.1 - Fatal Error" message: "Der Cursor zeigt vor die erste bzw. hinter die letzte Zeile" (translates to: "cursor is pointing before the first, respectively behind the last row") [OK] click on "OK" closes down LO ("soft crash") System-/Installation-Information Version: 5.1.2.2.0+ Build-ID: 1:5.1.2-3~bpo8+1 CPU-Threats: 4; BS-Version: Linux 4.6; UI-Render: Standard; Gebietsschema: de-DE (de_DE.UTF-8)
Would you mind testing with most recent versions (5.1.4.2 fresh and/or 5.2.0.2 pre-release)? Instructions on installing in parallel with the existing version are available at [1]. If the issue persists, could you attach a minimal example database file? I could not reproduce the issue in 5.1.2.2/Windows 7 with a whatever database. Find Record could be closed normally with ESC key. [1] https://wiki.documentfoundation.org/Installing_in_parallel/Linux
No repro on Version: 5.1.4.2 Build ID: f99d75f39f1c57ebdd7ffc5f42867c12031db97a CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; Locale: fr-FR (fr.UTF-8)
No repro on LO 5142 Linux Mint 18
@Volker : your report indicates that you are using a 32bit version of LibreOffice - is this really the case ?
Please also indicate your OS distribution and version.
32bit is correct running debian stable (with jessie-backports) kernel 4.6.0-0.bpo.1-686-pae the form belongs to an address-database, connected to a series of dbase files/tables I meanwhile could figure out the following: * setting up a new form, referring only to the main table -> I can regularly abort the search dialog * I get the described faulty behaviour, when including several related tables, linked via corresponding "ID"-fields 1 - collection of contact-events; 1:n , n may be 0) 2 - status field: "code"-to-"plaintext"; 1:1, code in main record maybe empty 3 - "country"-to-"international phone code" (1:1) thanks so far for checking Volker
@Volker : it would be more useful if you could provide us with a sample database file that contains the tables, main form and subforms to which you refer in your reply
Created attachment 126305 [details] sample test-DB with tables and form OK, got a step further (while preparing this file upload): in the attached status (maybe database needs to be properly reassigned to corresponding directory) , the search WORKS. BUT: deleting the (AID=1) entry from the table "Kontakte" leads to crash; i.e.: if the first record in the main table (Adressen) has no corresponding entry in the linked table (Kontakte), LO crashes as described
Confirming on Version: 5.1.4.2 Build ID: f99d75f39f1c57ebdd7ffc5f42867c12031db97a CPU Threads: 2; OS Version: Mac OS X 10.11.5; UI Render: default; Locale: fr-FR (fr.UTF-8) by following instructions in comment 8
@Volker : I have removed you as assignee, as that field is reserved for the person who wants to fix the bug.
Reproduced in 4.4.0.3, not reproduced in 4.3.0.4 (OS: Windows 7). => regression Also reproduced in 5.2.0.2, but since it's not a real crash, there's no crash report. However since the application exits abruptly, which can cause data loss, raising severity to critical.
Hm, I couldn't reproduce it in Ubuntu 16.04 with 5.1.4.2 (x64). Is LibreOffice being 32/64-bit relevant? Alex, I assume the Mac repro was on 64-bit, right?
I can reproduce a std::terminate under dbgutil by putting "foo" into the search dialog that appears and pressing search. A "not found" dialog appears, and on ok on that the exception fires. Its not 100% the same route to reproduce but very plausible as the problem reported
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d8e225304b7c8465f5e7f038ec02270445e1b600 Resolves: tdf#100845 exception during vcl painting -> std::terminate It will be available in 5.3.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.
@Caolán I'm not convinced, that this solves the original problem, as a not-successful search doesn't terminate my running LO. Even more: *after* an executed search (successful or not) I can harmlessly abort a newly opened search-dialog with ESC. Did you try the steps from the bug description after applying the patch?
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=bab808ca04f8c79a98e8133b09ac1a3934c6d339&h=libreoffice-5-2 Resolves: tdf#100845 exception during vcl painting -> std::terminate It will be available in 5.2.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=90a26f7501b3829eba28e61f5dbae6ce6927b1f1&h=libreoffice-5-1 Resolves: tdf#100845 exception during vcl painting -> std::terminate It will be available in 5.1.6. 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.
Both versions 5.3.0 and 5.2.1 exiting the search dialog peacefully. Thank you! BUT - I don't know if is due to this patch or something else - the search speed appears to be massively decreased (without accurately measuring it, I'd say: at least factor 4 or 5)
(In reply to VolkerTwer from comment #18) > Both versions 5.3.0 and 5.2.1 exiting the search dialog peacefully. > Thank you! > > BUT - I don't know if is due to this patch or something else - the search > speed appears to be massively decreased (without accurately measuring it, > I'd say: at least factor 4 or 5) "Find Record" has almost been a very slow way to find anything in a database. For a better way to search through data have a look here: https://bugs.documentfoundation.org/show_bug.cgi?id=44954 If "Find Record" in LO 5.3 and 5.2 is massively decreased from 5.1 or before: File a new bug.