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
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.