This was found while confirming another bug:
The crash only happens with the error during migration. I did not check if any error or only the error here, but I did check that it is not simply saving as and then starting the migration on an hsql ODB that does not generate an error during migrating and that did not cause a crash.
Steps to Reproduce:
1. Download and open attached ODB file.
2. Click on tables, when prompted to begin migration select 'Later'
3. Save the file with a new name.
4. The migration dialog is displayed again, select 'Yes'
5. The migration function displays a SQL error message, select 'Ok'
Error message box closes.
User Profile Reset: No
Build ID: cb47f0d320994e001bc38dc2ee9b7d957b15e6ab
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2;
Locale: en-US (en_US.UTF-8); Calc: group
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/65.0.3325.181 Chrome/65.0.3325.181 Safari/537.36
Created attachment 141746 [details]
Test file with field type which will trigger needed sql error in the current build of LibO
Confirmed on ubuntu 16.04 x64 with Version: 184.108.40.206.alpha1+
Build ID: e9ac3a9c1ee7689c4d591a68250666c95632bd2a
CPU threads: 2; OS: Linux 4.4; UI render: default; VCL: gtk2;
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-04-27_00:59:01
Locale: en-US (en_US.UTF-8); Calc
Created attachment 141969 [details]
typescript of run and gdb on the core file
Working with dbgutil builds, an assertion upon clicking <Yes> in step
4 (dbaccess/source/filter/hsqldb/createparser.cxx:138) prevents me
from completing the given STR. I hope that the result is helpful for
the current problem, but I am leaving keyword wantBacktrace.
This result is from commit cd1a3db4, pulled 2018-05-07, configured:
built and running on debian-buster.
To help navigation of the attachment from comment 3:
6 run LO
102 run gdb on the core file
161 info threads
198 thread apply all backtrace
630 backtrace of Thread 1
Tamas Bunth committed a patch related to this issue.
It has been pushed to "master":
tdf#117333, tdf#117325 dbahsql: exception handling
It will be available in 6.1.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:
Affected users are encouraged to test the fix and report feedback.
Created attachment 142170 [details]
test file to show conformance
the original test file no longer generates the needed error during import.
This new file will still generate an error, it then runs to completion, given a different patch.
So following the steps this no longer crashes Libo.
When the file is migrated Table1 will generate an error and when it finished Table2 will still have been migrated.