Bug Hunting Session
Bug 112998 - Calc Hangs When Auto-filter Is Set and Row/Column Freeze Enabled and Fcitx Input Method Enabled
Summary: Calc Hangs When Auto-filter Is Set and Row/Column Freeze Enabled and Fcitx In...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.6.1 release
Hardware: All Linux (All)
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: haveBacktrace, possibleRegression
Depends on:
Blocks: Cell-Freeze
  Show dependency treegraph
 
Reported: 2017-10-08 14:30 UTC by Kevin Suo
Modified: 2019-10-02 14:55 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Test ODS File (12.37 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-10-12 01:31 UTC, Kevin Suo
Details
gdbtrace.log (26.58 KB, text/x-log)
2017-11-07 09:00 UTC, Kevin Suo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2017-10-08 14:30:12 UTC
Steps to Reproduce:

1. Create a simple sheet with the following content in column A:
test
1
12

2. Set auto-filter on this column. Then select cell A2 and then click the "Freeze Rows and Columns" toolbar icon.

3. In the drop-down list of the auto-filter, type in "1" in the "Search Item" text box (in order to filter-out the items containing char 1.)


Current Behaviour: 
Calc freezes (not responding) at step 3.


Further Information:
It seems that the bug only exists if the column contains items which have identical chars. In my example above, the item "1" and "12" both contain the char "1".
It is also noted that, in order to reproduce, "Freeze Rows and Columns" must be set.

Version: 5.3.6.1
Build ID: 5.3.6.1-6.fc26
OS: Fedora 26 x64.

P.S.
I am using the LibreOffice version shipped by Fedora. I am not able to test this with the official libreoffice build offered by TDF because of bug 112252.
Comment 1 Xavier Van Wijmeersch 2017-10-08 15:59:38 UTC
Can not reproduce

Version: 5.3.1.2
Build ID: e80a0e0fd1875e1696614d24c32df0f95f03deb2
CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Layout Engine: new; 
Locale: nl-BE (en_US.UTF-8); Calc: group

Version: 5.3.8.0.0+
Build ID: a0fae00a2d52960eebbb14f08d2de251e0a8ff3f
CPU Threads: 8; OS Version: Linux 4.9; UI Render: default; VCL: kde4; Layout Engine: new; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:libreoffice-5-3, Time: 2017-10-05_05:58:12
Locale: nl-BE (en_US.UTF-8); Calc: group

Version: 5.4.3.0.0+
Build ID: cc70f137cd853bc22281edb94f15ebe48da871e7
CPU threads: 8; OS: Linux 4.9; UI render: default; VCL: kde4; 
Locale: nl-BE (en_US.UTF-8); Calc: group
Comment 2 Xavier Van Wijmeersch 2017-10-08 16:12:33 UTC
Sorry spoke to soon. Observation is correct but its not freezing and is responding when inserting the number 1 (step 3), comment 1 is based on four numbers in the drop-down list

Best regards
Comment 3 raal 2017-10-08 20:07:56 UTC
I can not confirm with Version: 6.0.0.0.alpha0+
Build ID: 9127d1a89cbfba89eb9df6755ea7b9e161cfc67a
CPU threads: 4; OS: Windows 6.1; UI render: default;
Comment 4 Kevin Suo 2017-10-09 02:01:02 UTC
Sorry my bad - you need to click "OK" after you type in 1 in the search box.
Comment 5 Kevin Suo 2017-10-11 04:08:10 UTC
I'd rather close this as NOTOURBUG.

I installed LibreOffice 5.4.2 and tested, the bug does not exist. Thus the bug may be because of the build of Fedora 26.

P.S In order to make the TDF build of LibreOffice run in Fedora 26, you need to manually install the "clang" package, as discussed in bug 112252.
Comment 6 Kevin Suo 2017-10-12 01:31:05 UTC
Created attachment 136917 [details]
Test ODS File

Reopened and set to UNCONFIRMED, as I reproduce this in my own build on master.

Steps to Reproduce:
1. In the autofilter dropdown of column A, type in 1 in the search box and click OK.

--> Calc freezes.

Version: 6.0.0.0.alpha0+
Build ID: fbfe55e58c4b14f86cbb2c7b822f727e5b2e4a66
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk3; 
Locale: zh-CN (zh_CN.UTF-8); Calc: group

My autogen.input is as following:
--without-help
--without-java
--without-myspell-dicts
--disable-online-update
--with-lang=zh-CN zh-TW
--with-vendor="Kevin Suo"

(all other build options are using defaults)
Comment 7 Kevin Suo 2017-10-12 01:42:03 UTC
Exiting the input method "Fcitx" will fix the issue.
So there may be some conflicts between LibreOffice and Fcitx.
Comment 8 Peter Nowee 2017-10-12 07:56:10 UTC
Sorry, I cannot reproduce this (#112998) with gtk2 or gtk3 on Debian.

Version: 5.4.1.2.0+
Build ID: 1:5.4.1-1~bpo9+1
CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); Calc: group

Version: 5.4.1.2.0+
Build ID: 1:5.4.1-1~bpo9+1
CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group

(I can still reproduce #85795 with both gtk2 and gtk3.)
Comment 9 Peter Nowee 2017-10-12 07:57:21 UTC
fcitx was running, by the way.
Comment 10 Buovjaga 2017-11-04 18:32:05 UTC
(In reply to Kevin Suo from comment #7)
> Exiting the input method "Fcitx" will fix the issue.
> So there may be some conflicts between LibreOffice and Fcitx.

Hiunn-hué: can you repro with Fcitx?
Comment 11 Hiunn-hué 2017-11-04 20:15:11 UTC
I cannot reproduce it with ...

 Version: 5.4.2.2
 Build ID: 1:5.4.2~rc2-0ubuntu0.16.04.1~lo2
 CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: gtk2; 
 Locale: zh-TW (zh_TW.UTF-8); Calc: group

and

 fcitx 1:4.2.9.1-1ubuntu1.16.04.2+elementary2~ubuntu0.4.1
 fcitx-chewing 0.2.2-1

--

Note:

  I am not using fcitx and therefore not familiar with it, but I still install and enable it to do the test.

  During the test I could input Chinese with fcitx, so fcitx should be working properly, and the Calc didn't freeze after I finished the steps.
Comment 12 Kevin Suo 2017-11-05 01:47:18 UTC
(In reply to Hiunn-hué from comment #11)
In Fedora 26, to install fcitx and reproduce this, do:
1. # dnf install fcitx fcitx-pinyin
2. # exit
3. $ imsettings-switch fcitx
(a message tray will display on the left-bottom of desktop showing fcitx icon.)
4. Click the input source displayed in ibus icon (right-top of the desktop area) as "en" keyboard (i.e., all input methods used by ibus are disabled)
5. You DO NOT need to set the input method as pinyin in fcitx message tray.
6. Reproduce the bug: in calc:
A1: a
A2: 1
A3: 11
set autofilter
put cursor in A2 and freeze first row
type in "1" in the search box of the autofilter dropdown and click OK.
calc hangs

I am trying my best to get a backtrace. But this may take some time.
Comment 13 Kevin Suo 2017-11-07 09:00:05 UTC
Created attachment 137587 [details]
gdbtrace.log

Calc is not crashing - it hangs when you do the filter. To get the backtrace I used CTRL+C.
Comment 14 Kevin Suo 2017-11-07 09:02:16 UTC
An issue is also reported to fcitx issue list:
https://github.com/fcitx/fcitx/issues/377
Comment 15 Xuetian Weng 2017-11-09 01:04:48 UTC
Hi I'm a fcitx developer. So to reproduce this problem the ooo desktop plugin need to be Gtk. Qt(KDE) doesn't have such problem.

IBus and Fcitx have been using such implementation for long time:
https://github.com/fcitx/fcitx/blob/master/src/frontend/gtk2/fcitximcontext.c#L922
https://github.com/ibus/ibus/blob/master/client/gtk2/ibusimcontext.c#L944

And IMHO it is the only way to get the surrounding text in Gtk "on-time". Otherwise, if the surrounding text is not updated before the key event, the input method won't be able to use the up-to-date surrounding text information to process the key event.

I noticed that when after bug is triggered, in spite of the freeze, the memory is increasing dramatically. My guess is that certain function in libreoffice is not reentrant and causes this bug.

My trick on reproducing this bug, is to do a "alt-tab" when the drop down list is opened. I can always reproduce this freeze with this additional step.

I tried to apply some workaround locally, e.g. delay "retrieve-surrounding" signal and emit it later. The issue is gone here. But I don't know if it can be still triggered in some other places. E.g. , we can't delay the retrieve-surrounding signal when handle key event.
Comment 16 Kevin Suo 2017-11-09 02:58:46 UTC
Set to NEW per comment 15.
Comment 17 Peter Nowee 2017-11-12 03:32:27 UTC
With suggestions of Xuetian Weng in comment #15, I can now also reproduce.

Version: 5.4.2.2.0+
Build ID: 1:5.4.2-3~bpo9+1
CPU threads: 2; OS: Linux 4.9; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 18 Kevin Suo 2018-09-30 02:20:22 UTC Comment hidden (obsolete)
Comment 19 Kevin Suo 2018-09-30 02:27:41 UTC
Sorry, comment #18 is a wrong post. Please ignore.

P.s. It would be great if we can delete our own message in bugzilla in case of wrong post.
Comment 20 QA Administrators 2019-10-01 03:01:50 UTC Comment hidden (obsolete)
Comment 21 Peter Nowee 2019-10-02 14:51:13 UTC
I currently cannot reproduce both fcitx-related issues (bug 85795 and
bug 112998) either with gtk2 or gtk3 anymore.

Version: 6.3.2.2
Build ID: 1:6.3.2-1~bpo10+1
CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: gtk2; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

Version: 6.3.2.2
Build ID: 1:6.3.2-1~bpo10+1
CPU threads: 2; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded

However, since the last time I could still reproduce at least one of
the bugs, I upgraded LibreOffice, fcitx and many other components on my
system:

LO           6.1.3.2 (*)  -> 6.3.2.2
fcitx        4.2.9.1-6    -> 4.2.9.6-5
libgtk2.0-0  2.24.31-2    -> 2.24.32-3
libgtk-3-0   3.22.11-1    -> 3.24.5-1
Debian       9            -> 10

* Bug 112998 last tested and reproduced with 5.4.2.2.0+. Bug 85795 with
  LO 6.1.3.2.

So, while something seems to have been fixed somewhere to make the bug
disappear for me, there may still be a problem with LO that let the bug
show up before and maybe let it show up again in the future under
certain circumstances. For example, if a bug was fixed in fcitx to make
this disappear now, LO still should not have hung even if fcitx had a
bug, right?

Of course, there is no need in keeping a report open for a bug that has
become unreproducible, but I cannot assume that just based on my own
report.

Maybe others can confirm that this has become unreproducible for them
as well or someone can point to a specific fix that was made in LO, and
then close this bug.

I will post this in both bugs 85795 and 112998, as they seem very
related. Not sure enough to mark one of them as duplicate, though.
Again, maybe someone else can confirm before doing that.
Comment 22 Buovjaga 2019-10-02 14:55:00 UTC
Thanks, let's close