Bug 114932 - CRASH: Read-only file crashes executing the macro (steps in comment 3)
Summary: CRASH: Read-only file crashes executing the macro (steps in comment 3)
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.0.0.1 rc
Hardware: All All
: highest critical
Assignee: Markus Mohrhard
URL:
Whiteboard: target:6.1.0 target:6.0.1 target:6.0.0
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks: 102078
  Show dependency treegraph
 
Reported: 2018-01-09 14:53 UTC by Tobias Burnus
Modified: 2018-01-18 15:13 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
gdb backtrace (17.35 KB, text/plain)
2018-01-10 15:09 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2018-01-09 14:53:07 UTC
Trying to open attachment 127275 [details] (cf. bug 102075 and bug 102078)

Opens LibreOffice 6rc1 (6.0.0.1 on Windows 7 SP 1 [32bit]) but it shows only a blank background and a blank dialog window with the title WARNING - but nothing more. Clicking on "X" closes that window but leaves a blank window behind.

This works quite reliably, but sometimes it shows the warning text - and clicking "[OK]" worked. Then, LO loaded the document. But after hitting "Edit":
* (read only) in still in the title page
* Clicking the "Auswerten" button shows a dialog (Fatal Error | Name [OK]); clicking OK then crashes LibreOffice.
Comment 1 Xisco Faulí 2018-01-10 12:34:16 UTC Comment hidden (obsolete)
Comment 2 Tobias Burnus 2018-01-10 13:45:29 UTC
BLANK window: I did see initially the same problem with LO-master. However, currently I can no longer reproduce the issue with the blank window - seems to be more illusive as before - but it is still lurking somewhere.


However, I found a reliable way to crash LO - with both versions:
* Version: 6.1.0.0.alpha0+, Build ID: 0074951704022d173a5fdb9df933f47be1dcbb91
TinderBox: Win-x86@42, Branch:master, Time: 2018-01-10_01:01:50
* Version: 6.0.0.1
Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a


For the CRASH:

1. In the web browser, click on the attachment and choose OPEN (not SAVE)
  (This will create a temporary file and LO will open it as *read only*)
  (That's crucial. If I download it first and then open it, the issue
   does not show up.)

2. In the macros-are-disabled dialog, hit [OK] (only choice)
  (Here, LO -> Security -> Macro Security Level is set to "High"
  [unsigned macros are disabled])

3. Click on "Edit Document"
4. Click on the button "Auswerten" in cell D4/D5.

Result:
(3) -> Title bar still shows "(read-only)", even though the document is no longer read only.
(4) -> Shows the '"Fatal Error" "Name" [OK]' dialog and crashes after clicking "OK".
Comment 3 Xisco Faulí 2018-01-10 14:34:08 UTC
Reproduced:

1. Download attachment 127275 [details]
2. Change the file to read-only
3. Open it in LibreOffice
4. Click on Edit Document button
5. Click on Auswerten button
CRASH!

Reproduced in

Version: 6.1.0.0.alpha0+
Build ID: 0ef0740298b45379bbf8d00d50beffee7a2f812a
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded
Comment 4 Xisco Faulí 2018-01-10 14:53:44 UTC
Regression introduced by:

author	Noel Grandin <noel.grandin@collabora.co.uk>	2017-11-22 15:46:20 +0200
committer	Noel Grandin <noel.grandin@collabora.co.uk>	2017-11-22 20:41:21 +0100
commit	5ee141ee2fb77c3cc452ac656235d7e83e15072c (patch)
tree	67d18ed6c87bf4eb72f0af95d8fb0c4e70ef58fe
parent	72ef2b5d9802c424dbb0810e0a72fae50d92b678 (diff)
tdf#113935 Switching from read-only to edit mode slow
Regression introduced by

    commit 389da66dfc96d06c407bff156c4ea21e940c5e06
    remove unused uno::Reference vars

I'm guessing this variable keeps some kind of cache alive which prevents
us from re-parsing the PDF file when we switch to edit mod

Bisected with: bibisect-linux64-6.0

Adding Cc: to Noel Grandin

It doesn't crash before 389da66dfc96d06c407bff156c4ea21e940c5e06 neither
Comment 5 Xisco Faulí 2018-01-10 15:09:36 UTC
Created attachment 139020 [details]
gdb backtrace
Comment 6 Noel Grandin 2018-01-11 08:40:09 UTC
The root of the problem is an UnknownPropertyException, being thrown in the below stacktrace.
Why this happens, however, I have no idea.

#0  com::sun::star::uno::Exception::Exception (this=0x60d2310, Message_="Name", Context_=uno::Reference to (SvxShapeControl *) 0x1f2e438)
    at /home/noel/libo3/workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/uno/Exception.hpp:30
#1  0x00002aaab12a0870 in com::sun::star::beans::UnknownPropertyException::UnknownPropertyException (this=0x60d2310, Message_="Name", Context_=uno::Reference to (SvxShapeControl *) 0x1f2e438)
    at /home/noel/libo3/workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/beans/UnknownPropertyException.hpp:19
#2  0x00002aaab1531c37 in SvxShape::_getPropertyValue (this=0x1f2e438, PropertyName="Name") at /home/noel/libo3/svx/source/unodraw/unoshape.cxx:1729
#3  0x00002aaab1531acb in SvxShape::getPropertyValue (this=0x1f2e438, PropertyName="Name") at /home/noel/libo3/svx/source/unodraw/unoshape.cxx:1715
#4  0x00002aaab1507d59 in SvxShapeControl::getPropertyValue (this=0x1f2e430, aPropertyName="Name") at /home/noel/libo3/svx/source/unodraw/unoshap2.cxx:818
#5  0x00002aaab1508033 in non-virtual thunk to SvxShapeControl::getPropertyValue(rtl::OUString const&) () at /home/noel/libo3/include/cppu/unotype.hxx:232
#6  0x00002aaafbc57bed in ScShapeObj::getPropertyValue (this=0x5b96140, aPropertyName="Name") at /home/noel/libo3/sc/source/ui/unoobj/shapeuno.cxx:827
#7  0x00002aaafbc57d13 in non-virtual thunk to ScShapeObj::getPropertyValue(rtl::OUString const&) ()
    at /home/noel/libo3/workdir/UnoApiHeadersTarget/udkapi/normal/com/sun/star/container/XChild.hdl:25
#8  0x00002aaafb982c06 in ScNavigatorDlg::UpdateSelection (this=0x57cf250) at /home/noel/libo3/sc/source/ui/navipi/navipi.cxx:813
#9  0x00002aaafb982953 in ScNavigatorDlg::Notify (this=0x57cf250, rHint=...) at /home/noel/libo3/sc/source/ui/navipi/navipi.cxx:673
#10 0x00002aaaafd6f9bf in SfxBroadcaster::Broadcast (this=0x14d9bf0, rHint=...) at /home/noel/libo3/svl/source/notify/SfxBroadcaster.cxx:49
#11 0x00002aaafbc9db0d in ScTabViewObj::SelectionChanged (this=0x186e010) at /home/noel/libo3/sc/source/ui/unoobj/viewuno.cxx:1724
#12 0x00002aaafbd1d3fe in ScDrawView::MarkListHasChanged (this=0x5723290) at /home/noel/libo3/sc/source/ui/view/drawview.cxx:528
#13 0x00002aaab111214e in SdrMarkView::MarkObj (this=0x5723290, pObj=0x5a92ec0, pPV=0x575c950, bUnmark=false, bImpNoSetMarkHdl=false) at /home/noel/libo3/svx/source/svdraw/svdmrkv.cxx:1652
#14 0x00002aaab1111ef4 in SdrMarkView::MarkObj (this=0x5723290, rPnt=Point = {...}, nTol=55, bToggle=false, bDeep=false) at /home/noel/libo3/svx/source/svdraw/svdmrkv.cxx:1430
#15 0x00002aaafb8a905a in FuSelection::MouseButtonDown (this=0x166d080, rMEvt=...) at /home/noel/libo3/sc/source/ui/drawfunc/fusel.cxx:251
Comment 7 Markus Mohrhard 2018-01-13 18:09:21 UTC
Simple fix by switching from XPropertySet::getPropertyValue("Name") to container::XNamed::getName.

I'll push the fix in a few minutes to gerrit.
Comment 8 Commit Notification 2018-01-13 21:20:57 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cfa0b631d00f1c17d15646ddcf78093b7f4df03b

shapes provide their name through the container::XNamed interface, tdf#114932

It will be available in 6.1.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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 9 Commit Notification 2018-01-16 11:35:17 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=2c202d82ed024c65e1bde3b93cb14dd4a03bd2a5&h=libreoffice-6-0

shapes provide their name through the container::XNamed interface, tdf#114932

It will be available in 6.0.1.

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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2018-01-17 09:21:18 UTC
Markus Mohrhard committed a patch related to this issue.
It has been pushed to "libreoffice-6-0-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=4f164e45745ee6c1536c30924d3aabaa76d2f005&h=libreoffice-6-0-0

shapes provide their name through the container::XNamed interface, tdf#114932

It will be available in 6.0.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:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Xisco Faulí 2018-01-18 15:13:10 UTC
Verified in

Version: 6.1.0.0.alpha0+
Build ID: 8f28db9515e049fa7e0aa26fe32513e3486dcfaf
CPU threads: 4; OS: Linux 4.10; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: group threaded

Thanks Markus!!