Bug 140728 - writer crash on closing in BigPtrEntry::GetArray (this=<error reading variable: Cannot access memory at address 0x38>) at ./sw/inc/bparr.hxx:105
Summary: writer crash on closing in BigPtrEntry::GetArray (this=<error reading variabl...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.0.3.1 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: KDE, KF5
  Show dependency treegraph
 
Reported: 2021-03-01 08:46 UTC by Pascal
Modified: 2023-04-08 19:12 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
crash bt (5.28 KB, text/plain)
2021-03-01 08:46 UTC, Pascal
Details
sample document (26.60 KB, application/vnd.oasis.opendocument.text)
2021-03-08 07:42 UTC, Pascal
Details
Backtrace with 313081c0703c66918e95640c74cd57312a1e8bba reverted (6.96 KB, text/plain)
2021-04-07 12:11 UTC, Michael Weghorn
Details
My tested plasma klipper settings (47.10 KB, image/png)
2021-04-07 13:00 UTC, Jan-Marek Glogowski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pascal 2021-03-01 08:46:57 UTC
Created attachment 170141 [details]
crash bt

got 2 crashes this morning when closing edited existing docs with the X button

I opened an existing doc
modified some text in them
then clicking save as button to save on another name
then click on X button to close the window  ==> crash

Version: 7.0.3.1
Build ID: 00(Build:1)
CPU threads: 8; OS: Linux 5.8; UI render: default; VCL: kf5
Locale: fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR
Ubuntu package version: 1:7.0.3-0ubuntu0.20.10.1
Calc: threaded
Comment 1 Xisco Faulí 2021-03-01 12:07:22 UTC
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Comment 2 Pascal 2021-03-08 07:33:28 UTC
unfortunatly this is a very random occuring bug, so I have not pointed a specific document yet.
Comment 3 Pascal 2021-03-08 07:42:10 UTC
Created attachment 170328 [details]
sample document

I might have found a buggy scenario.

You must be on Kubuntu (maybe) 
You setup klipper to only have an history count of 1 (paste buffer history count)

you start writer
you open the joined doc
you select a few word in it
you press ctrl-c (to copy)

then you close the writer window with the X on the corner
=> crash
Comment 4 Pascal 2021-03-08 07:49:15 UTC
bugs #140700 #140698  might be related
Comment 5 Michael Weghorn 2021-03-08 15:01:21 UTC
(In reply to Pascal from comment #3)
> You setup klipper to only have an history count of 1 (paste buffer history
> count)
> 
> you start writer
> you open the joined doc
> you select a few word in it
> you press ctrl-c (to copy)
> 
> then you close the writer window with the X on the corner
> => crash

I can reproduce a crash using those steps (just selected the "Lorem ipsum" for "a few words")  on Debian testing with a current master build, though my backtrace is different.

Doesn't crash after increasing klipper history size to be larger than 1.

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: c7b898df4d452746399621f6adc8e7da088f0f3a
CPU threads: 12; OS: Linux 5.10; UI render: default; VCL: kf5
Locale: en-GB (en_GB.UTF-8); UI: en-US
Calc: threaded

@Pascal: Setting bugs to status NEW should be done by a person independent from the original reporter, please set from NEEDINFO to UNCONFIRMED next time when answering a question on a bug that hasn't been confirmed by somebody else yet.
Comment 6 Michael Weghorn 2021-03-08 15:02:27 UTC
Didn't crash in a quick test with gtk3 VCL plugin and otherwise same version as in comment 5.
Comment 7 Xisco Faulí 2021-03-09 15:01:05 UTC
(In reply to Pascal from comment #3)
> Created attachment 170328 [details]
> sample document
> 
> I might have found a buggy scenario.
> 
> You must be on Kubuntu (maybe) 
> You setup klipper to only have an history count of 1 (paste buffer history
> count)
> 
> you start writer
> you open the joined doc
> you select a few word in it
> you press ctrl-c (to copy)
> 
> then you close the writer window with the X on the corner
> => crash

This looks like bug 140700, isn't it ?
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Comment 8 Michael Weghorn 2021-03-09 16:09:02 UTC
(In reply to Xisco Faulí from comment #7)
> This looks like bug 140700, isn't it ?
> Could you please try to reproduce it with a master build from
> http://dev-builds.libreoffice.org/daily/master/ ?

It really sounds similar, but is different. The version I used in comment 5 already includes the fix for tdf#140700, but it still crashes for the scenario described here.
Comment 9 Jan-Marek Glogowski 2021-04-06 10:08:11 UTC
So I had a look at this, because I was fixing bug 140404 and was already in the clipboard code. I can't repo any of the crashes with the steps on Debian buster with current master, from any comment. But then there are more Klipper options, like the sync of PRIMARY and CLIPBOARD, which might trigger other code. I checked it doesn't trigger the fix for bug 140404, just in case.

Bug 140700 is about Calc and nothing in this bugs bt (attachment 170141 [details]) indicates Calc and ~SwTransferable() already has equivalent code to the Calc fix:

    SwModule* pMod = SW_MOD();
    if(pMod)

My current idea is, that these kind of bugs are triggered by the workaround for bug 131533. We defer the real clipboard clear handling, but no LO code really expects that. Everything is refcounted, so it should work.
And I can't repo the crash from bug 131533 anymore, if I revert that fix, but the bug 131533 terminal message "QXcbClipboard::setMimeData: Cannot set X11 selection owner" still appears. That also shouldn't be a result from the fix for bug 140700, because bug 131533 was involving Draw, but since I can't repo and it has no attached bt...

So I thought to test Application::IsQuit to catch the shutdown and skip deference, in this case, but that returns false on quit too. Seems Application::Quit is called much later :-(

If someone can repo the crash and has a build, can you check, if 

$ git revert 313081c0703c66918e95640c74cd57312a1e8bba

fixes the crash?
Comment 10 Michael Weghorn 2021-04-07 12:11:44 UTC
Created attachment 171000 [details]
Backtrace with 313081c0703c66918e95640c74cd57312a1e8bba reverted
Comment 11 Michael Weghorn 2021-04-07 12:18:56 UTC
While trying to reproduce, I realized that it doesn't always crash, but depends on how selection is done.

It crashes for this case (the "Lorem Ipsum" used here is the one from the first heading):

0) set Klipper history size to 1, open sample doc
1) double-click on "Lorem" -> "Lorem" gets selected
2) press Shift key + click after the "ipsum" -> "Lorem Ipsum" is selected
3) close LO

It does not crash when doing any of the following instead of steps 1-2:

* press Shift + click after "ipsum" -> "Lorem ipsum" is selected (cursor initially is at the beginning of the doc)
* select "Lorem ipsum" by clicking before the "Lorem", then moving the mouse cursor to after the "ipsum" while keeping the mouse button pressed
* leave out step 2, i.e. only double-click "Lorem" before Ctrl+C and closing the doc

(In reply to Jan-Marek Glogowski from comment #9)
> 
> If someone can repo the crash and has a build, can you check, if 
> 
> $ git revert 313081c0703c66918e95640c74cd57312a1e8bba
> 
> fixes the crash?

Well, I get a crash with a different backtrace (attachment 171000 [details]), which may or may not be what 313081c0703c66918e95640c74cd57312a1e8bba had fixed.
Comment 12 Michael Weghorn 2021-04-07 12:21:11 UTC
@jmux: Adding you in CC due to your question in comment 9 and answer in comment 11, please remove yourself again as needed.
Comment 13 Jan-Marek Glogowski 2021-04-07 13:00:56 UTC
Created attachment 171002 [details]
My tested plasma klipper settings

(In reply to Michael Weghorn from comment #11)
> 0) set Klipper history size to 1, open sample doc
> 1) double-click on "Lorem" -> "Lorem" gets selected
> 2) press Shift key + click after the "ipsum" -> "Lorem Ipsum" is selected
> 3) close LO

No repo. But then your STR doesn't have any more Ctrl+C, like before, but even if I add that before the close (using the window X or Ctrl+w), no crash. Master source + the revert AKA no clean defer.

Maybe it is actually some Qt bug. I'm using Debian Buster, with an old Qt 5.11.3+dfsg1-1+deb10u4. Or a KF5 bug.

But then I couldn't repo bug 131533 with my sample Qt app, so I'm still suspicions, that there is some underlying problem we actually worked around.
Comment 14 Michael Weghorn 2021-04-07 13:52:47 UTC
(In reply to Jan-Marek Glogowski from comment #13)
> (In reply to Michael Weghorn from comment #11)
> > 0) set Klipper history size to 1, open sample doc
> > 1) double-click on "Lorem" -> "Lorem" gets selected
> > 2) press Shift key + click after the "ipsum" -> "Lorem Ipsum" is selected
> > 3) close LO
> 
> No repo. But then your STR doesn't have any more Ctrl+C, like before, but
> even if I add that before the close (using the window X or Ctrl+w), no
> crash. Master source + the revert AKA no clean defer.

My bad, the Ctrl+C between step 2) and 3) is still needed.
Comment 15 QA Administrators 2023-04-08 03:25:14 UTC Comment hidden (obsolete)
Comment 16 Pascal 2023-04-08 19:12:34 UTC
HEllo

no more bug with 7.4.6.2
in kubuntu 22.10