https://bugs.documentfoundation.org/show_bug.cgi?id=164030
Bug ID: 164030
Summary: Database saving after multiple edits slows down and
eventually crashes, memory leakage?
Product: LibreOffice
Version: 24.2.7.2 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Severity: normal
Priority: medium
Component: Base
Assignee: [email protected]
Reporter: [email protected]
Description:
I just had opened a database which I am using for many years now. I have had
the problem that, when editing a form or some other things in the database (not
editing data entries, but changing the structure of the database in some way),
the database becomes slower and slower up to the point that it cannot be saved,
because the process of saving it would take hours (more than two or three). In
many cases, I had to shut down LO forcefully because I needed to work on other
things and couldn't go on waiting for the saving process to finish.
Today there was again such an issue:
I had added three boolean fields to the database table and wanted to add them
to the form which I use regularly. While adding the three boolean fields to the
form went more or less smoothly (it started lagging already, but I got all
three fields to the position where I wanted them to be), the saving didn't.
After I noticed that Base started lagging again, I immediately hit the save
button in order to save the form and then the database (which is also
required). However, nothing happened except that LO froze. I waited for an hour
and observed during that time, that LO was using CPU power and writing to disk
at some point of time, but I didn't see a temporary file being created or
anything else. The database has a file size of 1.2 MB, but the memory
consumption of LO went up from 1.6 GB to 2.4 GB within a few minutes, and after
an hour or so it crashed (there was still enough RAM available (About 10 GB),
so that couldn't have been the reason).
After reopening and recovering the database, the database file had a size of
about 20 kB, i.e. all data was lost.
Luckily I save every day a copy of the file using a script, usually when the PC
is being started, because after having experienced that problem every now and
then (lets say once in a year, maybe more often), I knew that it can happen any
time, and if there is no recent backup, I would have to reconstruct a database
with about 400 entries, each having about 30 to 40 fields.
Quintessence: Editing the database structure is virtually impossible.
I have observed this behavior for many years, and I guess I have reported it
previously, but couldn't find the report. So I apologize if this is a
duplicate.
Unfortunately, I cannot send you the database in question, because it contains
highly sensitive data.
And another thing: I just tried doing changes in a limited number (maximum 3),
and it worked fine (after each edit save and close the databes, then open it
again and doing the next edit and so on).
But when there are more edits in a row, it gets stuck after a while, LO doesn't
respond as quickly as it usually does and saving becomes impossible.
Steps to Reproduce:
1. Open a database
2. Change structure of the database, add fields and/or change layout of a form,
etc.
3. save the file
Actual Results:
LibreOffice won't save it, but take a very long time and eventually crashes,
losing all data in the database.
Expected Results:
The database is being saved with all changes that have been made.
Reproducible: Always
User Profile Reset: No
Additional Info:
[Information automatically included from LibreOffice]
Locale: de
Module: OfficeDatabaseDocument
[Information guessed from browser]
OS: Linux (All)
OS is 64bit: yes
Additional info:
Operating System: Manjaro Linux
KDE Plasma Version: 6.2.3
KDE Frameworks Version: 6.8.0
Qt Version: 6.8.0
Kernel Version: 6.6.62-1-MANJARO (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 2600 Six-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: AMD Radeon RX 570 Series
Manufacturer: Micro-Star International Co., Ltd.
Product Name: MS-7B79
System Version: 1.0
--
You are receiving this mail because:
You are the assignee for the bug.
