https://bugs.documentfoundation.org/show_bug.cgi?id=156256
Bug ID: 156256
Summary: Inspecting an object in the Watch Window blocks
Windows
Product: LibreOffice
Version: 7.0.4.2 release
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: BASIC
Assignee: [email protected]
Reporter: [email protected]
Observed with:
Version: 7.0.4.2 (x64)
Build ID: dcf040e67528d9187c66b2379df5ea4407429775
CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render:
Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: de-DE
Calc: threaded
The problem I am going to describe requires me to power off the computer during
heavy disk activities. So far Windows seems to have successfully repaired the
resulting file system corruption. Thus the damage was limited. But I fear that
I am not always that lucky. Therefore I do not want to do additional
experiments and hope that someone has a computing environment that allows to
investigate this problem safely.
I run into this problem when I tried to write a macro that searches through a
complete spreadsheet document. If you want to search a text document you can
use the fact that a text document implements the XSearchable interface.
Spreadsheet documents don’t implement this interface. (See
https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1text_1_1GenericTextDocument.html
,
https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1sheet_1_1SpreadsheetDocument.html
https://api.libreoffice.org/docs/idl/ref/servicecom_1_1sun_1_1star_1_1sheet_1_1SheetCellRanges.html
and
https://api.libreoffice.org/docs/idl/ref/interfacecom_1_1sun_1_1star_1_1util_1_1XSearchable.html
).
Therefore I needed a workaround. An obvious one is to create a SheetCellRanges
object that contains all spreadsheets of the document. I used something like
the following lines of code to create this object:
document = ThisComponent
rangeToSearch = document.createInstance("com.sun.star.sheet.SheetCellRanges")
With document.Sheets
For I = 0 To .Count - 1
rangeToSearch.insertByName("", .getByIndex(I))
Next I
End With
The code seemed to work. rangeToSearch.AbsoluteName contained something that
looked reasonable.
The problem started when I tried to inspect the object in the Watch Window of
the Basic IDE. Nothing bad happened when I placed the variable rangeToSearch
into the Watch Window. Problems started when I tried to click on the plus sign
left of the variable. This should expand the content tree and display the
attributes.
This never happened. Instead the machine started heavy disk activities and
became irresponsive. As I was not able to bring up the task manager using
Ctrl+Alt+Del I had to power off the machine to make it usable again.
I observed a similar effect when I tried to inspect the variable using MRI.
One time I had a resource monitor window open when this happened. In the
resource monitor I could see that memory usage increased quickly before all
physical memory was exhausted and the machine froze.
Thus my current hypothesis is that the inspection of this variable tries to
create data arrays that contain an entry for each cell in the document. As a
spreadsheet has 2^10 columns and 2^20 rows there are 2^30 cells per
spreadsheet. Assuming 8 bytes per entry for a double value this is about 80 GiB
per spreadsheet. This is a lot more than the available physical memory, and a
couple of spreadsheets may fill a complete hard disk. The operation system has
to swap physical memory to disk. Due to the amount of memory this operation may
take quite some time and may lead to other errors, maybe disk full. As swapping
memory is a very basic operation probably the only way to stop it is to power
off the machine.
Expected behavior:
a) Spreadsheet documents should implement the XSearchable interface. This would
avoid the need for this workaround in the first place.
b) Inspecting a variable in the Basic IDE should be a safe operation. Maybe
this would require LibreOffice to enforce some limits on memory usage. This
would be useful in other situations too, e.g. when a memory leak lets
LibreOffice consume all available physical memory. Maybe LibreOffice could use
some kind of lazy evaluation of sparse objects to avoid excessive but
unnecessary memory usage.
--
You are receiving this mail because:
You are the assignee for the bug.
