Description: Crash swlo!SwFEShell::SelectObj+0x46a when inserting a new shape with cursor still in textbox Steps to Reproduce: 1. Follow the steps as in screencast. Actual Results: Crash Expected Results: No crash Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.alpha0+ (x64) Build ID: 97a2c1fc5e376c0c00968f17a0392c6d3a5ed565 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc:
Created attachment 160496 [details] Screencast For the record, I'm clicking the shape
nice... we write very awesome lyrics of songs... you can play as well as download the songs of new singers... https://lyricsnstatus.xyz/
Created attachment 160543 [details] console logs + bt On pc Debian x86-64 with master sources updated, I got an assertion.
Play & Download the songs & raps sung by New Indian Singers & Rappers for only on <a href="https://www.naayab.com/">Naayab.com</a>
it seems to happen only when inserting a shape from the gallery. I've tried other ways to reproduce it and this is the only one I could find. BTW, the issue is not reproducible with the old gallery, since the images didn't have a textbox
BTW, only happening in Writer, nor in Impress nor Calc
Dear Telesto, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible with the latest LO 7.6 dev master: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bdd96fb801627b0accd81ff33be034c19fe193ba CPU threads: 12; OS: Linux 5.19; UI render: default; VCL: x11 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL threaded Also, various other crashes happen if you try ctrl+z/ctrl+y or other usual actions.
* Crash report from 7.5.8.2 with crash signature SwDrawContact::GetAnchorFrame(SdrObject const*) const : https://crashreport.libreoffice.org/stats/crash_details/ad4786ae-b33b-4c79-9211-1e0f240a32dc * In 7.3.7.2 I get SwFEShell::GetAnchorId() const : https://crashreport.libreoffice.org/stats/crash_details/91aac178-486f-492a-beb2-e385bccdfc9f * In 7.0.6.2, I got SwFEShell::SelectObj : https://crashreport.libreoffice.org/stats/crash_details/2d8c8566-ced7-4aae-8109-dbf67e9eeca2 Still crashing in recent trunk build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: baecfd21797310bb15ab98ca3962445d99e397db CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Once the second shape is inserted, it doesn't crash straight away, and zooming in and out makes it shift across the page. Clicking anywhere crashes. Document Recovery dialog is frozen.
Fix is posted at: https://gerrit.libreoffice.org/c/core/+/161950
Matt K committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/19062c98da5b2e9edc7a99068fa06a83c7578826 tdf#132810 Prevent crashes with gallery objects It will be available in 24.8.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.
Matt K committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/a72dad4e4c0d41b61e453919401fcefc8e5e9b43 tdf#132810 Prevent crashes with gallery objects It will be available in 24.2.1. 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.
Matt K committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/75026d55a5ad58ac2bba790ec89caa38e7f44136 tdf#132810 Prevent crashes with gallery objects It will be available in 7.6.5. 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.
I still get a crash when closing: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 8b393bba91111bd4f8988457f3a78b0306462bf2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Steps: 1. Open Writer 2. Drag-and-drop Gallery > Shapes > Callout-1 onto the page 3. Double-click into callout text box 4. Drag-and-drop same object on page again 5. (optional: Zoom in and out) 6. Close, don't save Results: - first object's position shifts at step 4 - second object's position shifts at step 5 - crash at step 6
(For the record, I also get signature "SwSortedObjs::Remove" in 7.0.6.2: https://crashreport.libreoffice.org/stats/crash_details/26262d64-3508-483a-b987-f756fb1fb5fb)
Fix is tracked in: https://gerrit.libreoffice.org/c/core/+/162349 Thanks for the extra testing Stéphane! It can be hard to test for everything.
Matt K committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6840c242684986483624557a405a00e91ea048e9 tdf#132810 Prevent more crashes on gallery objects It will be available in 24.8.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.
Matt K committed a patch related to this issue. It has been pushed to "libreoffice-24-2": https://git.libreoffice.org/core/commit/d6466f9b1ec73011145d429d120aaaa03b52718b tdf#132810 Prevent more crashes on gallery objects It will be available in 24.2.1. 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.
Matt K committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/b3d710ffd5f63d9c37a61fccc97213d22c4d721f tdf#132810 Prevent more crashes on gallery objects It will be available in 7.6.5. 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.
Sorry Matt, I can still crash it in a trunk build with your latest patch. I could also crash it in earlier versions, e.g. 6.0: https://crashreport.libreoffice.org/stats/crash_details/18058417-d427-4599-8387-2314236b70cd Also in libreoffice-5.1.0.3. Because all stock contents of the Gallery were images prior to 7.0, the trick is to add a shape to a custom gallery theme: 1. Open Writer 2. Gallery > New Theme 3. Insert > Shape > Basic > Rectangle 4. Long-click on shape, then drag and drop it into the new gallery theme 5. Enter text edit mode on rectangle by double-clicking it 6. Drag-and-drop shape from custom theme into document Result: as in comment 14. Another path to crash it: 1. Open Writer 2. Drag-and-drop Gallery > Arrows > curved-right-arrow onto the page (any shape, really) 3. Double-click on shape 4. Drag-and-drop same object on page again 5. Try to rename second object (e.g. using the Navigator) Result: crash. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6d71c21890c908225945f0fc3566255ed150f660 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Created attachment 192126 [details] bt On pc Debian x86-64 with master sources updated today, I got a crash by reproducing the second scenario of Stéphane's last comment. (Clicking on "New" in gallery just makes its properties, that's all so I didn't what to do)
I forgot to tell I had this kind of logs in console: warn:legacy.osl:617492:617492:sw/source/core/frmedt/feshview.cxx:2663: <SwFEShell::GetObjAttr(..)> - missing <pContact>. warn:legacy.osl:617492:617492:sw/source/core/access/accfrmobj.cxx:344: sdr contact is missing warn:legacy.osl:617492:617492:sw/source/core/frmedt/fews.cxx:1308: <SwFEShell::IsFrameVertical(..)> - missing SwContact instance at marked object -> This is a serious situation
I guess the root cause of the crashes and unwanted object movements is the way the Gallery drag-and-drop works: it allows what I assume to be anchoring inside another drawing object. Same issue can be reproduced with all drawing objects, e.g a text box. Also crashes if opening the Position and Size dialog for such inserted drawing object. In the same conditions, drag-and-dropping an image from the Gallery behaves differently: it just doesn't insert anything. Shouldn't we modify the way drag-and-dropping from Gallery works, so it makes sure anchoring consistently goes to Paragraph on the text body? (Just like drawing a shape from toolbar or menu works in same conditions: automatically exiting edit mode first.)
(In reply to Stéphane Guillou (stragu) from comment #23) I can fix the crashes/asserts, but changing the design is something I would need to learn more about, specifically I don't know much about how anchoring works with these objects. Is there any documentation or can someone give some feedback on how this is supposed to work?
(In reply to Stéphane Guillou (stragu) from comment #23) > I guess the root cause of the crashes and unwanted object movements is the > way the Gallery drag-and-drop works: it allows what I assume to be anchoring > inside another drawing object. You mean to dropping a Gallery item onto a shape, which applies the item as background? > Shouldn't we modify the way drag-and-dropping from Gallery works, so it > makes sure anchoring consistently goes to Paragraph on the text body? If at all, then conditionally. Bitmaps should fill the target, if applicable.
(In reply to Heiko Tietze from comment #25) > You mean to dropping a Gallery item onto a shape, which applies the item as > background? No, I was trying to describe the buggy shape-on-shape behaviour. > [...] Bitmaps should fill the target, if applicable. ...but yes, good point! Ctrl+Dropping a bitmap onto a drawing object should fill its area[1], just like Insert > Image does on a selected drawing object. However, in my testing between 6.0 and a recent trunk build, dropping one of the bitmaps in the "Bullets" theme onto a shape actually inserts it into the page body instead of using it as an area fill for the object, even though the shape gets "highlighted" (dashed line around it) when hovering. Have you managed to make that work somehow? I've teste the gtk3 and gen VCL plugins to no avail. [1]: https://help.libreoffice.org/latest/en-US/text/shared/guide/gallery_insert.html
(In reply to Stéphane Guillou (stragu) from comment #26) > Ctrl+Dropping a bitmap onto a drawing object should fill its area Though it was just drag 'n drop. Found bug 127322 and bug 144201, and for some reason we don't have the "Background" images anymore, maybe related bug 153957. Maybe Justin has more insights.
(In reply to Heiko Tietze from comment #27) > Though it was just drag 'n drop. Found bug 127322 and bug 144201, and for > some reason we don't have the "Background" images anymore, maybe related bug > 153957. Maybe Justin has more insights. ...and bug 107081 for culling all the things that don't work from the documentation.
*** Bug 159593 has been marked as a duplicate of this bug. ***