Created attachment 64840 [details] Database could not be opend after opening report-builder for new report I open the report-builder and want to edit a new report. I changed nothing and close the report - not saving the report. I close the database - nothing to save. Then I want to open the database for a second time - the database could not be opened. In META-INF there is the file manifest.xml. When I close LO 3.6.0.4rc this file is changed to 0 kB. This happens every time with the attached file in LO 3.6.0.4rc
Created attachment 64925 [details] Shown a destroyed *.odb-file after report-builder was opened for new report
Created attachment 64926 [details] Shows the undistroyed file - open, try to edit a report. Choose "Create Report in Design View" under LO 3.6.0.4 32bit rpm Linux. The Report_Designer opens. Close the Report-Designer. Close the database and LO. Then open LO and try to open the database. It couldn't be opened, because there is no content in META-INF/manifest.xml.
NOT Reproducible with Server Installation of "LibreOffice 3.6.0.4 rc German UI/Locale [Build-ID: 932b512] on German WIN7 Home Premium (64bit) My Steps: 0. Download sample, 0.1. Start LibO (With inactive Experimental Features) > Start Center appears 1. Open without registering from File Dialog > Document Main View appears 2. Click 'Database Pane -> Reports' 3. 'Tasks Pane -> Create Report in Design View' > Report Builder appears 4. Click into Page Header field > Context related properties appear 5. Menu 'File -> Close' > Report Builder will be closed, Document Main View appears 6. Menu 'File -> Exit' > Document Closed, LibO Terminated Now I restart from 0.1 Everything works fine Linux related? Damaged User Profile? Something completely different? @sasha: Can you check this very urgent problem? @Robert: Of course this one may be very serious, but please do not mark Bugs as "blocker" in this stadium. Unfortunately important information is missing in the report: Please: - Attach screenshots with comments if you believe that that might explain the problem better than a text comment. Best way is to insert your screenshots into a DRAW document and to add comments that explain what you want to show - Contribute a document related step by step instruction containing every key press and every mouse click how to reproduce your problem (similar to example in Bug 43431) – if possible contribute an instruction how to create a sample document from the scratch (did you observe the problem also with an other database?) - add information -- concerning your OS (Version, Distribution, Language) -- concerning your LibO localization (UI language, Locale setting) –- Libo settings that might be related to your problems (Experimental Features activated)? -- how you launch LibO and how you opened the sample document –- If you can contribute an AOOo Issue that might be useful -- everything else crossing your mind after you read linked texts
I have tested this the following way: 1. Destroy the old User-Profile. 2. Start LO. 3. Create a new database. 4. Don't register - I won't work with this database under writer ore another program. ( - ) You can create a little table, put some content in it. I have tested it with a new table and without; same behaviour as followed. 5. Start the Report-Builder (not the wizard). 6. Close the Report-Builder (nothing to save, you haven't created any report) 7. Close the database and LO (nothing to save ...) 8. Open LO 9. Try to open the database. 9a) In German version appears: "Allgemeiner Fehler" ("General Problem") 9b) Base opened, but could not connect to tables ("No Driver-class '' found") There is nothing else to explain with pictures. It's a new profile, a new database. It first appears under 3.6.0.2 (this was the first 3.6-Version I tested). This bug appears every time on my system. My System is OpenSuSE 32bit.
I did not try new Database Table, but sample document again with blank new user profile; still not reproducible. Still ma suspect: Linux related? Particular Java problem? @Robert: What JRE Version do you use? If nobody finds the time to test this problem here with Linux today, you should add someone else to CC who was involved in one of the report builder bugs listed in the Wiki and ask for Help @Julien: Can you help with a test on Linux?
I have just tried it with the following Java: 1. jre1.6.0_29 2. 1.6.0_24 from openjdk 3. jre1.6.0_22 Behaviour is all the same. Create Database, open Report-Creating, close (nothing to save), close LO, try to open the created database again - wouldn't work. LO 3.3.4 presents the "filter-selection" window, when I try to open the file, also LO 3.6, when I don't try to open it from the "Recent Documents".
Just another notice: The database could be reopened, when you do not close LO. But when you close the whole LO it couldn't be opened any more. So the *.odb-file seems to get corrupt while closing LO.
Rainer: sorry, for the moment i only got access to an iphone. I'll be able to test when I come back home, next Saturday.
Another notice: Database is not destoyed in LO 3.6.0.4 on Linux x86-64. Tried this with OpenSuSE 12.1. All persons, who could not confirm this bug, have noticed, that the report-wizard won't work on their systems. Also on Linux x86-64. When I try the report-wizard the whole office will crash. When I try it an Linux x86 (32bit-rpm) the wizard works.
[Reproduced] in 3.6.0.4 on Fedora 64 bit (installed from libreoffice.org) used first attachment and initial description Not reproduced in 3.5.5. Therefore regression Not reproduced in 3.3.4. Writes: "Oracle report builder required".
Problem seems to be: There are a lot of tests, also with Linux, where the database is not destroyed. I tested this with 64-bit-rpm on a OpenSUSE 12.1-System. It works. Other problem with *.deb: Seems to be, that the report-builder could not be closed whithout crashing the whole LO. And another hint: When I don't close the whole LO I can reopen the database. And when I kill the LO-process (Ctrl-Alt-Esc in SuSE) I can also open the database again. The deleting of the *.odb-file happens, when the whole LO is closed in the norml way without any errormessage.
FYI: Given the fact that this issue is reproducible (see comment #10), I have added it to our list of LibO 3.6 most annoying bugs (bug 44446).
On pc Debian x86-64, with master sources updated today, I tried to reproduce the problem by following comment4 (without creating table), I didn't succeed. Base opened normally then I could click on Table tab (but not surprising it's ok since there wasn't any table). I noticed these logs during closing anyway: warn:legacy.osl:9759:1:/home/julien/compile-libreoffice/libo/dbaccess/source/core/dataaccess/ModelImpl.cxx:926: caught an exception! in function:static bool dbaccess::ODatabaseModelImpl::commitStorageIfWriteable_ignoreErrors(const com::sun::star::uno::Reference<com::sun::star::embed::XStorage>&) type: com.sun.star.uno.RuntimeException message: unsatisfied query for interface of type com.sun.star.io.XStream! warn:legacy.osl:9759:1:/home/julien/compile-libreoffice/libo/dbaccess/source/core/dataaccess/ModelImpl.cxx:832: ODatabaseModelImpl::commitRootStorage: could commit the storage! warn:legacy.osl:9759:1:/home/julien/compile-libreoffice/libo/unotools/source/config/configmgr.cxx:208: OSL_ASSERT: items_.empty()
Created attachment 65142 [details] bt + console msgs on master I reproduced the crash (with same config than my previous comment). This time, i created a table with some lines in it, noticed these logs during first insert: warn:legacy.osl:10009:1:/home/julien/compile-libreoffice/libo/dbaccess/source/core/api/RowSetCache.cxx:851: ORowSetCache::moveWindow: m_nStartPos not smaller than m_nEndPos warn:legacy.osl:10009:1:/home/julien/compile-libreoffice/libo/dbaccess/source/ui/browser/genericcontroller.cxx:1343: SbaTableQueryBrowser::openHelpAgent: could not get a dispatcher! Then I saved the table, launch report creation (without using wizard), then cancelled so no report. Finally I closed LO and had a crash.
Sorry, the line "warn:legacy.osl:10009:1:/home/julien/compile-libreoffice/libo/dbaccess/source/ui/browser/genericcontroller.cxx:1343: SbaTableQueryBrowser::openHelpAgent: could not get a dispatcher!" appeared only when I launched report creation not during insert. I tried the same with 3.6 sources updated today, I had the same behaviour. BTW, here are my Java info: java version "1.6.0_24" OpenJDK Runtime Environment (IcedTea6 1.11.3) (6b24-1.11.3-2) OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
Now there are more tests, that reproduced the bug. Problem: we can not describe the configuration by, for example, "Linux - all". In mailinglists I heard, that it works with *.deb 32bit (Ubuntu) and 64bit (Debian). An here Julien reported: crash. (Comment 14) I tested with OpenSuSE 11.4, 32bit rpm - *.odb has beeen destroyed. With OpenSuSE 12.1, 64bit rpm it works. And here Sasha reported: crash. (Comment 10) One day ago I had the same crash-problem with all wizards (I have not tested it before). Could you please have a look on https://bugs.freedesktop.org/show_bug.cgi?id=53115 ?
In my case was not a crash. All was looking correctly. But during exiting of office ODB file becomes slightly shorter. And next time this file impossible to open.
Hi Sasha, what OS are you using? The problems don´t occur using Windows as OS, but only using Linux (also bug 53115).
Linux Fedora 64 bit
I have tested it now on another PC with OpenSuSE 11.4, 32bit rpm. There it works. So I had a look at the difference between the same systems, both working with KDE. The GUI in the system, which could reopen the databases, looks rather old - don't know why, but it's the same in LO 3.3.4 an this system. When I want to save or open a file an old Gnome-dialog appears. I haven't installed the whole Gnome on this machine, because I am working with KDE. Seems, that the integration in KDE won't work right. Another hint for this system: When I start LO at the shell I see: GLIBCXX_3.4.11 not found. This system hasn't all the repositories with very new software integrated. I have a 64-bit-rpm-System, where it looks like this description - and there databases could be reopened too. The system, which could not open databases, when used the report-builder, shows a integrated design to KDE. When I want to open a file ore save a file an old KDE-dialog appears - looks like the old konqueror from KDE 3. It is the first time in LO, that a system-Dialog for saving and opening appears in this system. @sasha: which GUI is on your machine?
KDE 4 and Gnome 3. Reproducible on both (corruption of odb in 3.6.0) Installed using rpm files from libreoffice.org. No desktop integration modules installed. User profile is fresh.
Reproduced odb corruption also on Linux Alt6 64 bit, KDE. Used the same installation files as for Fedora.
Experimented also on Windows XP 32 bit with 3.6.0: After exiting LibreBase window disappears, but program remains in memory. Impossible to start office again. I need use Ctrl-Alt-Del and kill soffice.bin. Only then possible to start LibreBase again. What about odb file: during exiting of office this file changes (no propose to save changes, just silent saving). But remains openable.
Cannot reproduce with freshly created embedded HSQL database with LibreOffice 3.6.0.4 (Build ID: 932b512) (official deb binaries) on Debian GNU/Linux amd64.
Cannot reproduce with attachment 64926 [details] with LibreOffice 3.6.0.4 (Build ID: 932b512) (official deb binaries) on Debian GNU/Linux amd64.
> After exiting LibreBase window disappears, but program remains in memory. Yes, I also already saw that effect, but I did not see a possible relation to the problem here. I will watch that more carefully.
I tried to reproduce and found a crasher when closing report wizard, please see the bug 53154. I wonder if it might be related. Otherwise, I can find a way to reproduce this problem. I am afraid that it is a memory corruption and it behaves different way on different systems.
(In reply to comment #27) > <snipp> I am afraid that it is a > memory corruption and it behaves different way on different systems. Hi Petr, what do mean with "memory corruption": main memory = ram = physical defect or a problem in the code of LO?
Created attachment 65173 [details] valgrind logs on master I retrieved Valgrind logs if it can help.
This bug describes, that the creating of a report destroys *.odb-files. The only system, where this happens - as I see from the comments - is Linux with *.rpm-packages 32bit and 64bit. And it didn't happen with every system, where these packages are installed. Only person, which has reproduced and commented it here is sahsha (comment 10 and comment 22) There are other problems with the wizard of the report-builder. This is reported in https://bugs.freedesktop.org/show_bug.cgi?id=53154 . The problems with the wizard seem to be problems of *.deb-packages. The bug reported here has nothing to do with the wizard. Only opening and closing of "Create Report in Design View" without saving anything is, what I make in LO-Base. I close normally without any problem Base. When I reopen at this moment the database it works - but only at this session. When I close LO in the normal way the database-file is corrupted. When I close LO by killing the process the database could be opened again.
Here is the difference between those versions of Linux-rpm, which don't destroy the database by editing a report (or opening a wizard) and on the other hand, which destroy databases. The following I see on the shell, when LO works in the right way with databases: (soffice:2011): Gtk-WARNING **: /opt/libreoffice3.6/program/../ure-link/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/gtk-2.0/2.10.0/engines/liboxygen-gtk.so) You see a warning on every *.rpm-version, which works with LO and base in the right way, don't destroys databases and looks a little bit like very old Gnome-desktop. The dialog for opening files in LO is an old Gnome-dialog - under KDE. This warning didn't appear at systems, which destroy the database in the way I have written in the former comments.
Is the "stdlibs" rpm provided by LibreOffice installed on the affected systems? If it is, try to uninstall it. If it is not, try to install it. In all cases, please report results before/after.
(In reply to comment #32) > Is the "stdlibs" rpm provided by LibreOffice installed on the affected systems? It has been installed. Databases were corrupted after closing LO. > > If it is, try to uninstall it. Have uninstalled it, tested - same problem. I think the version stdlibs of LO is for "old" Linux-Systems. But the systam I have is updated with all patches ...
(In reply to comment #33) > (In reply to comment #32) >> Is the "stdlibs" rpm provided by LibreOffice installed >> on the affected systems? >> If it is, try to uninstall it. > Have uninstalled it, tested - same problem. Drats. > I think the version stdlibs of LO is for "old" Linux-Systems. > But the systam I have is updated with all patches ... Exactly; but if it is installed, it is always used, even on newer systems. This can cause problems with *other* components (such as QT or GTK+ themes) that expect a newer stdlibs than what is distributed with LibreOffice. That's why it is recommended to install the LO stdlibs only if necessary. (if the stdlibs on the systems are *older* than the ones distributed with LibreOffice, using the LO ones should AFAIK not hurt.) I think the "looks like a very old Gnome" that you report is caused by the presence of LibreOffice's stdlibs: the GTK+ theme cannot be loaded. That's the meaning of the warning you report: (soffice:2011): Gtk-WARNING **: /opt/libreoffice3.6/program/../ure-link/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found (required by /usr/lib64/gtk-2.0/2.10.0/engines/liboxygen-gtk.so) You should get this warning if and only if the LO stdlibs are installed (on a system where the GTK themes have been compiled against a newer stdlibs than what is shipped with LO). As you were reporting that the warning is linked to presence of this bug, my hunch was that there was something about the stdlibs in LO or on the system that caused something to go wrong.
In other words: this message not connected with this problem.
"Is the "stdlibs" rpm provided by LibreOffice installed on the affected systems?" Little hint: When I uninstall it on the machines, were the bug didn't appear and the GTK-Warning appears, the GTK-Warning has gone and LO uses the dialog of my system (KDE, Dolphin). Good for my eyes, but didn't solve the problem directly. Its the system, where stdlibs seems nothing to do and the dialogs look like old konqueror-dialogs of KDE - with stdlibs and without stdlibs. The bug happens under KDE and Gnome, so it isn't a connection between KDE and LO.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=142d3ec875b446b56d0071c59d00937dea0cdd61 Related fdo#52639: Do not destroy Implementations with mutex locked
(In reply to comment #37) > Stephan Bergmann committed a patch related to this issue. > It has been pushed to "master": > > http://cgit.freedesktop.org/libreoffice/core/commit/?id=142d3ec875b446b56d0071c59d00937dea0cdd61 > > Related fdo#52639: Do not destroy Implementations with mutex locked That commit addresses the crash from comment 14 upon exiting LO (and I intend to get it backported to LO 3.6.1; it is a regression introduced with the new service manager in LO 3.6.0). I consider that crash unrelated to the problem discussed in this issue, though.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=fdcd1655b1648f078289c5ac8a1c075c71e6e6df&g=libreoffice-3-6 Related fdo#52639: Do not destroy Implementations with mutex locked It will be available in LibreOffice 3.6.1.
after trying out a lot of things, i have to disagree with Stephan for once :) first, the corruption problem does not occur in a "dev-install" installation with symlinks; i could only reproduce it by building "archive" instsets and running those; i only mention this because finding this out wasted a lot of time :( then it seems that the commit in comment #37 actually _does_ fix the corruption problem. i don't know exactly why that is, but my guess is that at shutdown some attempt is made to save the document while the ServiceManager is being disposed, and that happened to "partially" succeed before the commit in such a way that a corrupted document was produced, while with the commit it fails completely. please somebody verify this in tinderbox builds that have the fix.
(In reply to comment #40) > > please somebody verify this in tinderbox builds that have the fix. Where could I get these builds. Is it difficult to install for somebody, who only installs *.rpm with a packagemanager?
(In reply to comment #41) > > Where could I get these builds. Is it difficult to install for somebody, who > only installs *.rpm with a packagemanager? you can find them here: http://dev-builds.libreoffice.org/daily/ it's not obvious to tell which upload has the fix, but looking at the git hashes in the *_build_info.txt it seems that this one should have the fix: http://dev-builds.libreoffice.org/daily/Linux-Fedora17-x86_64@4-gcc-4.7-dbgutil/master/2012-08-10_05.55.24/
*** Bug 53115 has been marked as a duplicate of this bug. ***
forgot to mention: with a 3.5.5 dbgutil build where the bug does NOT happen i get this telling assertion on shutdown: dbaccess/source/core/dataaccess/ModelImpl.cxx:937: caught an exception! in function:static bool dbaccess::ODatabaseModelImpl::commitStorageIfWriteable_ignoreErrors(const com::sun::star::uno::Reference<com::sun::star::embed::XStorage>&) type: com.sun.star.lang.DisposedException message: service manager instance has already been disposed! context: N9stoc_smgr23ORegistryServiceManagerE dbaccess/source/core/dataaccess/ModelImpl.cxx:843: ODatabaseModelImpl::commitRootStorage: could commit the storage! in 3.6, with the fix i get a slightly different assertion about some XStream interface missing, and without the fix i get no assertion on shutdown. that's why i think something tries to save the document on shutdown, and this has always failed until the new service manager in 3.6. i wonder if _trying_ to save the document at this stage in shutdown is a bug by itself, and what to do about that; Lionel can think about this problem if he likes :)
I have verified, that it works now with Version 3.6.1.0+ (Build ID: cd656ac). The problem with the wizards has also gone. Thank you, it took a load of my mind.
*** Bug 53854 has been marked as a duplicate of this bug. ***
*** Bug 53910 has been marked as a duplicate of this bug. ***