Description: clicking the plus (+) button once in the sheet band to add new sheet, end up with creating too many new sheets. Seems to happens only with big files (more than 4 MB size) and with many calculation cells. Happens on .ods, .xls, and .xlsx file format. Steps to Reproduce: 1. open big file 2. add entries in many cells, including cells that contains formulas (calculated) 3. click the add new sheet button (+ button) on sheet band Actual Results: creating a lot of new sheets with auto-filled names, up to Sheet1328 Expected Results: only add one new sheet Reproducible: Sometimes User Profile Reset: No Additional Info: ver 7.1.8.1 (x64) cpu threads 8 Windows 10 build 19042 ui render skia/raster VCL win locale en-id ui en-gb RAM 20GB AMD Radeon Vega Mobile Graphics
Please attach a sample file to reproduce the issue.
Please don't use private mail, BTW I'm Miguel Ángel, not Mike. " From: andhy ch <andhy.ch@gmail.com> Date: Mon, Mar 7, 2022 at 1:58 PM Subject: Re: [Bug 147794] Clicking "Add New Sheet" button (+) once, continuously add new sheets up to Sheet1328 To: <bugzilla-daemon@bugs.documentfoundation.org> Dear Mike, Please find the attached sample file. The file is in .xlsx format and zipped. Some sensitive data has already been removed, so the file size decreased. But many additional new sheets have not been deleted yet. Not long after I reported this bug, the LO also crashed (crash report has automatically been sent too), when I tried to adjust the column width by mouse. You might also experience unusually slow file loading, and strange movement in PL (2) sheet using vertical and horizontal movement buttons and slider ("<", and ">", and in-between bars: please try to click the buttons after some major editing, and the changes are not saved yet). I tried to install a Chinese Simsun font, but it didn't work well to improve the file loading (only some slightly faster). Thank you for your response. "
No problem here clicking on'+', only one sheet it's created. Version: 7.2.6.1 (x64) / LibreOffice Community Build ID: ce99d6a58f9368279ff1495b5b367eb64343b26c CPU threads: 4; OS: Windows 10.0 Build 21390; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL
Thanks for the response, Miguel. I am sorry for my un-familiarity with this bug reporting method. I am still looking for the origin of the problems from certain files that make strange behavior. It does not always happens. Only for files from certain source, with many sheets and big size, and only after I work on the file for hours (doing heavy editing, data addition and calculation cells addition, file auto saving and many time save button click). For comparison, doing the same actions with Microsoft Excel 2013 for the similar file does not create this problem.
[Automated Action] NeedInfo-To-Unconfirmed
Can't it be a hardware failure?
i can kind of confirm... i was confused by the button just ignoring all users actions ( #147868 ) then i finally successfully googled for it and found the reason. The workbook itself is small, but has some nested area-summing formulas and conditional formatting. Also my Win7x64 office computer works noticeably slow this morning, dunno why, maybe admins run HDD backup or something. So, i undone "sheet structure protection" and then probably clicked that [+] button yet seen no action, and perhaps clicked it again, or right clicked, not sure? I also believe (but my memory may be not exact) i then right-clicked on the sheet tabs, i think, to check if context menu now has more items. Well, one way or another in the end i clicked [+] button and saw TWO sheets created. I could not reproduce it - the "execution path" was warmed up and the reaction to that button was instant. However i speculate that if you would reproduce "slow win64 computer" - for example severly downclocking CPU and prohibiting L1/L2 caches in BIOS and do a reboot, then early after login, while Windows Defender antivirus and Windows AutoUpdate would make your HDD (not SSD) busy - you probably would be able to reproduce the GUI slugishness. I speculate when the button is clicked some event is asynchronously enqueued. In Windows that would be PostMessage API, but since OOo/LO use some x-platform toolkit it may be something else. In the end as user keeps clicking getting no reaction from the program - the queue gets many async actions in it. When the code path is finally warmed up - they are rushed to execution all at once. I don't when exactly this happens. Easy fix would be to record "current number of sheets" as a property of the action command to enqueue. Then all "actions" that do not have current counter equal to the recorded one would be ignored. Lazy synchronization. However this presumes GUI itself works almost instantly and the slugishness kicks in later. If those are OS-level events (like WM_MOUSEDOWN GetMessage in Windows case) that are amassed and processed with huge delay as huge batch - then bad luck, this counter marking would not fix it.
Well, I am pretty certain that it is not caused by hardware failure. I have 500GB SSD and 1 TB HDD (plenty of room), 20 GB RAM, AMD Ryzen 5 2500U with AMD Radeon Vega Mobile Graphics, and it is ok for a lot of heavy tasks. Only a certain files from certain source that create the problems. The incidents is occurs on about 30%-40% of .xls(x) / .ods files I work on. It happens only on files with Chinese characters that I have no proper font installed. I cannot find/get the proper font files, due to communication problem with the person I communicate (due to very basic English and only able to do office administrative tasks, and we live in different country). Possibly it create font substitution process for the display, every time I do something that related to display refresh, and make a burden on GUI. It might be a major cause. But this kind of files also makes some subtle problem seen/arise on surface. Let say I open file A and B side-by-side. I made some changes on both, and then I click save button on one of the file. It start the save process, and while it run, I can do nothing on the second file. I have to wait until it finish, before I able to edit the second file.
it is not about outright "failure" it is about being able to fully process that OS message before human notices the delay and presses again what specifically might slow down things in unlucky moment - differs, it is combination of hardware, workbook complexity, LO internal design (scaling), other programs executing on the same computer, etc you "font not found" might trigger such a slow fallback execution path too > It start the save process, and while it run, I can do nothing on the second file. I have to wait until it finish, before I able to edit the second file. Yes, it is typical single-thread design. It is much simpler to both develop and to run, so it was natural choice for old computers. It gambles on the idea that computers are fast enough to finish any activity before human notices slow down. Sometimes it does not happen fast enough though.
(In reply to Dmitry INEC from comment #9) > ...... > > Yes, it is typical single-thread design. It is much simpler to both develop > and to run, so it was natural choice for old computers. > > ...... It is not a single-thread design, you can enable multi-thread in Menu/Tools/Options/LibreOffice Calc/Calculate - CPU Threading Settings, it enables multi-thread calculation of formula-groups.
that is a multi-thread island in otherwise single-thread sea otherwise, while can you not be editing file B while saving file A ?
Well, about multi-threading option, it already enabled since the beginning. I forgot when it enabled exactly, because I already use LO since ver.5. So far I have not much problems. The current problem only come recently (about 2 month), after I receive the files with Chinese characters. But OK, I still able to live with it :-) Regarding the ways LO has designed and developed, I understand the problems that the developers have in the process. With always-changing-environments, many times we have to decide the priority, and usually we have to take non-ideal choices but quite fast and able to reduce the severity (at least). So, I would like to close this discussion, and leave it for long term problem solution, possibly to be solved in the next LO major version.
Hi @andhy, you have opened it, so if you think the best it's close it, then do it, don't hesitate.
Maybe this is related to some bug with XModifyListener (see bug 149482)
andhy, please see Rafael's suggestion. It would be great if you could test version 7.6 and see if you can still reproduce the issue. If not, please set to "resolved - works for me". Thank you!