Bug 86494 - segfault whle closing program after "Autocorrect Options..."
Summary: segfault whle closing program after "Autocorrect Options..."
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) Master
Hardware: Other All
: high critical
Assignee: Michael Stahl (allotropia)
Whiteboard: target:4.5.0 target:4.4.0
Keywords: bibisected, haveBacktrace, regression
: 74385 86693 (view as bug list)
Depends on:
Reported: 2014-11-20 17:24 UTC by Terrence Enger
Modified: 2015-12-17 08:39 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

terminal output from crashing job (1.12 KB, text/plain)
2014-11-20 17:27 UTC, Terrence Enger
gdb on the core file (7.66 KB, text/plain)
2014-11-20 17:32 UTC, Terrence Enger
bt with debug symbols (7.99 KB, text/plain)
2014-11-20 19:24 UTC, Julien Nabet

Note You need to log in before you can comment on or make changes to this bug.
Description Terrence Enger 2014-11-20 17:24:42 UTC

(1) Run LO with command-line option --writer.  Program opens Writer
    window "Untitled 1".

(2) Take menu options Tools> "Autocorrect Options..." > Replace.
    Program displays dialog Autocorrect open either at tab Replace or
    at tab "Localized Options".

(3) Click <Cancel>.  Focus returns to "Untitled 1".

(4) Close the program, discarding changes to "Untitled 1".  Observe
    segmentation fault.

These observations are from daily dbgutil bibisect repostiory version
2014-11-20 running in an environment chroot'ed to debian-sid.
Comment 1 Terrence Enger 2014-11-20 17:27:13 UTC
Created attachment 109761 [details]
terminal output from crashing job
Comment 2 Terrence Enger 2014-11-20 17:32:23 UTC
Created attachment 109762 [details]
gdb on the core file

Note that with somewhat longer set of steps, a segmentation fault
happened directly withing SfxItemPool::Put.

Because of skimpy symbols in the backtrace, I am not supplying keyword
Comment 3 Terrence Enger 2014-11-20 17:41:21 UTC
Setting O/S All, as I also see the crash on Windows Vista running

    Build ID: 4f18bd405831c31cd49190046f7bafd805a47d7d
    TinderBox: Win-x86@39, Branch:master, Time: 2014-11-20_09:39:04
    Locale: en_CA

Setting keywoard regression as there is no crash with daily dbgutil
bibisect version 2014-05-21.
Comment 4 Terrence Enger 2014-11-20 18:05:23 UTC
Working in the daily dbgutil bibisect, I see from `git bisect bad`:

    ea2725ba3b5e205d1ae628c7dc1b5335f5d463ad is the first bad commit
    commit ea2725ba3b5e205d1ae628c7dc1b5335f5d463ad
    Author: Miklos Vajna <vmiklos@collabora.co.uk>
    Date:   Thu Nov 6 09:22:12 2014 +0100

        2014-11-06: source-hash-8b21b5cbe78945b27525b4ce78ae3d981f90590f

    :100644 100644 99944723fc60c833ef869ec8ae8ccadc3c45bcc4 3601a2942c77454924406fd63e567c8c56abb0e2 M	build-info.txt
    :040000 040000 55b4ed43a8d22e2af12db913105a1053921fb10f a6cdcb75b71953d56688ea17a0fa4c0997c7f7ad M	opt

and from `git bisect log`:

    # bad: [05f4c71d4862a02ab81f09fcdd536c0cc6dfb128] 2014-11-20: source-hash-d273a60bfdbf9bb7623bed38667ec0647753157c
    # good: [b3130c846de5cf1b4be48b48dfc780bb369549fa] 2014-05-21
    git bisect start 'origin/master' 'oldest'
    # good: [364ba817b97ce3b1d9ce53a2b51235cdb82d6864] 2014-08-21
    git bisect good 364ba817b97ce3b1d9ce53a2b51235cdb82d6864
    # good: [3bd90766c05c07c4a39e36cb1d3106b0016983d4] 2014-10-05
    git bisect good 3bd90766c05c07c4a39e36cb1d3106b0016983d4
    # good: [229fb435cbce6368a809b90a7aa176fb5bd4b0c2] 2014-10-28: source-hash-9997e60ba50483b791c5da3586f3372a3960f5ce
    git bisect good 229fb435cbce6368a809b90a7aa176fb5bd4b0c2
    # bad: [896c41d51775cfb52501476a17929817d15bf963] 2014-11-08: source-hash-c989f5e0e11e295b11ffc921b0d105869e037e47
    git bisect bad 896c41d51775cfb52501476a17929817d15bf963
    # skip: [fc496236778e821413024dc1e37361fc4d9ad23b] 2014-11-02: source-hash-06bde51ced10e9d2997157b91c85d80100b0dafb
    git bisect skip fc496236778e821413024dc1e37361fc4d9ad23b
    # good: [55b9e9c3f5adeb3aaba6f08e7b619552c03453a0] 2014-11-03: source-hash-d9473f25380c627966b4406cc4cdfaafcf44bc37
    git bisect good 55b9e9c3f5adeb3aaba6f08e7b619552c03453a0
    # good: [90a1c59acbcd8a2d11f6bf8d914af71fb558d849] 2014-11-05: source-hash-b7d8a58ff2698ffc6e22943f64aa97c5ea253bd9
    git bisect good 90a1c59acbcd8a2d11f6bf8d914af71fb558d849
    # bad: [7d3277fd5f4135e56eed30c6630f95d344dbbbf4] 2014-11-07: source-hash-0adb90115596ce69e1d80becdaa39e23197fe454
    git bisect bad 7d3277fd5f4135e56eed30c6630f95d344dbbbf4
    # bad: [ea2725ba3b5e205d1ae628c7dc1b5335f5d463ad] 2014-11-06: source-hash-8b21b5cbe78945b27525b4ce78ae3d981f90590f
    git bisect bad ea2725ba3b5e205d1ae628c7dc1b5335f5d463ad
    # first bad commit: [ea2725ba3b5e205d1ae628c7dc1b5335f5d463ad] 2014-11-06: source-hash-8b21b5cbe78945b27525b4ce78ae3d981f90590f

The skipped version, fc49623 ... 2014-11-02, crashed immediately when
I tried to open Tools menu.
Comment 5 Julien Nabet 2014-11-20 19:24:48 UTC
Created attachment 109774 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated today, I could reproduce this.
I attached a bt with symbols.
Comment 6 Julien Nabet 2014-11-20 19:26:08 UTC
Michael: one for you?
Comment 7 Michael Stahl (allotropia) 2014-11-21 21:46:13 UTC
pretty obvious it's a regression from 

commit 4404b718bdb547cb9b7b17c73a53574724cdeeb7
Author:     Daniel Sikeler <d.sikeler94@gmail.com>
AuthorDate: Thu Oct 30 14:53:48 2014 +0000
Commit:     Michael Stahl <mstahl@redhat.com>
CommitDate: Wed Nov 5 11:50:42 2014 +0000

    fdo#79761: parse BlockList.xml only once

i've done a fix already with commit 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d
but it looks like this crash is still happening :(

let's see... how many stupid instance of the container of global variables
anti-pattern do we have in writer... ah... moving the delete to ~SwDLL
seems to help.

fixed on master
Comment 8 Commit Notification 2014-11-21 21:47:11 UTC
Michael Stahl committed a patch related to this issue.
It has been pushed to "master":


fdo#86494: sw: fix crash on exit from SwAutoCorrect

It will be available in 4.5.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:
Affected users are encouraged to test the fix and report feedback.
Comment 9 Terrence Enger 2014-11-22 17:42:23 UTC
I see no crash with LibreOffice versions
(*) daily dbgutil bibisect repo version 2014-11-22
(*) TinderBox: Win-x86@51-TDF, Branch:MASTER, Time: 2014-11-21_23:15:55
On each platform, the one-day-older version did crash.

Once again, thank you, Michael.

Comment 10 Michael Stahl (allotropia) 2014-11-24 20:44:46 UTC
libreoffice-4-4 commit is 0b47dcdce3642e550cdf309b9d46431233cee41b
Comment 11 Caolán McNamara 2014-12-08 12:27:16 UTC
*** Bug 86693 has been marked as a duplicate of this bug. ***
Comment 12 Michael Stahl (allotropia) 2015-04-07 14:14:30 UTC
*** Bug 74385 has been marked as a duplicate of this bug. ***
Comment 13 Robinson Tryon (qubit) 2015-12-17 08:39:39 UTC Comment hidden (obsolete)