Created attachment 128253 [details] typescript of `make debugrun`; bt full at line 153 One expects to see this error only in a dbgutil build, of course. I found it while I was testing tdf#99717 "EDITING: with certain steps (comment #5) copied table contents does not paste correctly in different document". STR (0) Download (soon-to-be) attached files first.odt and second.odt. (1) Run LibreOffice, naming first.odt and second.odt on command line. (2) In first.odt, select first two columns of the table and copy. (3) In second.odt, select first two columns of the table and paste. Program terminates with messages ... /usr/include/c++/4.8/debug/safe_iterator.h:323: Error: attempt to decrement a singular iterator. Objects involved in the operation: iterator "this" @ 0x0x7f62116ee2a0 { type = (mutable iterator); state = singular; references sequence with type 'std::__debug::deque<unsigned long, std::allocator<unsigned long> >' @ 0x0x7ffe1156f1c8 } Application Error Fatal exception: Signal 6 I see this both in recent versions from the daily Linux dbgutil repository and a local build of master commit cec94a4, pulled 2016-10-14, 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 built and executed on debian-stretch, and in recent versions in the daily Linux dbgutil repository. This attached backtrace is from this build. Working in the daily Linux dbgutil repository, I see from `git bisect bad` ... 038087e58cc6ace6ec0ee2f7d258b51d9514b1ee is the first bad commit commit 038087e58cc6ace6ec0ee2f7d258b51d9514b1ee Author: Miklos Vajna <vmiklos@collabora.co.uk> Date: Fri Sep 2 05:43:54 2016 +0200 2016-09-02: source-hash-91ee1cdce712d50e1e6951bcd7ba82dac50d8038 and from `git bisect log` (whitespace added) ... # bad: [588156d00ce2dea856597f1b17cb43ea2de97c71] 2016-10-18: source-hash-ea7b023115f228406b702c0e6328878b7944d8af # good: [c0512e5ea20f89a047edb75df2a55fb243b2998f] 2016-06-16: source-hash-3ab13873ebb6dc4738be2e2184ee4433a2447c1d git bisect start '588156d00ce2dea856597f1b17cb43ea2de97c71' 'c0512e5ea20f89a047edb75df2a55fb243b2998f' # good: [6c4c998d386b11ef2efe0b1979ece13e5f68a17f] 2016-08-17: source-hash-aa21f8acfa4d4997688ef4ddc04fcf95987e3424 git bisect good 6c4c998d386b11ef2efe0b1979ece13e5f68a17f # bad: [3bf8e246a229c76736fc3594b154378eeb719975] 2016-09-17: source-hash-5b6185d27781d5876d1c6fb18d848a7babdfec88 git bisect bad 3bf8e246a229c76736fc3594b154378eeb719975 # good: [28af858db3dc2d12e13dbd1526a84186f9484b25] 2016-09-01: source-hash-c780c6726dca5e2fe33297e44f25ae3e00703294 git bisect good 28af858db3dc2d12e13dbd1526a84186f9484b25 # bad: [d1d47802d9ed29629a3407f0639dbff80161339d] 2016-09-09: source-hash-6cf44da0395ce5d8dc9cfda838fb15c593507363 git bisect bad d1d47802d9ed29629a3407f0639dbff80161339d # bad: [9be85b75cf2e72c8c0369de8fdb889a530427606] 2016-09-05: source-hash-619d5fceada2df7c7bc915cea51779fd115d0fcd git bisect bad 9be85b75cf2e72c8c0369de8fdb889a530427606 # bad: [67252904b6480cb4ecf29a0e58dc5e802772b5c4] 2016-09-03: source-hash-f7513f0f53f2d074c08610a68fb787bb379c31d4 git bisect bad 67252904b6480cb4ecf29a0e58dc5e802772b5c4 # bad: [038087e58cc6ace6ec0ee2f7d258b51d9514b1ee] 2016-09-02: source-hash-91ee1cdce712d50e1e6951bcd7ba82dac50d8038 git bisect bad 038087e58cc6ace6ec0ee2f7d258b51d9514b1ee # first bad commit: [038087e58cc6ace6ec0ee2f7d258b51d9514b1ee] 2016-09-02: source-hash-91ee1cdce712d50e1e6951bcd7ba82dac50d8038 I am setting keywords regression, bibisected, haveBacktrace.
Created attachment 128254 [details] document to copy from
Created attachment 128255 [details] document to paste to
I'll take a try.
I haven't had the time yesterday to test but could you retrieve an even more recent dbgutil to retest. It seems this one has already been fixed by Caolán, see https://cgit.freedesktop.org/libreoffice/core/commit/?id=1a583283d6b58c8951cb52faac82ecb24fdbf1b3 (2016-10-18 13:03:50 (GMT)) Indeed, I see a reference to "deque" and the quoted fix put back again std::list instead of std::deque.
On pc Debian x86-64 with master sources updated today, I don't reproduce this. If I revert locally, I indeed reproduce this with same symptom ("attempt to decrement a singular iterator") Let's put this one to FIXED then. However, don't hesitate to reopen this tracker if you still reproduce the bug with a more recent LO build.
Caolán: as I put in my previous comment, I could reproduce this one by reverting locally https://cgit.freedesktop.org/libreoffice/core/commit/?id=1a583283d6b58c8951cb52faac82ecb24fdbf1b3. But with this patch: if( rpCol == maCols.end() || *rpCol > rnBorder ) { - maCols.insert( rpCol, rnBorder ); + rpCol = maCols.insert( rpCol, rnBorder ); --rpCol; incColSpan( nLine, rnCol ); } we could keep deque, a container which seems to give more perf than list. Unless, we need capabilites of list? Finally, could we simply use vector instead of deque? Any thoughts?
I'll let noel decide that. I should have mentioned the revert to him at the time but I was focusing on a paste table into table bug of my own and saw the assert and saw that it was new from 9e9e7bd3c9dc9a3149436916e747c7f7ee040621 so just reverted it back to known good state
Noel: any thoughts about this one? I think it could be interesting to replace list by deque and so use the returned iterator from insert call.
Julien, that seems fine, if you test the problem Caolan found, I'd be happy to review such a patch
I see the bug fixed in daily Linux dbgutil bibisect repository version 2016-11-14. I am setting status VERIFIED FIXED.