Created attachment 41832 [details]
error message on stderr
When creating a new report using the wizard, if one clicks the "cancel" button when it asks for the fields (the very first question), the whole of libreoffice aborts and coredumps.
I'm using the Debian package version 1:3.3.0~rc2-3.
Precise instructions to reproduce:
- open a Base document
- click "reports"
- click "Use wizard to Create Report"
- if prompted for a password, enter it and click OK
- now it asks which query/table the report should be based on, and which columns should appear. Just click the "Cancel" button.
The whole of LibreOffice immediately exits and coredumps.
Expected behaviour: creating the report is cancelled, but LibreOffice continues to work correctly and does not close any other document.
Created attachment 41833 [details]
backtrace generated from core file with gdb
Created attachment 41834 [details]
backtrace when libreoffice run with MALLOC_CHECK_=2
Does look like Linux (maybe - can't try OS X)
- easily reproduced under Ubuntu here
- can not reproduce (even if I force a bad connection being passed to the wizard) under XP or Vista
I can't reproduce it here on openSUSE 11.2, using the one packaged by the distro.
Does changing the Java setting to pick different JVM make any difference?
I can not confirm on Mac OSX 10.6.5, with LibO RC2. The cancel button works as expected and returns me to the main ODB window.
(In reply to comment #4)
> I can't reproduce it here on openSUSE 11.2, using the one packaged by the
> Does changing the Java setting to pick different JVM make any difference?
Using sun-java6-jre (version 6.22-1) instead of openjdk-6-jre (version 6b18-1.8.3-2) does not make a difference, the same crash happens.
However, using GCJ (reported by LibreOffice as Free Software Foundation 1.5.0), the crash does not happen.
I also confirm this is a regression, i.e. it does not happen with the following packages:
- openoffice.org 1:3.2.1-11
- openoffice.org-report-builder 1:1.2.1+OOo3.2.1-11
Has this situation changed with the release of 3.3.1, if so, we ought to close this report.
*** Bug 35451 has been marked as a duplicate of this bug. ***
(In reply to comment #9)
> *** Bug 35451 has been marked as a duplicate of this bug. ***
The fact that someone has reported the same for 3.3.2 indicates that bug still present in the latest stable version available, at least on some Linux platforms.
I have tested with the latest 3.4rc2 on Mac OSX and get no crash. Need someone to test on Linux.
yes,bug also appears in 3.5 main branch, thought it seems to do strange things even when I launch this wizard.
I tried to reproduce without success.
I'm on a pc Debian x86-32 (is it confirmed it concerns only x86-64 ?) with debug mode and use Openjdk-6-jre (1.6.0_23)
lionel: have you succeeded in reproducing the pb with 3.4.3 or 3.5 ?
Gabor: Would you have some error messages before the crash or better a backtrace (ideally with symbols) ?
Can not reproduce on Mac OSX with LibO 3.4.3.
Can also not reproduce on Mac OSX with 3.5 master.
Alex: great !
Gabor: could you tell us on which environment are you ? Have you tried to uninstall completely LO (profil file and registry if Windows) and reinstall it ?
> lionel: have you succeeded in reproducing the pb with 3.4.3 or 3.5 ?
Yes and no.
One one machine (for my future reference:piperine), I cannot reproduce. This machine (Debian GNU/Linux amd64) has Debian packages libreoffice 1:3.4.3-1 and OpenJDK 6b23~pre9-1. There, I cannot reproduce.
On another machine (for my future reference: camp), also Debian GNU/Linux amd64, I can reproduce with various versions of LO and Java:
- Self-compiled libreoffice-3-4, as of mid-august (meaning "some development after 3.4.3-rc1, but not including 3.4.3-rc2), *not* a debug build, with Debian OpenJDK 6b18-1.8.7-2~squeeze1: silent abort
- Same libreoffice-3-4 tree with Debian OpenJDK 6b23~pre11-1: silent abort
- My core/master development tree, last updated 12/9/2011 (commit b89da4bbb9e4fb2b94bf3d5dcc225a0d88936953), debug build: sometimes freeze, sometimes the "LibreOffice has crashed" dialog. When it freezes, even a SIGTERM does not kill it, it needs SIGKILL.
Now, the weird thing is that on machine camp, I get the choice between "use wizard to create report" or "create report in design mode"; on machine piperine I have only "Use Wizard to Create Report"... Anyone has an idea where this discrepancy can come from?
about piperine, you meant you didn't reproduce in debug and not debug mode ? If it's the case, good news !
About camp: "sometimes freeze, sometimes the "LibreOffice has crashed" dialog". Perhaps a stupid idea, but have you runned a memcheck ?
It could be interesting you make more tests on this machine in debug mode (with symbols too) perhaps with the last sources of master then, if you don't reproduce the pb on master, with last sources from 3.4.X branch. I know it'll take you some time to do this.
(In reply to comment #8)
> Has this situation changed with the release of 3.3.1
No: reproduced with 3.3.3 (Debian package 1:3.3.3-4+b1)
(In reply to comment #18)
> about piperine, you meant you didn't reproduce in debug and not debug mode ? If
> it's the case, good news !
No, I mean I tested only the Debian package, which (I strongly expect) is compiled in "not debug" mode.
(In reply to comment #20)
> (In reply to comment #18)
> > about piperine, you meant you didn't reproduce in debug and not debug mode ? If
> > it's the case, good news !
> No, I mean I tested only the Debian package, which (I strongly expect) is
> compiled in "not debug" mode.
sorry about the remark on Piperine, you're absolutely right, it can't be debug mode if these are Debian packages.
Keep us informed about camp ! :-)
FYI, testing this on a 3.4 debug build is blocked by bug #39839
Cannot reproduce with a fresh master (commit cbc0073221ba1df90a56d541752bed16272906b1 of Fri Oct 28 11:16:13 2011 +0200, "make clean && make") on camp.
(In reply to comment #23)
> Cannot reproduce with a fresh master (commit
> cbc0073221ba1df90a56d541752bed16272906b1 of Fri Oct 28 11:16:13 2011 +0200,
> "make clean && make") on camp.
Perhaps I'm wrong but camp had 3.4 and you were stucked with debug mode because of the pb fdo#39839
Now the commit you quoted is from master, so I suppose you tried master branch on camp and this was ok.
If it's the case, it's another test on 3.5 which confirms the pb couldn't be reproduced on 3.5, great !
About 3.4, since you don't reproduce 39839 on master, perhaps you could retry on camp machine by removing the block "#if OSL_DEBUG_LEVEL > 0" from comphelper/source/property/propagg.cxx
gabor: would you have you got more information about your pb ? (see my comment 16)
Created attachment 53560 [details]
BT on 3.4.4
I reproduced the pb on 3.4.4 (Debian Sid Packages pc, x86-32, I use testing except for the LO packages just to reproduce this pb).
I installed libreoffice-dbg but for the moment I only get a bt without symbols.
(In reply to comment #24)
> (In reply to comment #23)
>> Cannot reproduce with a fresh master (commit
>> cbc0073221ba1df90a56d541752bed16272906b1 of Fri Oct 28 11:16:13 2011 +0200,
>> "make clean && make") on camp.
> Perhaps I'm wrong but camp had 3.4 and you were stucked with debug mode because
> of the pb fdo#39839
Camp has several versions:
1) Debian package
2) self-compiled "old" libreoffice-3-4 debug build (I can update it if useful, obviously)
3) self-compiled libreoffice-3-4 non-debug build: my development tree to do stuff on libreoffice-3-4
4) self-compiled master, regularly updated: my main development tree
Created attachment 53634 [details]
backtrace with some symbols
In fact the libreoffice-dbg version didn't correspond to libreoffice version
libreoffice and libreoffice-dbg version : 3.4.4-1+b1
(thanks you Michael for your help on IRC and finally the version were identical).
Then I did this :
- on console 1 :
open a odb
- on console 2 : I attached gdb by following http://wiki.documentfoundation.org/Development/How_to_debug#Attaching_to_the_soffice.bin_process
go to report part
click wizard report
console 2 :
Hope it helps.
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
needinfo keyword redundant by needinfo status.
Bug is absent in 3.5.0. Closing, as it looks like it won't be fixed in 3.4 line.