Bug 52639 - ReportBuilder: Creating a new report destroys .odb
Summary: ReportBuilder: Creating a new report destroys .odb
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
3.6.0.4 release
Hardware: All Linux (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:3.7.0 target:3.6.1
Keywords: regression
: 53115 53854 53910 (view as bug list)
Depends on:
Blocks: mab3.6
  Show dependency treegraph
 
Reported: 2012-07-29 17:25 UTC by Robert Großkopf
Modified: 2012-08-26 11:00 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Database could not be opend after opening report-builder for new report (744.97 KB, application/vnd.sun.xml.base)
2012-07-29 17:25 UTC, Robert Großkopf
Details
Shown a destroyed *.odb-file after report-builder was opened for new report (3.05 KB, application/vnd.sun.xml.base)
2012-07-29 19:36 UTC, Robert Großkopf
Details
Shows the undistroyed file - open, try to edit a report. (3.22 KB, application/vnd.sun.xml.base)
2012-07-29 19:42 UTC, Robert Großkopf
Details
bt + console msgs on master (26.33 KB, text/plain)
2012-08-05 12:17 UTC, Julien Nabet
Details
valgrind logs on master (26.40 KB, application/x-gzip)
2012-08-06 12:43 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2012-07-29 17:25:58 UTC
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
Comment 1 Robert Großkopf 2012-07-29 19:36:46 UTC
Created attachment 64925 [details]
Shown a destroyed *.odb-file after report-builder was opened for new report
Comment 2 Robert Großkopf 2012-07-29 19:42:09 UTC
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.
Comment 3 Rainer Bielefeld Retired 2012-07-30 03:06:45 UTC
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
Comment 4 Robert Großkopf 2012-07-30 05:49:43 UTC
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.
Comment 5 Rainer Bielefeld Retired 2012-07-30 06:20:27 UTC
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?
Comment 6 Robert Großkopf 2012-07-30 06:55:17 UTC
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".
Comment 7 Robert Großkopf 2012-07-30 08:22:12 UTC
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.
Comment 8 Julien Nabet 2012-07-30 08:32:56 UTC
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.
Comment 9 Robert Großkopf 2012-07-30 09:21:24 UTC
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.
Comment 10 sasha.libreoffice 2012-08-02 07:19:20 UTC
[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".
Comment 11 Robert Großkopf 2012-08-02 07:45:46 UTC
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.
Comment 12 Roman Eisele 2012-08-05 10:17:06 UTC
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).
Comment 13 Julien Nabet 2012-08-05 12:07:36 UTC
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()
Comment 14 Julien Nabet 2012-08-05 12:17:17 UTC
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.
Comment 15 Julien Nabet 2012-08-05 13:09:16 UTC
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)
Comment 16 Robert Großkopf 2012-08-05 14:04:15 UTC
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 ?
Comment 17 sasha.libreoffice 2012-08-06 05:50:51 UTC
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.
Comment 18 Jochen 2012-08-06 06:27:54 UTC
Hi Sasha,

what OS are you using?
The problems don´t occur using Windows as OS, but only using Linux (also bug 53115).
Comment 19 sasha.libreoffice 2012-08-06 06:37:43 UTC
Linux Fedora 64 bit
Comment 20 Robert Großkopf 2012-08-06 07:10:04 UTC
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?
Comment 21 sasha.libreoffice 2012-08-06 07:22:07 UTC
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.
Comment 22 sasha.libreoffice 2012-08-06 07:49:59 UTC
Reproduced odb corruption also on Linux Alt6 64 bit, KDE. Used the same installation files as for Fedora.
Comment 23 sasha.libreoffice 2012-08-06 09:18:38 UTC
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.
Comment 24 Lionel Elie Mamane 2012-08-06 09:26:20 UTC
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.
Comment 25 Lionel Elie Mamane 2012-08-06 09:28:37 UTC
Cannot reproduce with attachment 64926 [details] with LibreOffice 3.6.0.4 (Build ID: 932b512) (official deb binaries) on Debian GNU/Linux amd64.
Comment 26 Rainer Bielefeld Retired 2012-08-06 09:33:26 UTC
> 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.
Comment 27 Petr Mladek 2012-08-06 09:36:58 UTC
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.
Comment 28 Jochen 2012-08-06 09:52:37 UTC
(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?
Comment 29 Julien Nabet 2012-08-06 12:43:48 UTC
Created attachment 65173 [details]
valgrind logs on master

I retrieved Valgrind logs if it can help.
Comment 30 Robert Großkopf 2012-08-06 14:20:34 UTC
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.
Comment 31 Robert Großkopf 2012-08-06 15:48:51 UTC
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.
Comment 32 Lionel Elie Mamane 2012-08-06 15:54:30 UTC
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.
Comment 33 Robert Großkopf 2012-08-06 18:50:30 UTC
(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 ...
Comment 34 Lionel Elie Mamane 2012-08-07 03:44:56 UTC
(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.
Comment 35 sasha.libreoffice 2012-08-07 05:29:10 UTC
In other words: this message not connected with this problem.
Comment 36 Robert Großkopf 2012-08-07 06:43:37 UTC
"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.
Comment 37 Not Assigned 2012-08-09 15:52:07 UTC
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
Comment 38 Stephan Bergmann 2012-08-09 16:03:07 UTC
(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.
Comment 39 Not Assigned 2012-08-10 11:30:43 UTC
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.
Comment 40 Michael Stahl (CIB) 2012-08-10 17:47:58 UTC
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.
Comment 41 Robert Großkopf 2012-08-10 19:15:43 UTC
(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?
Comment 42 Michael Stahl (CIB) 2012-08-10 19:51:35 UTC
(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/
Comment 43 Michael Stahl (CIB) 2012-08-10 20:15:12 UTC
*** Bug 53115 has been marked as a duplicate of this bug. ***
Comment 44 Michael Stahl (CIB) 2012-08-10 20:21:07 UTC
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 :)
Comment 45 Robert Großkopf 2012-08-14 06:34:00 UTC
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.
Comment 46 Alex Thurgood 2012-08-21 08:56:40 UTC
*** Bug 53854 has been marked as a duplicate of this bug. ***
Comment 47 Alex Thurgood 2012-08-26 11:00:07 UTC
*** Bug 53910 has been marked as a duplicate of this bug. ***