Created attachment 70665 [details] here you can reproduce the problem I try to add a formula making a multiplication between columns of a table and the libreoffice generates a loops. If you try many times generates a crash of Libreoffice an even of the SO.
Verified. (windows XP, 32 bit) The cells are getting tremendously long (over several pages) and the view seems to try to find a region which contains the middle of the cell and the cursor, which is not possible. You can get out of that with ESCAPE, but since it is a seldomly used function, it doesn't fulfill the criteria of a blocker. First I need to find out why the cells are getting long.
On Windows, it was version 3.6.3. Works better in 3.5.4.2 (linux, 64 bit)! and master 4.0 with last commit f2cce815d17ecab4a9440d3cae2064db60fa5d2c So this is mainly a windows - or 32 bit bug. the edited cell doesn't get longer in Linux, (so there is no loop) but the subsequent cells are pushed to the far during edit for some reason. that means the following pages dont contain columns, just an empty table. And the empty area is growing with time, so you cant scroll to the end. It happens when you enter the second operand. I thought Maybe thisis because there are two tables in another, but even then I cant reproduce this with a self-made document - yet...
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.3.5 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) Thank you for your help! -- The LibreOffice QA Team
I do not know, how I could reproduce this. I need step by step instructions.
There is a frame anchored to a paragraph in the header. The frame runs down the right side of the page. It is used for a border that lines up with the tables so that text outside of the tables has a border. Reproduced thusly: 1. Place cursor in Tabla1:D14. 2. Press Formula on toolbar. 3. Click in B14 (two columns over). 4. Type "*". 5. Click in C14. Result: It is at this point that the cell stretchs and the page count increases. Escape. 6. Double click on frame or select Marco2 in Navigator and Delete. 7. Repeat steps 1 through 5. Result: Loopy no more. Unchecking AutoSize of the Height of the frame didn't help. Something interesting is if you change the wrap of the frame to None then it goes into a loop of adding pages. Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Still reproduced in current master. Version: 6.3.0.0.alpha0+ Build ID: 2de1fd7d8b8bd42c66190140cc4506df0c3367f1 Threads CPU : 4; OS : Linux 4.15; UI Render : par défaut; VCL: gtk3; Ubuntu_18.04_x86-64 Locale : fr-FR (fr_FR.UTF-8); Langue IHM : fr-FR Calc: threaded Best regards. JBF
Forgot to add the removing the frame "Marco2" makes the problem not reproducible. Best regards. JBF
Created attachment 151729 [details] bt with debug symbols (gtk3) On pc Debian x86-64 with master sources updated today, I could reproduce the crash.
Comment on attachment 151729 [details] bt with debug symbols (gtk3) Wrong tdf sorry
Sorry for the noise, I commented the wrong bugtracker
On pc Debian x86-64 with master sources updated today, I could reproduce this. Indeed, removing the frame allows to avoid the bug. Michael: thought you might be interested in this old bug still present.
After some gdb session, it seems the loop is in this block: https://opengrok.libreoffice.org/xref/core/sw/source/core/crsr/crsrsh.cxx?r=aebf1925#1830
Created attachment 157087 [details] perf flamegraph Here's a Flamegraph retrieved on pc Debian x86-64 with master sources updated today.
Also in Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 5b025285b3528910a4360899abb2bbbaadc72c97 CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded Without frame everything is quick. With frame is freezing.
> Forgot to add the removing the frame "Marco2" makes the problem not reproducible. Yes, very strange. When I did comment 0's 6+7 first (deleting "Marco2" Frame), then: - Steps 1-5 worked. But if I did Steps 1-5 first: - The layout completely glitched + 100% CPU usage. - - - Also, if I pressed ESC immediately after Step 5: - I was able to "escape", and try 6+7. But if I was too slow: - I was stuck in the 100% glitch/"loop". But if I did something even stranger, and I SCROLLED the vertical bar down immediately after Step 5 (after the table cells went weird): - I was able to stay active. - And I could see the pages infinitely generating/counting up. - I clicked out of LO after I reached page ~350. - - - Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded