Description: This was found while confirming another bug: https://bugs.documentfoundation.org/show_bug.cgi?id=117301 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' Actual Results: LibO crashes Expected Results: Error message box closes. Reproducible: Always User Profile Reset: No Additional Info: Tested with: Version: 6.1.0.0.alpha1 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] Example odb 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: 6.1.0.0.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: CC=ccache /usr/bin/gcc CXX=ccache /usr/bin/g++ --enable-option-checking=fatal --enable-dbgutil --enable-debug --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src --without-package-format built and running on debian-buster.
To help navigation of the attachment from comment 3: line what ---- ----------------------- 6 run LO 29 assertion 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": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ea19b96b6beb0ce2f25705339d1d6342dc38b283 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: http://wiki.documentfoundation.org/Testing_Daily_Builds 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.