Steps to reproduce: 1. Create a new text document in Writer 2. Add new table, say, 2x2 (doesn't matter, may be reproduced with 1x1) 3. Put caret to cell A1, menu Format->Character->Font Effects->check Hidden 4. Menu View->uncheck Nonprinting Characters (default Ctrl+F10) 5. Show Draw Functions (menu View->Toolbars->Drawing), Draw a Rectangle, so that its top-right corner is above cell A1. This makes the rectangle to be anchored to that cell. Expected result: the rectangle is drawn, and possibly is hidden, as it is anchored to the hidden paragraph Actual result: writer crashes, and recovery dialog hangs, it is impossible to close it gracefully, only task kill helps. Tested with: 4.2.5.2 and 4.3.5.2 under Win7x64. Marking HIGH/CRITICAL as it is crash, affects the component that is used by most users, but the functionality is not very common.
Also reproducible with Version: 4.5.0.0.alpha0+ Build ID: 57626f2132f73e4e42b31e364b25c5867336e718 TinderBox: Win-x86@42, Branch:master, Time: 2014-12-26_09:26:33 Locale: ru_RU and with OOo 3.3.0 under Win7x64 -> Inherited from OOo, as well as with 4.3.5.2 under Ubuntu 14.04 64-bit -> All OS.
TESTING on Ubuntu 14.04 + LO 4.4.0.1 (In reply to Mike Kaganski from comment #0) > Steps to reproduce: > 1. Create a new text document in Writer > 2. Add new table, say, 2x2 (doesn't matter, may be reproduced with 1x1) > 3. Put caret to cell A1, menu Format->Character->Font Effects->check Hidden clicked "OK" > 4. Menu View->uncheck Nonprinting Characters (default Ctrl+F10) Was already unchecked for me. > 5. Show Draw Functions (menu View->Toolbars->Drawing), Draw a Rectangle, so > that its top-right corner is above cell A1. This makes the rectangle to be > anchored to that cell. Ok (I'm not entirely sure about the specifics of where the corners of the rectangle should lie) > Expected result: the rectangle is drawn, and possibly is hidden, as it is > anchored to the hidden paragraph > > Actual result: writer crashes, and recovery dialog hangs, it is impossible > to close it gracefully, only task kill helps. I drew the rectangle, and nothing happened. > > Tested with: 4.2.5.2 and 4.3.5.2 under Win7x64. > > Marking HIGH/CRITICAL as it is crash, affects the component that is used by > most users, but the functionality is not very common. I can't repro. Maybe just an issue on Windows?
(In reply to Robinson Tryon (qubit) from comment #2) > TESTING on Ubuntu 14.04 + LO 4.4.0.1 > > (In reply to Mike Kaganski from comment #0) > > Steps to reproduce: > ... > Draw a Rectangle, so > > that its top-right corner is above cell A1. This makes the rectangle to be > > anchored to that cell. I poked around a bit more, and was able to crash the program if I drew the rectangle as follows: - Top corners in A1 - Bottom corners in A2 > > Actual result: writer crashes, and recovery dialog hangs, it is impossible > > to close it gracefully, only task kill helps. (No recovery dialog for me on Ubuntu) CONFIRMED: Crash on drawing rectangle Status -> NEW
(In reply to Robinson Tryon (qubit) from comment #3) > (No recovery dialog for me on Ubuntu) Yes, you are right. I didn't mention it in comment 1. Also, starting with 4.4.0.0.beta1 under Windows, the recovery dialog no more hangs, and after cancelling it, another error message appears: --------------------------- LibreOfficeDev 4.4 - Fatal Error --------------------------- Unknown SEH Exception --------------------------- ОК ---------------------------
As this is a MAB: Priority -> Highest
On pc Debian x86-64 with master sources updated yesterday or with 4.3 sources updated some days ago, I don't reproduce this even if I begin rectangle at top left of first cell and end it at bottom right of the last cell.
Created attachment 111421 [details] Screencast (Windows) This screencast is to clarify how to reproduce this bug
Created attachment 111493 [details] bt with debug symbols Thank you Mike for your screencast! On pc Debian x86-64 with master sources updated today, I could reproduce the crash, I attached a bt.
Michael: the problem is here: 1593 pAnch = aPos.nNode.GetNode().GetCntntNode()->getLayoutFrm( GetLayout(), &aPoint, 0, false ); 1594 1595 if( !bAtPage ) (see http://opengrok.libreoffice.org/xref/core/sw/source/core/frmedt/feshview.cxx#1593) gdb session indicates that aPos.nNode.GetNode().GetCntntNode() is empty so no pAnch here. Any idea what to do?
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ef3b6fa0cf3e4f2c7b29e9373a8afc8c2c7c7ca0 Related: fdo#87760 don't crash on searching for a place to put the anchor 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: http://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": http://cgit.freedesktop.org/libreoffice/core/commit/?id=15faeb4f9f111f7ea8d04fd64b3d065971cd4570 Resolves: fdo#87760 if we can't anchor at hidden text then... 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: http://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 "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=87eb4fb1a43d799c9ae8df11bd8b9381d2d88cdb&h=libreoffice-4-3 Resolves: fdo#87760 if we can't anchor at hidden text then... It will be available in 4.3.7. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=94506a71fab6f6d6e8d62b02ec78004f85c87aeb&h=libreoffice-4-4 Resolves: fdo#87760 if we can't anchor at hidden text then... It will be available in 4.4.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.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c5b6b206c0e80fae7de4d452334541d2198d41ba sw: redo check in SwFEShell::FindAnchorPos() a bit (related: fdo#87760) 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: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.