Bug Hunting Session
Bug 117325 - Firebird: Migration: Starting migration on file saved in current session and which generates SQL error during migration crashes LibO
Summary: Firebird: Migration: Starting migration on file saved in current session and ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
6.1.0.0.alpha1+
Hardware: All All
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:6.1.0
Keywords: wantBacktrace
Depends on:
Blocks: Database-Firebird-Migration
  Show dependency treegraph
 
Reported: 2018-04-28 22:28 UTC by Drew Jensen
Modified: 2018-05-17 19:12 UTC (History)
3 users (show)

See Also:
Crash report or crash signature: ["libdbulo.so"]


Attachments
Example odb (4.20 KB, application/vnd.oasis.opendocument.database)
2018-04-28 22:30 UTC, Drew Jensen
Details
typescript of run and gdb on the core file (75.54 KB, text/plain)
2018-05-08 13:21 UTC, Terrence Enger
Details
test file to show conformance (3.19 KB, application/vnd.oasis.opendocument.database)
2018-05-17 19:12 UTC, Drew Jensen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Drew Jensen 2018-04-28 22:28:40 UTC
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
Comment 1 Drew Jensen 2018-04-28 22:30:20 UTC
Created attachment 141746 [details]
Example odb

Test file with field type which will trigger needed sql error in the current build of LibO
Comment 2 MM 2018-04-28 23:37:06 UTC
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
Comment 3 Terrence Enger 2018-05-08 13:21:30 UTC
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.
Comment 4 Terrence Enger 2018-05-08 13:24:38 UTC
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
Comment 5 Commit Notification 2018-05-16 09:11:49 UTC
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.
Comment 6 Drew Jensen 2018-05-17 19:12:29 UTC
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.