| Summary: | [BASE/Table Copy] crash: when repeated Primary Key on Table Copy Wizard. | ||
|---|---|---|---|
| Product: | LibreOffice | Reporter: | sawakaze <souichirho> |
| Component: | Base | Assignee: | Julien Nabet <serval2412> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | CC: | ilmari.lauhakangas, lo_bugs |
| Priority: | highest | Keywords: | haveBacktrace |
| Version: | 5.4.2.2 release | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | target:6.1.0 target:5.4.5 target:6.0.0.2 | ||
| Crash report or crash signature: | Regression By: | ||
| Attachments: |
example .odb, embedded firebird
typescript of gdb session |
||
|
Description
sawakaze
2017-11-18 20:57:47 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 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".
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.
Thanks, Terrence. 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. 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. 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. 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. |