Download it now!
Bug 136189 - Crash rejecting track and changes sorted by author
Summary: Crash rejecting track and changes sorted by author
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.0.4 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.1.0 target:7.0.2 target:6.4.7
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks: Track-Changes
  Show dependency treegraph
 
Reported: 2020-08-27 15:31 UTC by Telesto
Modified: 2020-09-05 09:33 UTC (History)
2 users (show)

See Also:
Crash report or crash signature: ["rtl_uString_acquire"]


Attachments
Bibisect log (2.90 KB, text/plain)
2020-08-27 21:01 UTC, Telesto
Details
BT of assert when sorting (2.53 KB, text/plain)
2020-08-29 22:06 UTC, Aron Budea
Details
BT of assert after 5th reject (5.06 KB, text/plain)
2020-08-29 22:08 UTC, Aron Budea
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-08-27 15:31:27 UTC
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
Comment 1 Telesto 2020-08-27 21:01:27 UTC Comment hidden (obsolete)
Comment 2 NISZ LibreOffice Team 2020-08-28 11:26:33 UTC
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
Comment 3 Aron Budea 2020-08-29 21:44:37 UTC
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
Comment 4 Telesto 2020-08-29 22:00:28 UTC
(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
Comment 5 Aron Budea 2020-08-29 22:06:52 UTC
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
Comment 6 Aron Budea 2020-08-29 22:08:01 UTC
Created attachment 164860 [details]
BT of assert after 5th reject
Comment 7 Aron Budea 2020-08-29 22:14:02 UTC
If the second assert mentioned in comment 5 is removed, the application fails in the next line of code.
Comment 8 Aron Budea 2020-08-29 22:14:47 UTC
Comment on attachment 164774 [details]
Bibisect log

Assuming the bibisect log is obsolete.
Comment 9 Aron Budea 2020-08-30 04:33:41 UTC
(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".
Comment 10 Telesto 2020-08-30 04:49:58 UTC
@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
Comment 11 Aron Budea 2020-08-30 14:58:39 UTC
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
Comment 12 Caolán McNamara 2020-08-31 10:36:53 UTC
looks like its trying to sort when an entry has been added but before the entry is fully populated
Comment 13 Commit Notification 2020-08-31 18:13:45 UTC
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.
Comment 14 Commit Notification 2020-09-01 07:39:27 UTC
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.
Comment 15 Caolán McNamara 2020-09-01 08:11:36 UTC
fixed in master, backport to 7-0 in gerrit
Comment 16 Commit Notification 2020-09-01 11:41:03 UTC
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.
Comment 17 Commit Notification 2020-09-05 09:33:24 UTC
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.