Hello, When using 3 filters with the same operator "NOT_EQUAL" the macro hangs if the property "CopyOutputData" is set to True. This occurs following the command : "sheet.filter()" This is not the case with the operator "EQUAL" Regards, P.NOEL
Would it be possible you attach a file with the example so we can try to reproduce this quickly? (by using this link: https://bugs.documentfoundation.org/attachment.cgi?bugid=104865&action=enter) (have in mind that any attachment is automatically made public so remove private /confidential part from it).
Created attachment 129892 [details] Calc macro and file.ods The Calc file has 7 columns and my goal is to display only empty cells column G but being unable to use operator EMPTY I tried to achieve that by using operator NOT=EQUAL. Macro hangs when operator is NOT_EQUAL and oFilterDesc.CopyOutputData is True noe : French version 5.2.3.3 Regards, P. NOEL
The file attached is a "bas" file which contains only the macro. Could you also attach the ods file?
Created attachment 129893 [details] File .ods See attached file
On pc Debian x86-64 with master sources updated today, I could reproduce the hang. However, I could reproduce this either CopyOutputData is TRUE or False or operator is "NOT_EQUAL" or "EQUAL"
Created attachment 129951 [details] bt with symbols I used "Ctrl-C" during the hang to retrieve this bt
Eike: thought you might be interested in this one. I noticed that nRealRow2 was equal to 1048575 (see http://opengrok.libreoffice.org/xref/core/sc/source/core/data/table3.cxx#2996). Since its values comes from aParam which is initialized in lcl_PrepareQuery, thought there must something here. http://opengrok.libreoffice.org/xref/core/sc/source/core/data/table3.cxx#2930
Sorry aParam isn't initialized in lcl_PrepareQuery but upper in the stack, in ScCellRangeObj::filter, from opengrok.libreoffice.org/xref/core/sc/source/ui/unoobj/cellsuno.cxx#5691
** 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 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 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: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still crashes Arch Linux 64-bit Version: 6.4.0.0.alpha0+ Build ID: 37fc9f51a8de11d40632e8cda17ccf1fa4b1f503 CPU threads: 8; OS: Linux 5.2; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 6 August 2019
I investigated the error and I am not 100% sure what causes the problem: The problem starts in https://opengrok.libreoffice.org/xref/core/sc/source/core/data/table2.cxx?r=8cad1620#3825 when nCol reaches the value 64. Then LO enters ScCellValue::release(https://opengrok.libreoffice.org/xref/core/sc/source/core/data/cellvalue.cxx?r=ca16def2#487) and ScColumn::DeleteContent( https://opengrok.libreoffice.org/xref/core/sc/source/core/data/column3.cxx?r=a9753917&fi=DeleteContent#120). The line sc::CellStoreType::position_type aPos = maCells.position(nRow); fails with a call to: template<typename _CellBlockFunc, typename _EventFunc> typename multi_type_vector<_CellBlockFunc, _EventFunc>::position_type multi_type_vector<_CellBlockFunc, _EventFunc>::position(size_type pos) { if (pos == m_cur_size) where pos = 140715552002943 and m_cur_size = 208. HOWEVER, if I'll wait some seconds during the debug process, pos has always the correct value of 0 and the macro works. Is there some timeout or resource waiting problem?
Created attachment 162405 [details] bt with debug symbols Here's an updated bt with master sources updated today.
bt shows: Error: attempt to subscript container with out-of-bounds index 64, but container only holds 64 elements. Objects involved in the operation: sequence "this" @ 0x0x327c220 { type = std::__debug::vector<std::unique_ptr<ScColumn, o3tl::default_delete<ScColumn> >, std::allocator<std::unique_ptr<ScColumn, o3tl::default_delete<ScColumn> > > >; } #5 0x00007fffdc4ee2fc in ScTable::CopyData (this=0x327c220, nStartCol=0, nStartRow=0, nEndCol=1023, nEndRow=0, nDestCol=0, nDestRow=0, nDestTab=0) at sc/source/core/data/table2.cxx:3862 3862 aCell.release(aCol[nDestX], nDestY); Luboš/Noel: the bt retrieved today makes me think about some similar bugs you already fixed so thought you might be interested in this one.
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/ee2d2184133b3bf47d38a03b14abab2caa15dad1 don't add a cell to a non-existent column (tdf#104865) It will be available in 7.1.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.
Hi Luboš Luňák, LibreOffice still hangs in Version: 7.1.0.0.alpha0+ Build ID: a330d8eef09a3135bf6ae94b31b7ea944f256bdc CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded For the record, before https://git.libreoffice.org/core/commit/ee2d2184133b3bf47d38a03b14abab2caa15dad1 LibreOffice crashes, now it hangs
It does not, it's just busy copying all cells that do not equal the criteria, which also all the empty cells in the sheet. If you add a condition that the cell shouldn't be empty, it's fine.
(In reply to Luboš Luňák from comment #16) > It does not, it's just busy copying all cells that do not equal the > criteria, which also all the empty cells in the sheet. If you add a > condition that the cell shouldn't be empty, it's fine. I see, should it be treat as a performance issue in another ticket? I killed LibreOffice after 16 minutes and the macro was still running. Clicking on stop does nothing...
(In reply to Xisco Faulí from comment #17) > > I see, should it be treat as a performance issue in another ticket? Its not a performance issue, as much as: if use you use jumbo sheets you are going to shoot yourself in the foot more easily. There is very little we can do when people try to do calculations across 16 million rows.
Oh never mind, ignore me, this is not a jumbo sheet problem.
Luboš Luňák committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/edca1aa90ad1ec2f8959effc7198f227e3be91d4 don't add a cell to a non-existent column (tdf#104865) It will be available in 7.0.0.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.
(In reply to Xisco Faulí from comment #17) > (In reply to Luboš Luňák from comment #16) > > It does not, it's just busy copying all cells that do not equal the > > criteria, which also all the empty cells in the sheet. If you add a > > condition that the cell shouldn't be empty, it's fine. > > I see, should it be treat as a performance issue in another ticket? I don't understand BASIC scripting much, but AFAICT the macro checks the entire sheet for cells that are not equal to the given strings. And empty cells also are not equal to those strings. Since the macro asks to copy such data, LO ends up copying pretty much the entire sheet. I'd probably keep this as closed until an actual user complains (and explains why LO shouldn't be slow in such a case).
Actually, maybe that's what the bugreport was originally about and the crash came only later. Still, I find it questionable to complain that it takes long to copy an entire sheet based on filters (that are probably poorly specified to being with).
(In reply to Luboš Luňák from comment #22) > Actually, maybe that's what the bugreport was originally about and the crash > came only later. > Still, I find it questionable to complain that it takes long to copy an > entire sheet based on filters (that are probably poorly specified to being > with). checked it in LibreOffice 3.3 and the behaviour is not the same, so at least it's not a regression
Luboš Luňák committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/6c3a6b9685acad171fda7bc5d44b0dd53b9f7268 don't add a cell to a non-existent column (tdf#104865) It will be available in 6.4.6. 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.