Download it now!
Bug 129542 - CRASH: Setting anchor for a formcontrol to character of pageheader leads to crash
Summary: CRASH: Setting anchor for a formcontrol to character of pageheader leads to c...
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.7.2 release
Hardware: All All
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:7.1.0
Keywords: bibisected, bisected, needUITest, regression
Depends on:
Blocks: Anchor-and-Text-Wrap Crash
  Show dependency treegraph
 
Reported: 2019-12-21 18:38 UTC by Julien Nabet
Modified: 2020-08-31 15:09 UTC (History)
6 users (show)

See Also:
Crash report or crash signature: ["SwFrame::IsVertical()"]


Attachments
Valgrind trace (36.64 KB, text/x-log)
2019-12-21 18:38 UTC, Julien Nabet
Details
bt with debug symbols (8.53 KB, text/plain)
2019-12-21 18:40 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nabet 2019-12-21 18:38:25 UTC
Description:
On pc Debian x86-64 with master sources updated today, I got a crash when using changing Anchor Page to Anchor character.


Steps to Reproduce:
1. Open https://bugs.documentfoundation.org/attachment.cgi?id=156698 (tdf#129524)
2. Set design-mode of the form to "yes".
3. Mark the listfield and set Anchor > To Character.


Actual Results:
Crash

Expected Results:
No crash


Reproducible: Always


User Profile Reset: No



Additional Info:
Comment 1 Julien Nabet 2019-12-21 18:38:57 UTC
Created attachment 156724 [details]
Valgrind trace
Comment 2 Julien Nabet 2019-12-21 18:40:31 UTC
Created attachment 156725 [details]
bt with debug symbols
Comment 3 Robert Großkopf 2019-12-21 19:51:11 UTC
Could confirm the buggy behavior. It's impossible to set a form control into a page header.
Comment 4 Robert Großkopf 2019-12-21 19:52:47 UTC
Have tested it with LO 6.3.4.2, but it could also be inherited from OOo as bug129542
Comment 5 Oliver Brinzing 2019-12-22 09:38:03 UTC
(In reply to Robert Großkopf from comment #4)
> Have tested it with LO 6.3.4.2, but it could also be inherited from OOo as
> bug129542

crashes with AOO 4.1.5
Comment 6 Telesto 2020-04-30 19:14:32 UTC
Crash stats suggest a recent regression
https://crashreport.libreoffice.org/stats/signature/SwFrame::IsVertical()


No repro
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL
Comment 7 Julien Nabet 2020-05-02 08:56:39 UTC
On pc Debian x86-64 with master sources updated today, I gave a new try and don't reproduce the crash anymore with "To Character".

However, I got a crash with "As Character".

Could someone confirm this?
Comment 8 Telesto 2020-05-02 09:10:53 UTC
Yes and no. Setting it paragraph followed by to character = crash. But no crash setting it to character the first time. Didn't check reselecting as to character a second time
Comment 9 raal 2020-08-12 20:25:20 UTC
(In reply to Julien Nabet from comment #7)
> On pc Debian x86-64 with master sources updated today, I gave a new try and
> don't reproduce the crash anymore with "To Character".
> 
> However, I got a crash with "As Character".
> 
> Could someone confirm this?

I can confirm with Version: 7.1.0.0.alpha0+
Build ID: 6ad2f463784a24c566477cdd60ae729651bb8564
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11
Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US
Calc: threaded
Comment 10 raal 2020-08-12 21:24:38 UTC
This seems to have begun at the below commit.
Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one?
Thanks

774506468555179a6274e6418058c48906fcc882 is the first bad commit
commit 774506468555179a6274e6418058c48906fcc882
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Wed May 27 19:03:50 2015 +0800

    source-hash-0a6a151c4b7c78a363fb64598fbda39db4f42d07
    
    commit 0a6a151c4b7c78a363fb64598fbda39db4f42d07
    Author:     Caolán McNamara <caolanm@redhat.com>
    AuthorDate: Wed Feb 11 10:51:13 2015 +0000
    Commit:     Caolán McNamara <caolanm@redhat.com>
    CommitDate: Wed Feb 11 12:00:03 2015 +0000
    
        Related: tdf#70062 keep drawing anchor objects sorted
    
        take attachment from tdf#70062, ungroup the bottom pair,
        anchor as char the left one, anchor as char the right one
    
        asserts with debugging stl on unsorted container
Comment 11 Caolán McNamara 2020-08-13 18:53:37 UTC
I suspect this has ~always been a bit broken. IIRC the story is something like that drawing objects at one point could only appear in the first instance of a header. So after a page break the drawing objects were missing on the next view of the header. Then the feature was implemented so they could appear on all instances of the header. Looks like control forms are left out of that support. In this document for example the form control only appears in the first header instance, its not shown on the other ones.

(maybe it shouldn't have been possible to add a form control into a header, you need to fiddle around with it a bit to force it anchored to something in the header)

The change anchor unsets the form control old anchor, but the code disallows it to anchor into a header/footer so it ends up with no anchor which eventually crashes, e.g. on changing its anchor again.

https://gerrit.libreoffice.org/c/core/+/100686 would allow it to anchor to the first instance of the header (as it initially is imported as) on changing anchor
Comment 12 Commit Notification 2020-08-20 13:44:40 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/6e0c7591ab86a893be85087d3caee0328e9411dd

tdf#129542 the control is already anchored to header/footer content

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 13 Caolán McNamara 2020-08-20 14:28:30 UTC
fixed in master, reluctant to backport for now. Forms controls in header/footers are presumably rare
Comment 14 Julien Nabet 2020-08-20 15:57:22 UTC
Thank you Caolán for the fix, I can confirm it works.(In reply to Caolán McNamara from comment #13)
> fixed in master, reluctant to backport for now. Forms controls in
> header/footers are presumably rare

Thank you Caolán for the fix, I can confirm it works.
I agree with you no need to backport it since a form in header is rather unexpected.