Created attachment 65158 [details] Test document (report_edit.odb) I tried to reproduce the bug 52639 and got the following crasher. I have got it with both the official upstream 3.6.0.4 build and also with openSUSE build based on 3.6.0.4 sources. I tested it on SLED11-SP1-x86_64. Steps to reproduce: 1. Open the attached report_edit.odb 2. Click "Reports" icon in the left side box. 3. "Select "Use Wizard to Create Report" 4. Click the button "Cancel" Result: Crash I see the following message on the console: --- cut ---- $> LANG=en_US.UTF-8 /usr/lib64/libreoffice/program/soffice.bin report_edit.odb pure virtual method called terminate called without an active exception Neúspěšně ukončen (SIGABRT) (core dumped) --- cut ---
Created attachment 65159 [details] Backtrace from the generated core file The backtrace is created from the SUSE packages but there are only very few patches on top of the plain sources.
Nothing unusual with "LibreOffice 3.5.6.1 German UI/Locale [Build-ID: 9cb76c3-dcba98b-297ab39-994e618-0f858f0] on German WIN7 Home Premium (64bit) NOT reproducible] with Server Installation of "LibreOffice 3.6.0.4 rc English UI/ German Locale [Build-ID: 932b512] on German WIN7 Home Premium (64bit)
Reproducible on my development tree (debug build, Debian GNU/Linux amd64, branch libreoffice-3-6). It seems some bridges::cpp_uno::shared::UnoInterfaceProxy is created with a "purely virtual" pCppI member (a plain XInterface, instead of an instance of a type that inherits from it and implements its member methods). I haven't found out which one: breaking in the constructor gives so many hits I did not have the patience to wait for the faulty call.
Program received signal SIGABRT, Aborted. 0x00007ffff6d7c475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) up 20 #20 0x00007fffea2ff880 in bridges::cpp_uno::shared::freeUnoInterfaceProxy (pEnv=0x1b8d0d0, pProxy=0x265fd30) at /home/master/src/libreoffice/workdirs/libreoffice-3.6/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:53 53 pThis->pCppI->release(); (gdb) list 48 OSL_ASSERT(false); 49 } 50 51 (*pThis->pBridge->getCppEnv()->revokeInterface)( 52 pThis->pBridge->getCppEnv(), pThis->pCppI ); 53 pThis->pCppI->release(); 54 ::typelib_typedescription_release( 55 (typelib_TypeDescription *)pThis->pTypeDescr ); 56 pThis->pBridge->release(); 57 (gdb) print pThis->pCppI $138 = (com::sun::star::uno::XInterface *) 0x24f3890 (gdb) show print object Printing of object's derived type based on vtable info is on.
can't reproduce here either; the crash is in a Java finalizer, so timing may vary significantly; freeUnoInterfaceProxy leading to __cxa_pure_virtual sounds like either memory corruption or a ref-counted UNO object forcefully being deleted before its ref-count is zero
(In reply to comment #5) > can't reproduce here either; the crash is in a Java finalizer, so timing may > vary significantly; freeUnoInterfaceProxy leading to __cxa_pure_virtual sounds > like either memory corruption or a ref-counted UNO object forcefully being > deleted before its ref-count is zero That's interesting... The line just before that is (*pThis->pBridge->getCppEnv()->revokeInterface)( pThis->pBridge->getCppEnv(), pThis->pCppI ); I wonder if that's the line that "forcefully deletes pThis->pCppI", and thus leads to the pure virtual: (gdb) break unointerfaceproxy.cxx:51 Breakpoint 1 at 0x7fffea2ff82d: file /home/master/src/libreoffice/workdirs/libreoffice-3.6/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx, line 51. (gdb) commands 1 Type commands for breakpoint(s) 1, one per line. End with a line saying just "end". >print pThis->pCppI >continue >end (gdb) continue -----> big snip of many breakpoint hits <-------------- Breakpoint 1, bridges::cpp_uno::shared::freeUnoInterfaceProxy (pEnv=0x1ba5330, pProxy=0x2676e50) at /home/master/src/libreoffice/workdirs/libreoffice-3.6/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:51 51 (*pThis->pBridge->getCppEnv()->revokeInterface)( $94 = (reportdesign::OSection *) 0x23c45c0 pure virtual method called terminate called without an active exception (gdb) up 6 #6 0x00007fffea2ff880 in bridges::cpp_uno::shared::freeUnoInterfaceProxy (pEnv=0x1ba5330, pProxy=0x2676e50) at /home/master/src/libreoffice/workdirs/libreoffice-3.6/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:53 53 pThis->pCppI->release(); (gdb) print pThis->pCppI $95 = (com::sun::star::uno::XInterface *) 0x23c4610 Hmmm... The value (address pointed at) of pThis->pCppI has changed between line 51 and 53... I don't immediately understand how this could happen: print pThis->pBridge->getCppEnv()->revokeInterface $96 = (void (*)(_uno_ExtEnvironment *, void *)) revokeInterface takes a void*, not a &(void*), so how could it change its argument? Maybe it is a more subtle memory corruption issue?
(In reply to comment #6) > Hmmm... The value (address pointed at) of pThis->pCppI has changed between > line 51 and 53... I've confirmed "for sure" that this is the case. (gdb) break unointerfaceproxy.cxx:51 Breakpoint 1 at 0x7fffea2ff82d: file /home/master/src/libreoffice/workdirs/libreoffice-3.6/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx, line 51. (gdb) commands 1 Type commands for breakpoint(s) 1, one per line. End with a line saying just "end". >print pThis->pCppI >continue >end (gdb) break unointerfaceproxy.cxx:53 Breakpoint 1 at 0x7fffea2ff82d: file /home/master/src/libreoffice/workdirs/libreoffice-3.6/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx, line 51. (gdb) commands 2 Type commands for breakpoint(s) 2, one per line. End with a line saying just "end". >print pThis->pCppI >continue >end (gdb) continue -------------> snip many hits <---------------- Breakpoint 1, bridges::cpp_uno::shared::freeUnoInterfaceProxy (pEnv=0x172c100, pProxy=0x2689940) at /home/master/src/libreoffice/workdirs/libreoffice-3.6/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:51 51 (*pThis->pBridge->getCppEnv()->revokeInterface)( $178 = (reportdesign::OSection *) 0x22fba40 Breakpoint 2, bridges::cpp_uno::shared::freeUnoInterfaceProxy (pEnv=0x172c100, pProxy=0x2689940) at /home/master/src/libreoffice/workdirs/libreoffice-3.6/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:53 53 pThis->pCppI->release(); $179 = (com::sun::star::uno::XInterface *) 0x22fba90 pure virtual method called terminate called without an active exception
Now I need to find a way to break at entry of this function only if I'm in the problematic case so that I can step through the execution. Tried to to that by this patch: --- a/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx +++ b/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx @@ -26,6 +26,8 @@ * ************************************************************************/ +#include "/home/user/src/libreoffice/workdirs/libreoffice-3.6/reportdesign/source/core/inc/Section.hxx" +#include <iostream> #include "bridges/cpp_uno/shared/unointerfaceproxy.hxx" @@ -48,6 +50,12 @@ void freeUnoInterfaceProxy(uno_ExtEnvironment * pEnv, void * pProxy) OSL_ASSERT(false); } + reportdesign::OSection *pSec = dynamic_cast<reportdesign::OSection*>(pThis->pCppI); + if (pSec == NULL) + std::cerr << "pSec is NULL" << std::endl; + else + std::cerr << "pSec is " << pSec << std::endl; + (*pThis->pBridge->getCppEnv()->revokeInterface)( pThis->pBridge->getCppEnv(), pThis->pCppI ); pThis->pCppI->release(); Thinking I would (in gdb) put a break on the line std::cerr << "pSec is " << pSec << std::endl; But then it doesn't link: ../../../unxlngx6/slo/unointerfaceproxy.o: In function `bridges::cpp_uno::shared::freeUnoInterfaceProxy(_uno_ExtEnvironment*, void*)': /home/user/src/libreoffice/workdirs/libreoffice-3.6/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:53: undefined reference to `typeinfo for reportdesign::OSection' collect2: error: ld returned 1 exit status Anybody got a dirty idea to get this to go through, or another idea to break only in the problematic case?
Is this one a regression?
(In reply to comment #9) > Is this one a regression? As a crasher, yes. But my development tree of libreoffice-3-5 freezes on the same test...
(In reply to comment #10) > (In reply to comment #9) >> Is this one a regression? > As a crasher, yes. But my development tree of libreoffice-3-5 freezes on the > same test... OTOH, it looks like it is trying to crash, but cannot: #0 __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 #1 0x00007f0a60958354 in _L_lock_997 () from /lib/x86_64-linux-gnu/libpthread.so.0 #2 0x00007f0a609581b7 in __pthread_mutex_lock (mutex=0x1ebcd20) at pthread_mutex_lock.c:82 #3 0x00007f0a61b6a915 in osl_acquireMutex (Mutex=0x1ebcd20) at mutex.c:130 #4 0x00007f0a5ca980f2 in vcl::SolarMutexObject::acquire (this=0x1ebccc0) at /home/master/src/libreoffice/core/vcl/source/app/solarmutex.cxx:44 #5 0x00007f0a5cf41724 in SalYieldMutex::acquire (this=0x1ebccc0) at /home/master/src/libreoffice/core/vcl/generic/app/geninst.cxx:59 #6 0x00007f0a5317aa90 in GtkHookedYieldMutex::acquire (this=0x1ebccc0) at /home/master/src/libreoffice/core/vcl/unx/gtk/app/gtkinst.cxx:98 #7 0x00007f0a5ca9cd94 in SolarMutexGuard::SolarMutexGuard (this=0x7f0a31777c40) at /home/master/src/libreoffice/core/solver/unxlngx6/inc/vcl/svapp.hxx:439 #8 0x00007f0a5caa44d0 in VCLExceptionSignal_impl (pInfo=0x7f0a31777d60) at /home/master/src/libreoffice/core/vcl/source/app/svmain.cxx:136 #9 0x00007f0a61b75dd5 in CallSignalHandler (pInfo=pInfo@entry=0x7f0a31777d60) at signal.c:854 #10 0x00007f0a61b76067 in SignalHandlerFunction (Signal=6) at signal.c:963 #11 <signal handler called> #12 0x00007f0a60da1475 in *__GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #13 0x00007f0a60da46f0 in *__GI_abort () at abort.c:92 #14 0x00007f0a60de4b70 in malloc_printerr (action=2, str=0x7f0a60ebb930 "free(): corrupted unsorted chunks", ptr= 0x71ac) at malloc.c:6288 #15 0x00007f0a60de693a in free_check (mem=0x3e48710, caller=<optimized out>) at hooks.c:300 #16 0x00007f0a61bad04a in rtl_freeMemory_SYSTEM (p=p@entry=0x3e48710) at /home/master/src/libreoffice/core/sal/rtl/source/alloc_global.cxx:284 #17 0x00007f0a61bad15c in rtl_freeMemory (p=0x3e48710) at /home/master/src/libreoffice/core/sal/rtl/source/alloc_global.cxx:348 #18 0x00007f0a61b8fa47 in rtl_uString_release (pThis=0x3e48710) at /home/master/src/libreoffice/core/sal/rtl/source/strtmpl.cxx:1057 #19 0x00007f0a602966a1 in rtl::OUString::~OUString (this=0x3e5fb10, __in_chrg=<optimized out>) at /home/master/src/libreoffice/core/solver/unxlngx6/inc/rtl/ustring.hxx:234 #20 0x00007f0a602b6eee in (anonymous namespace)::ObjectEntry::~ObjectEntry (this=0x3e5fb10, __in_chrg=<optimized out>) at /home/master/src/libreoffice/core/cppu/source/uno/lbenv.cxx:86 #21 0x00007f0a602b7267 in (anonymous namespace)::s_stub_defenv_revokeInterface (pParam=pParam@entry=0x7f0a31778608) at /home/master/src/libreoffice/core/cppu/source/uno/lbenv.cxx:407 #22 0x00007f0a602c5ca2 in s_environment_invoke_v (pCurrEnv=0x0, pTargetEnv=pTargetEnv@entry=0x32feea0, pCallee=pCallee@entry=0x7f0a602b6f0a <(anonymous namespace)::s_stub_defenv_revokeInterface(va_list*)>, pParam=pParam@entry=0x7f0a31778608) at /home/master/src/libreoffice/core/cppu/source/uno/EnvStack.cxx:296 #23 0x00007f0a602c5d4b in uno_Environment_invoke_v (pTargetEnv=pTargetEnv@entry=0x32feea0, pCallee=pCallee@entry= 0x7f0a602b6f0a <(anonymous namespace)::s_stub_defenv_revokeInterface(va_list*)>, pParam=pParam@entry= 0x7f0a31778608) at /home/master/src/libreoffice/core/cppu/source/uno/EnvStack.cxx:315 #24 0x00007f0a602c5df3 in uno_Environment_invoke (pEnv=0x32feea0, pCallee= 0x7f0a602b6f0a <(anonymous namespace)::s_stub_defenv_revokeInterface(va_list*)>) at /home/master/src/libreoffice/core/cppu/source/uno/EnvStack.cxx:324 #25 0x00007f0a602b75a5 in (anonymous namespace)::defenv_revokeInterface (pEnv=0x32feea0, pInterface=pInterface@entry= 0x3e454e0) at /home/master/src/libreoffice/core/cppu/source/uno/lbenv.cxx:455 #26 0x00007f0a54e062a1 in bridges::cpp_uno::shared::releaseProxy (pUnoI=0x3e454e0) at /home/master/src/libreoffice/core/bridges/source/cpp_uno/shared/unointerfaceproxy.cxx:95 #27 0x00007f0a31b3adf1 in Java_com_sun_star_bridges_jni_1uno_JNI_1proxy_finalize (jni_env=0x36939d0, jo_proxy=0x7f0a31778840, bridge_handle=57136320) at /home/master/src/libreoffice/core/bridges/source/jni_uno/jni_java2uno.cxx:695 #28 0x00007f0a36154d68 in ?? () #29 0x0000000003693800 in ?? () #30 0x00007f0a39ddfa59 in NotRunnable (ox=0x77fd85f00, this=<optimized out>, Self=<optimized out>) at /scratch/packages/openjdk/6b24/openjdk-6-6b24-1.11.1/build/openjdk/hotspot/src/share/vm/runtime/objectMonitor.cpp:2187 #31 ObjectMonitor::NotRunnable (this=0x77fd85f00, Self=<optimized out>, ox=0x77fd85f00) at /scratch/packages/openjdk/6b24/openjdk-6-6b24-1.11.1/build/openjdk/hotspot/src/share/vm/runtime/objectMonitor.cpp:2166 #32 0x00007f0a3614985a in ?? () #33 0x0000000000000000 in ?? () Notice the similar (but not same) bridges::cpp_uno::shared::releaseProxy in the call stack.
LibreOffice 3.5.5.3 (official .deb binaries) on Debian GNU/Linux amd64 does not crash, nor freeze. LibreOffice 3.6.0.4 (official .deb binaries) on Debian GNU/Linux amd64 aborts. So for a non-debug build, definitely a regression.
We need to run under valgrind, ignore the python GC thrash, and find out where this memory corruption comes from: #14 0x00007f0a60de4b70 in malloc_printerr (action=2, str=0x7f0a60ebb930 "free(): corrupted unsorted chunks", ptr= The "do all sorts of crazy stuff from a signal handler" approach we have to these faults is a best-effort attempt to handle simple crashes, and - well - as you see it is rather flawed. Doing better is rather hard - particularly around mutex states. We could try to do some heavy-duty poking / resetting of mutex state as we catch the signal somehow I guess; but that's hard for the internal libc protections :-) Best to find / fix the underlying memory corruption I guess; for that valgrind is our friend.
(In reply to comment #5) > can't reproduce here either; the crash is in a Java finalizer, so timing may > vary significantly; freeUnoInterfaceProxy leading to __cxa_pure_virtual sounds > like either memory corruption or a ref-counted UNO object forcefully being > deleted before its ref-count is zero can reproduce now after all on Linux master; looks like a refcounting error between a reportdesign::OSection and its XAggregation reportdesign::OReportDrawPage; investigating...
Created attachment 65241 [details] debug code to demonstrate aggregation violation The attached aggregation-violation.patch demonstrates that reportdesign::OSection delegating to an SvxFmDrawPage (held as mxUnoPage by an SdrPage derivate) violates the XAggregation requirement that: "All calls to XInterface::acquire() which are made before the delegator was set (using the method XAggregation::setDelegator()) must not be taken back (using the method XInterface::release()) before the delegation is removed by calling xAggregation->setDelegator(NULL)." [udkapi/com/sun/star/uno/XAggregation.idl] debug: SdrPage::getUnoPage mxUnoPage acquire, 0x7f5d78d985d0 debug: OSection::init m_xProxy set delegator, 0x7f5d78d985f0 debug: OSection::~OSection m_xProxy reset delegator, 0x7f5d78d985f0 debug: SdrPage::~SdrPage mxUnoPage release, 0x7f5d78d985d0 debug: SdrPage::getUnoPage mxUnoPage acquire, 0x7f5d78d94ac0 debug: OSection::init m_xProxy set delegator, 0x7f5d78d94ae0 debug: SdrPage::getUnoPage mxUnoPage acquire, 0x7f5d78d945c0 debug: OSection::init m_xProxy set delegator, 0x7f5d78d945e0 debug: SdrPage::getUnoPage mxUnoPage acquire, 0x7f5d78d940c0 debug: OSection::init m_xProxy set delegator, 0x7f5d78d940e0 debug: SdrPage::getUnoPage mxUnoPage acquire, 0x7f5d78d99998 debug: OSection::init m_xProxy set delegator, 0x7f5d78d999b8 debug: SdrPage::getUnoPage mxUnoPage acquire, 0x7f5d7806a338 debug: OSection::init m_xProxy set delegator, 0x7f5d7806a358 debug: SdrPage::getUnoPage mxUnoPage acquire, 0x7f5d7806a5b8 debug: OSection::init m_xProxy set delegator, 0x7f5d7806a5d8 debug: SdrPage::~SdrPage mxUnoPage release, 0x7f5d7806a5b8 debug: SdrPage::~SdrPage mxUnoPage release, 0x7f5d7806a338 debug: SdrPage::~SdrPage mxUnoPage release, 0x7f5d78d99998 debug: SdrPage::~SdrPage mxUnoPage release, 0x7f5d78d940c0 debug: SdrPage::~SdrPage mxUnoPage release, 0x7f5d78d945c0 debug: SdrPage::~SdrPage mxUnoPage release, 0x7f5d78d94ac0 debug: OSection::~OSection m_xProxy reset delegator, 0x7f5d78d94ae0 pure virtual method called terminate called without an active exception The first usage of SvxFmDrawPage 0x7f5d78d985d0 (resp. 0x7f5d78d985f0) is OK, SdrPage acquires/releases its mxUnoPage strictly outside the timespan where OSection is set as delegator at its m_xProxy. However, the next usage of SvxFmDrawPage 0xf5d78d94ac0 (resp. 0xf5d7894ae0) is broken, as SdrPage releases its mxUnoPage within the timespan where OSection is set as delegator at its m_xProxy. (An SdrPage's mxUnoPage and the corresponding OSection's m_xProxy point at common SvxFmDrawPage instance, the slight 0x20 offset in reported this pointers is due to the this pointers being reported at different points in the derivation hierarchy of SvxFmDrawPage.) Not knowing the relevant svx and reportdesign code, I do not see an obvious fix for this problem. The best fix would be to abandon aggregation, as it is known to be broken in general (as one has to observe these picky rules) and deprecated.
This /might/ be a regression introduced with <http://cgit.freedesktop.org/libreoffice/core/commit/?id=f7f34c29aada422e54c5835eb4df610b7d2a627c> "INTEGRATION: CWS impress144 (1.6.104); FILE MERGED: 2008/06/07 16:54:05 cl 1.6.104.1: #i88525# keep SvxUnoDrawPage wrapper for as long as the SvdPage lives" changing SdrPage's mxUnoPage from WeakReference to Reference, in a fix for <https://issues.apache.org/ooo/show_bug.cgi?id=88525> "Error in showing and saving presentation when removing last slide is undone."
Radek / Thorsten - an SvxUnoDrawPage bug causing a Base bug ? :-)
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8ec791316c1d90b25e85c94ad105e9cc62e568e2 fdo#53154: fix report design wizard crash:
replacing XAggregation use as described in comment #15 with plain forwarding fixes the crash for me.
Why target 3.7.0 and not 3.6.x?
I still get some scary OSL_WARNs, but it does not crash anymore. warn:legacy.osl:13239:1:/home/master/src/libreoffice/workdirs/libreoffice-3.6/dbaccess/source/ui/browser/genericcontroller.cxx:1350: SbaTableQueryBrowser::openHelpAgent: could not get a dispatcher! warn:legacy.tools:13239:1:/home/master/src/libreoffice/workdirs/libreoffice-3.6/toolkit/source/awt/vclxtoolkit.cxx:1120: createWindow: Unknown Component! warn:legacy.tools:13239:1:/home/master/src/libreoffice/workdirs/libreoffice-3.6/toolkit/source/awt/vclxtoolkit.cxx:1120: createWindow: Unknown Component! warn:legacy.tools:13239:1:/home/master/src/libreoffice/workdirs/libreoffice-3.6/toolkit/source/awt/vclxtoolkit.cxx:1120: createWindow: Unknown Component! warn:legacy.tools:13239:1:/home/master/src/libreoffice/workdirs/libreoffice-3.6/toolkit/source/awt/vclxtoolkit.cxx:1120: createWindow: Unknown Component! warn:legacy.osl:13239:14:/home/master/src/libreoffice/workdirs/libreoffice-3.6/reportdesign/source/ui/report/ReportControllerObserver.cxx:297: caught an exception! in function:void rptui::OXReportControllerObserver::switchListening(const com::sun::star::uno::Reference<com::sun::star::container::XIndexAccess>&, bool) type: com.sun.star.lang.DisposedException warn:legacy.osl:13239:14:/home/master/src/libreoffice/workdirs/libreoffice-3.6/reportdesign/source/ui/report/ReportControllerObserver.cxx:297: caught an exception! in function:void rptui::OXReportControllerObserver::switchListening(const com::sun::star::uno::Reference<com::sun::star::container::XIndexAccess>&, bool) type: com.sun.star.lang.DisposedException warn:legacy.osl:13239:14:/home/master/src/libreoffice/workdirs/libreoffice-3.6/reportdesign/source/ui/report/ReportControllerObserver.cxx:297: caught an exception! in function:void rptui::OXReportControllerObserver::switchListening(const com::sun::star::uno::Reference<com::sun::star::container::XIndexAccess>&, bool) type: com.sun.star.lang.DisposedException warn:legacy.osl:13239:14:/home/master/src/libreoffice/workdirs/libreoffice-3.6/reportdesign/source/ui/report/ReportControllerObserver.cxx:297: caught an exception! in function:void rptui::OXReportControllerObserver::switchListening(const com::sun::star::uno::Reference<com::sun::star::container::XIndexAccess>&, bool) type: com.sun.star.lang.DisposedException
(In reply to comment #20) > Why target 3.7.0 and not 3.6.x? The keyword name is confusing. It means "fixed in this version", not "we intend to fix it in this version". Michael (the author of the patch) asked for backport to 3.6.x (see https://gerrit.libreoffice.org/#/c/381/)
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=40157f6fa8950505a7ffd22e0b11696ccbd512ae&g=libreoffice-3-6 fdo#53154: fix report design wizard crash: It will be available in LibreOffice 3.6.1.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-3-5": http://cgit.freedesktop.org/libreoffice/core/commit/?id=05218c101df486302bf4cfe8be23ad840daa3f73&g=libreoffice-3-5 fdo#53154: fix report design wizard crash: It will be available in LibreOffice 3.5.7.