Bug 123962 - Form based filter search freezes LO with main form and subform
Summary: Form based filter search freezes LO with main form and subform
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: high major
Assignee: Not Assigned
Keywords: bibisectRequest, regression
Depends on:
Reported: 2019-03-09 14:18 UTC by Brent Warkentin
Modified: 2019-07-10 21:35 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Base database with Form Issue (18.35 KB, application/vnd.sun.xml.base)
2019-03-11 12:16 UTC, Brent Warkentin

Note You need to log in before you can comment on or make changes to this bug.
Description Brent Warkentin 2019-03-09 14:18:51 UTC
Form based filter search now hangs the software after upgrading to :

Version: (x64)
Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-CA (en_CA); UI-Language: en-GB
Calc: threaded

Steps to Reproduce:
1. Open a Base form and click on form based filter... software hangs

Actual Results:
Software hangs as above... forced to close and recover database

Expected Results:
Software hangs

Reproducible: Always

User Profile Reset: No

Additional Info:
Actually allowed me to click on a form entry box and enter a searcvh criteria value
Comment 1 Robert Großkopf 2019-03-09 17:47:05 UTC
Tested with LO and LO on OpenSUSE 64bit rpm Linux. Didn't see any buggy behaviour when filtering with the form based filter.
Comment 2 frofa 2019-03-09 21:04:15 UTC
Confirming this problem with form-based filter button on Mac OSX version 10.11.6 'El Capitan' using HSQLDB version 2.x in a 'split' database setup. A freeze occurs as soon as the form-based filter button in the form window is clicked. It is necessary then to force-quit the LibreOffice application. The problem always occurs with LO The problem does NOT happen with LO version
Comment 3 Alex Thurgood 2019-03-11 08:13:41 UTC
No repro with

Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62
Threads CPU : 8; OS : Mac OS X 10.14.3; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

Tested with embedded hsqldb.

@Brent : please indicate which kind of database file your are using, and which controls are present in your form. Ideally, please provide a sample ODB file in which the behaviour is shown.
Comment 4 Alex Thurgood 2019-03-11 08:19:03 UTC
@frofa : neither your macOS version, nor your db setup are commonplace today, so the results you encountered may be specific to your environment.

For example, you don't mention :
- which version of Java you are using ;
- whether, or where, you have added the hsqldb.jar to enable access to the split database - these are known to cause specific issues on macOS and so may interfere with the results of testing.
Comment 5 Alex Thurgood 2019-03-11 08:26:30 UTC
I can reproduce the hang in a form which has a subform, but that was never mentioned in the original bug report.

@Brent : we need more detail from you as to how you form is setup, please provided a sample ODB file that causes the hang with more detailed instructions.

@frofa : did your testing include a main form with a subform - which controls are included ?
Comment 6 frofa 2019-03-11 10:29:42 UTC
@Alex Thurgood : Yes, in my test the form does have a sub-form (plus two additional sub-sub forms). The main form has a simple LIST-BOX control that stores a contact NAME's ID (integer) in a FILTER table, so after selecting a specific CONTACT NAME, the sub-form displays all that contact's details once a REFRESH button is clicked. Also, the CONTACT details sub-form has two additional 'sub-sub' forms to display some additional LISTS of information about the selected contact.

Note: I have another simpler form that does not include the FILTER TABLE setup (as above) but only the 2 'additional information' sub-forms as above-mentioned, and that setup also causes the form-based filter crash as described.
Comment 7 Alex Thurgood 2019-03-11 11:00:35 UTC
@frofa : thanks for the feedback.

We also need Brent to chip in with his setup as currently his report is too vague. If he doesn't have the same or similar setup as what you and I have reported, we can open a separate bug report for our own findings.
Comment 8 Alex Thurgood 2019-03-11 11:12:50 UTC
@frofa : can you write a new report anyway, and put me on CC ? 

I'll confirm it at least for macOS. If you don't want to post a sample embedded db, I have one from another bug report I can resubmit.

If Brent confirms he has a similar setup, we can then mark this as a DUP of that other report.
Comment 9 Brent Warkentin 2019-03-11 12:16:37 UTC
Created attachment 149878 [details]
Base database with Form Issue
Comment 10 Brent Warkentin 2019-03-11 12:17:17 UTC
Sorry I have been traveling... 

The database is used as a address and invoicing database... with 4 tables, a number of queries, one form and a number of reports (Writer and Calc Formats)...

The Form utilizes two of the tables with one main form from one table and one sub form from a second table.  

No issues with Version or earlier...

A sample of the database is attached... removing all but the two tables involved, all real data, and all reports etc. (for privacy reasons)...


When entering or editing data in this form, the total records available changes to "1" and you can't refresh to all records or at least I can't find a way to show all records again.  I must close the form and reopen...  sorry for the second question but I have not been able to find a reason or what to do about this...


Brent Warkentin
Comment 11 Alex Thurgood 2019-03-11 14:41:57 UTC
@Brent : thanks.

Indeed, no hang with 
Build ID: 90f8dcf33c87b3705e78202e3df5142b201bd805
Threads CPU : 8; OS : Mac OS X 10.14.3; UI Render : par défaut; 
Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded

but confirming with

Build ID: 98c6a8a1c6c7b144ce3cc729e34964b47ce25d62
Threads CPU : 8; OS : Mac OS X 10.14.3; UI Render : par défaut; VCL: osx; 
Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Calc: threaded

and test file provided by Brent.

Comment 12 Robert Großkopf 2019-03-11 15:38:10 UTC
With the attached database I could confirm the behaviour. Form based filter didn't work in the form with
Build-ID: 7bcb35dc3024a62dea0caee87020152d1ee96e71
CPU-Threads: 6; BS: Linux 4.12; UI-Render: Standard; VCL: gtk3; 
Gebietsschema: de-DE (de_DE.UTF-8); UI-Sprache: de-DE
Calc: threaded
but works with LO
Comment 13 frofa 2019-07-10 21:35:43 UTC
Is any work being done on this 'high major' importance issue? Users of the form-based filter button on FORMS with SUBFORMS will be unable to upgrade beyond LO/Base v6.1.x if it is not fixed. (Does anyone know a workaround?)