Created attachment 166667 [details] File to reproduce crash Open attached file. Click on cell A7. Then click in the formula line between = and M. In that situation a info box "You cannot change only part of an array." should come up, but I get a crash. I see the problem in Version: 7.1.0.0.alpha0+ (x64) Build ID: 86d4419c6c4961c8b473decccea99338c176ffe1 CPU threads: 8; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: de-DE (en_US); UI: en-US Calc: threaded
Created attachment 166668 [details] Call Stack VS2019 The error message is Exception thrown: read access violation. **this** was nullptr. occurred
Created attachment 166670 [details] bt with debug symbols On pc Debian x86-64 with master sources updated today, I could reproduce this.
Caolán: thought you might be interested in this one since it might be related with: e087e25f05e689091cbf1c4f91b6e93878ac17ec "weld InputBar"
I gave a try with this patch: diff --git a/sc/source/ui/app/inputwin.cxx b/sc/source/ui/app/inputwin.cxx index 1632ce1f3e09..cf1aaaf272e3 100644 --- a/sc/source/ui/app/inputwin.cxx +++ b/sc/source/ui/app/inputwin.cxx @@ -1533,10 +1533,12 @@ bool ScTextWnd::MouseButtonDown( const MouseEvent& rMEvt ) TextGrabFocus(); } + bool bClickOnSelection = false; if (m_xEditView) + { m_xEditView->SetEditEngineUpdateMode( true ); - - bool bClickOnSelection = m_xEditView->IsSelectionAtPoint(rMEvt.GetPosPixel()); + bClickOnSelection = m_xEditView->IsSelectionAtPoint(rMEvt.GetPosPixel()); + } if (!bClickOnSelection) { rtl::Reference<TransferDataContainer> xTransferable(new TransferDataContainer); It doesn't crash but when selecting another cell in the matrix once I got the expected error popup message "You cannot change only part of an array.", the cell is blank. If I select a cell which is not included in the matrix and select again a cell in the matrix, the formula appears again. With LO Debian package 7.0.2.2, the formula is always present. (I also tried with "bool bClickOnSelection = true;", I got the same.)
Nothing wrong with your proposed fix IMO, so that's as https://gerrit.libreoffice.org/c/core/+/104757 The remaining problem looks sort of odd, but seems to boil down that we throw away the EditView on showing that dialog and we rely on Paint to recreate it if necessary so it has to always call GetEditView() to ensure that which wasn't obvious to me
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/802dc2fec107585dff333edd709a6fc399663df5 tdf#137713 don't crash if there is no m_xEditView 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/37081085fa989aa2fd07a7a0d063295819e185a0 tdf#137713 GetEditView must be called unconditionally in Paint 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.
(In reply to Julien Nabet from comment #3) > Caolán: thought you might be interested in this one since it might be > related with: > e087e25f05e689091cbf1c4f91b6e93878ac17ec "weld InputBar" yep, this is a regression from the mentioned commit
Verified in Version: 7.1.0.0.alpha1+ Build ID: 0f0a5b63b19196f9463149a0a1991704c940efe2 CPU threads: 4; OS: Linux 5.7; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded @Caolán, thanks for fixing this issue!!