Description: Crash rejecting track and changes sorted by author Steps to Reproduce: 1. Open attachment 164757 [details] 2. Edit -> Track changes -> Sort by author (by date doesn't seem to work) 3. Reject all changes by unknown author Actual Results: Crash Expected Results: No crash Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: 6640d7f405d2970ba2825a9455926cc803284d01 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 164774 [details] Bibisect log Bisected to author Tomáš Chvátal <tchvatal@suse.com> 2019-03-20 12:05:39 +0100 committer Tomáš Chvátal <tchvatal@suse.cz> 2019-03-22 11:44:11 +0100 commit 0e4ea2d08a2bf7bda47815ed32b19e70c0d7e905 (patch) tree 341c0dbd9f2ff109cada66774f950cb65d6b0082 parent 2a41c31a0627bf752a625f23a64eaf4d3fe82fb9 (diff) Add few more fixes to build with Boost < 1.56 https://cgit.freedesktop.org/libreoffice/core/commit/?id=0e4ea2d08a2bf7bda47815ed32b19e70c0d7e905
Confirm with: Version: 7.1.0.0.alpha0+ (x64) Build ID: a486fd929d4b3e915f928ef495b6cb2b96d74a3a CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL Rejecting changes by Unknown author one by one leads to crash at the fifth change (counted from the top of the list). Also repro in 6.3.0 but not in 6.2.0
Strangely, no repro here. Possibly Windows-only? Version: 7.1.0.0.alpha0+ Build ID: 217122387f6e0ef657b8ba85eae082b448901cec CPU threads: 16; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to Aron Budea from comment #3) > Strangely, no repro here. Possibly Windows-only? > > Version: 7.1.0.0.alpha0+ > Build ID: 217122387f6e0ef657b8ba85eae082b448901cec > CPU threads: 16; OS: Linux 5.4; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > Calc: threaded Depends what GEN does; GTK3 tends to diverge from the Windows problem
Created attachment 164859 [details] BT of assert when sorting Indeed, it seems to be Windows-only. Adjusting crash report signature, and adding URL here: https://crashreport.libreoffice.org/stats/crash_details/f21cd282-76d7-474e-afe5-cfbb674ac745 In Windows, when trying to sort on Author, I get the following assertion failure (attached): assert(col >= 0 && "cannot sort on expander column"); https://opengrok.libreoffice.org/xref/core/vcl/source/app/salvtables.cxx?r=45649f44#4663 If I comment out the assert, and continue with the procedure, there's another assert after the 5th or so rejection, similarly to comment 2: assert(col >= 0 && o3tl::make_unsigned(col) < pEntry->ItemCount()); https://opengrok.libreoffice.org/xref/core/vcl/source/app/salvtables.cxx?r=45649f44#3952
Created attachment 164860 [details] BT of assert after 5th reject
If the second assert mentioned in comment 5 is removed, the application fails in the next line of code.
Comment on attachment 164774 [details] Bibisect log Assuming the bibisect log is obsolete.
(In reply to Telesto from comment #4) > Depends what GEN does; GTK3 tends to diverge from the Windows problem You are right, it crashes when invoking with "SAL_USE_VCLPLUGIN=gen".
@Caolan This looks like an VCL UI issue, so you might be interested. It's also reproducible with gen backend in contrary to what's stated below. Leave it up to you if a bibisect is needed (In reply to Aron Budea from comment #5) > Created attachment 164859 [details] > BT of assert when sorting > > Indeed, it seems to be Windows-only. > Adjusting crash report signature, and adding URL here: > https://crashreport.libreoffice.org/stats/crash_details/f21cd282-76d7-474e- > afe5-cfbb674ac745 > > In Windows, when trying to sort on Author, I get the following assertion > failure (attached): > > assert(col >= 0 && "cannot sort on expander column"); > https://opengrok.libreoffice.org/xref/core/vcl/source/app/salvtables. > cxx?r=45649f44#4663 > > If I comment out the assert, and continue with the procedure, there's > another assert after the 5th or so rejection, similarly to comment 2: > > assert(col >= 0 && o3tl::make_unsigned(col) < pEntry->ItemCount()); > https://opengrok.libreoffice.org/xref/core/vcl/source/app/salvtables. > cxx?r=45649f44#3952
Bibisected to the following commit using repo bibisect-linux-64-6.3. Before that the list isn't sorted properly when trying to sort on Author, and there's no crash before the commit introducing bug 125589. https://cgit.freedesktop.org/libreoffice/core/commit/?id=418c1d6143dd42e48ef52e0fb8c3d6e5d22c3cfa author Caolán McNamara <caolanm@redhat.com> 2019-06-02 15:52:28 +0100 committer Caolán McNamara <caolanm@redhat.com> 2019-06-03 22:15:54 +0200 Resolves: tdf#125589 we are initially unsorted
looks like its trying to sort when an entry has been added but before the entry is fully populated
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/78876b03874915459f7ebe2135ac146ece92aaf4 Related: tdf#136189 don't assert on unsetting non-existing previous sort column It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dd8313d2c65f0cea68b1ab2aeefb1426b1d3b76c Resolves: tdf#136189 don't try and sort until treeview is filled It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
fixed in master, backport to 7-0 in gerrit
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/c52ac477beefc46802148033adbca9edb9970ac1 Resolves: tdf#136189 don't try and sort until treeview is filled It will be available in 7.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/6c75668ebf3062b087e83c7a3559448d4ceefdeb Resolves: tdf#136189 don't try and sort until treeview is filled It will be available in 6.4.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.