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.