Bug 113923 - [BASE/Table Copy] crash: when repeated Primary Key on Table Copy Wizard.
Summary: [BASE/Table Copy] crash: when repeated Primary Key on Table Copy Wizard.
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.4.2.2 release
Hardware: All All
: highest critical
Assignee: Julien Nabet
URL:
Whiteboard: target:6.1.0 target:5.4.5 target:6.0.0.2
Keywords: haveBacktrace
Depends on:
Blocks:
 
Reported: 2017-11-18 20:57 UTC by sawakaze
Modified: 2018-01-10 19:50 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
example .odb, embedded firebird (2.88 KB, application/vnd.oasis.opendocument.database)
2017-12-25 18:46 UTC, Terrence Enger
Details
typescript of gdb session (113.37 KB, text/plain)
2017-12-25 18:49 UTC, Terrence Enger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description sawakaze 2017-11-18 20:57:47 UTC
Description:
Hi, after 10 steps, Libreoffice crashed.

Steps to Reproduce:
In Advance, User created table.

1.open base.
2.select table and right click
3.copy and paste
--> launch Copy table window
4.input Table name, select "Definition and Data"
5.check ON "Create New Field as primary key" and input new primary key name(<- this step is key point)
6.press next
--> launch "Apply Column" 

7.All item apply (press ">>" button) and next.
--> launch "Type formating" window

8. press "Back" button.
--> launch "Apply Column" window

9.press Next button.
--> launch "Type formating" window and added Primary key (Key Point 2)
10. press back button.
--> crash! 

Actual Results:  
crash, on Step 9, duplicate Primary Key.

Expected Results:
not crash, on Step 9, not duplicate Primary Key.


Reproducible: Always


User Profile Reset: No



Additional Info:
Data Base type : HSQLDB
OS : Ubuntu MATE x64

crash report 
http://crashreport.libreoffice.org/stats/crash_details/3ea39710-4110-4e8b-a0a6-cba96bac42a4

this report is version 6.0 alpha1+
I can confirm 2 version

[1]
Version: 6.0.0.0.alpha1+
Build ID: 637d96a25926e299fff5b4cf5a0055b1d171b23b
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-11-17_23:45:59
Locale: en-US (C); Calc: group

[2]
Version: 5.4.1.2
Build ID: 1:5.4.1-0ubuntu1
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: en-US (C); Calc: group



User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0
Comment 1 Buovjaga 2017-11-19 13:32:30 UTC
I don't get a crash. Going back and forth, it keeps creating new duplicates of the key, though.

Maybe you could attach an example file.

Set to NEEDINFO.
Change back to UNCONFIRMED after you have provided the document.

Arch Linux 64-bit
Version: 6.0.0.0.alpha1+
Build ID: 121303615054568c204def97872343d2014af4a0
CPU threads: 8; OS: Linux 4.13; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on November 17th 2017
Comment 2 Terrence Enger 2017-12-25 18:46:25 UTC
Created attachment 138647 [details]
example .odb, embedded firebird

I see the crash with message "attempt to copy from a singular
iterator" in, for example, daily Linux dbgutil bibisect repository
version 2017-12-24 and a local build from 2017-12-11.  LO 5.4.3.2 as
delivered with debian-buster does not crash, but neither does it
create the new table.

For specificity, here are my latest STR:

( 1) Download and open attached a03_fb.odb, an existing embedded
     firebird database with minimal Table1.  Program displays main
     database window with Forms selected in the Database pane.

( 2) "<Alt>+A".  In database pane Tables is selected, and lower right
     pane changes to Tables, showing Table1.

( 3) In Tables pane right-click on Table1.

( 4) From pop-up menu select Copy.

( 5) Right-click on the background of the Tables pane.

( 6) From pup-up menu select Paste.  Program displays dialog "Copy
     table" with default destation table name Table12.

( 7) Select "Create new field as primary key.  The default name for
     the new field is ID.

( 8) Click <Next>>.  Program presents dialog "Apply columns".

( 9) Click the button ">>" to select both existing columns.

(10) Click <Next>>.  Program presents dialog "Type formatting" with
     fields
         (key) ID
         (key) cardinal
               words

(11) Click <<Back>.  Program presents dialog "Apply columns".

(12) Click <Next>>.  Program crashes.

In production LO 5.4.3.2 at step (12) the program again displays
dialog "Type formatting".  The new primary key is named *twice* in the
list of fields, and each execution of <Back><Next> adds another
appearance the name to the list of fields.

I am setting bug status NEW.

In bug summary, I am changing "duplicate Primary Key" to "repeated
Primary Key".
Comment 3 Terrence Enger 2017-12-25 18:49:13 UTC
Created attachment 138648 [details]
typescript of gdb session

The following points in the attachment may be of interest:

    line  what
    ----  --------------------------------
      21  (gdb) set args
      24  (gdb) run
      78  error message
      95  (gdb) info threads
     106  (gdb) backtrace full
     388  (gdb) thread apply all backtrace

This is from a local build of commit 68f7d89c, 2017-12-11, 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.

I am adding keyword haveBacktrace, even though I have to suspect that
the crash is merely the natural result of the repeated field name.
Comment 4 Buovjaga 2017-12-25 18:52:24 UTC
Thanks, Terrence.
Comment 5 Julien Nabet 2018-01-09 21:55:02 UTC
I gave it a try with https://gerrit.libreoffice.org/#/c/47684/
I don't know if the fix is right but I don't reproduce the crash with it.
Let's wait for the review.
Comment 6 Commit Notification 2018-01-10 13:44:08 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c2bc2c4633e92349cac390c05d245d1a812986c4

tdf#113923: don't use twice a new column in table copy

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 7 Commit Notification 2018-01-10 19:45:18 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=71e822bed1131745bb66dc0798b3b8af61f0ec48&h=libreoffice-5-4

tdf#113923: don't use twice a new column in table copy

It will be available in 5.4.5.

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 8 Commit Notification 2018-01-10 19:45:27 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6277990f3ccf3ed9ab5c727670c7f5d15e3c6e7d&h=libreoffice-6-0

tdf#113923: don't use twice a new column in table copy

It will be available in 6.0.0.2.

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.