Description: On pc Debian x86-64 with master sources updated today, LO fails to save a form generated from wizard. I don't reproduce this with LO Debian package 7.0.3 Steps to Reproduce: 1. Open Attachment 2. Open "Use Wizard to Create Form..." 3. Select all the fields of the only table 4. Finish Actual Results: no form Expected Results: a new form Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.1.0.0.alpha1+ Build ID: f7ca7e19942b02b4a19df72a3ca5f6c5fd861887 CPU threads: 12; OS: Linux 5.9; UI render: default; VCL: gtk3 Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
Created attachment 167212 [details] Test file to reproduce this more quickly
Created attachment 167213 [details] console logs
Noel/Caolán: thought you might be interested in this one. Indeed, I noticed this kind of log (see 2nd attachment): warn:legacy.osl:336815:336815:xmloff/source/forms/elementimport.cxx:1832: OColumnWrapperImport::StartElement: AttributeList not clonable! warn:legacy.osl:336815:336815:xmloff/source/forms/elementimport.cxx:1835: OColumnWrapperImport::StartElement: no cloned list! warn:legacy.osl:336815:336815:xmloff/source/forms/elementimport.cxx:1821: OColumnWrapperImport::CreateChildContext: had no form:column element! warn:sax:336815:336815:sax/source/fastparser/fastparser.cxx:615: Unexpected exception from XML parser com.sun.star.xml.sax.SAXException message: FastAttributeList::getValue: unknown token 1051096 /home/julien/lo/libreoffice/sax/source/tools/fastattribs.cxx:246 wrapped: void message: /home/julien/lo/libreoffice/tools/source/debug/debug.cxx:104 I'm not sure but think it might be related to Java stacktrace below: com.sun.star.task.ErrorCodeIOException: SfxBaseModel::handleLoadError: 0x0x4070b0f /home/julien/lo/libreoffice/sfx2/source/doc/sfxbasemodel.cxx:2746 java stack trace: at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method) at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:185) at com.sun.proxy.$Proxy4.createInstanceWithArguments(Unknown Source) at com.sun.star.wizards.db.DBMetaData.addDatabaseDocument(DBMetaData.java:851) at com.sun.star.wizards.db.DBMetaData.addFormDocument(DBMetaData.java:822) at com.sun.star.wizards.form.FormWizard.start(FormWizard.java:353) at com.sun.star.wizards.form.CallFormWizard$FormWizardImplementation.trigger(CallFormWizard.java:75) I know it's not been confirmed yet but it should be very quick to reproduce this.
Not reproducible in Version: 7.1.0.0.alpha1+ Build ID: 03cafc2ab6b1678f82e9a30b6f81e505660ee702 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded debug builds only ?
I could reproduce this even in non debug build. I got only this on console when saving: julien@debianamd:~/lo/libo_perf/instdir/program$ ./soffice /tmp/testjul.odb nov. 12, 2020 10:00:47 PM com.sun.star.wizards.db.DBMetaData addDatabaseDocument GRAVE: null com.sun.star.task.ErrorCodeIOException: SfxBaseModel::handleLoadError: 0x0x4070b0f /home/julien/lo/libo_perf/sfx2/source/doc/sfxbasemodel.cxx:2746 at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method) at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:185) at com.sun.proxy.$Proxy4.createInstanceWithArguments(Unknown Source) at com.sun.star.wizards.db.DBMetaData.addDatabaseDocument(DBMetaData.java:851) at com.sun.star.wizards.db.DBMetaData.addFormDocument(DBMetaData.java:822) at com.sun.star.wizards.form.FormWizard.start(FormWizard.java:353) at com.sun.star.wizards.form.CallFormWizard$FormWizardImplementation.trigger(CallFormWizard.java:75) nov. 12, 2020 10:00:47 PM com.sun.star.wizards.db.DatabaseObjectWizard loadSubComponent GRAVE: null com.sun.star.container.NoSuchElementException: Tasks /home/julien/lo/libo_perf/dbaccess/source/ui/app/AppControllerGen.cxx:415 at com.sun.star.bridges.jni_uno.JNI_proxy.dispatch_call(Native Method) at com.sun.star.bridges.jni_uno.JNI_proxy.invoke(JNI_proxy.java:185) at com.sun.proxy.$Proxy6.loadComponent(Unknown Source) at com.sun.star.wizards.db.DatabaseObjectWizard.loadSubComponent(DatabaseObjectWizard.java:74) at com.sun.star.wizards.form.FormWizard.start(FormWizard.java:354) at com.sun.star.wizards.form.CallFormWizard$FormWizardImplementation.trigger(CallFormWizard.java:75)
Robert: would you have some time to check if you reproduce this? (it's very quick to give it a try) Hope it's not just me or I'll try a "make clean && make" but it'll take quite some time.
Couldn't confirm the buggy behavior with the attached database file and LO 7.1.0.0 alpha 1+ (2020-10-29) on OpenSUSE 15.1 64bit rpm Linux. Wizard will create the form and save it every time
(In reply to Robert Großkopf from comment #7) > Couldn't confirm the buggy behavior with the attached database file and LO > 7.1.0.0 alpha 1+ (2020-10-29) on OpenSUSE 15.1 64bit rpm Linux. > > Wizard will create the form and save it every time Thank you for the quick feedback. Let's "make clean && make" then.
Now I have tested the version LO 7.1.0.0 alpha 1+ (2020-11-13). There the forms are not saved. So I could confirm the buggy behavior for this version.
(In reply to Robert Großkopf from comment #9) > Now I have tested the version LO 7.1.0.0 alpha 1+ (2020-11-13). There the > forms are not saved. So I could confirm the buggy behavior for this version. Thank you Robert! So it's due to a commit between 2020-10-29 and 2020-11-13 (range is large but it's a start).
(In reply to Julien Nabet from comment #10) > (In reply to Robert Großkopf from comment #9) > > Now I have tested the version LO 7.1.0.0 alpha 1+ (2020-11-13). There the > > forms are not saved. So I could confirm the buggy behavior for this version. > > Thank you Robert! So it's due to a commit between 2020-10-29 and 2020-11-13 > (range is large but it's a start). Have had a look with the version from 2020-11-06. This version will save the forms. So between 2020-11-06 and 2020-11-11 (when you reported the bug).
I bisect this to... commit 3de38e95561ab7ca114d9f3307702ba89c4e3e9a Date: Tue Nov 10 19:20:06 2020 +0200 use fastparser in forms Change-Id: I7d09d64857e24267b4b4baddb563e28ceea92f2e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105560 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
I'll have a fix for this soon.
https://gerrit.libreoffice.org/c/core/+/105932
Noel committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/d52f83c7dbeba243aa9cb0f8f129df2fe543a7d3 tdf#138144 Form wizard fails to save It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
With master sources updated today, I don't reproduce this anymore. Thank you Noel for the fix and Caolán for having bibisected it!