Bug 53154 - Closing Report Wizard crashes LibreOffice
Summary: Closing Report Wizard crashes LibreOffice
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) Linux (All)
: medium major
Assignee: Michael Stahl (CIB)
URL:
Whiteboard: target:3.7.0 target:3.6.1 target:3.5.7
Keywords: regression
Depends on:
Blocks:
 
Reported: 2012-08-06 09:26 UTC by Petr Mladek
Modified: 2012-08-13 10:10 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document (report_edit.odb) (3.29 KB, application/vnd.oasis.opendocument.database)
2012-08-06 09:26 UTC, Petr Mladek
Details
Backtrace from the generated core file (60.44 KB, text/plain)
2012-08-06 09:29 UTC, Petr Mladek
Details
debug code to demonstrate aggregation violation (1.66 KB, text/plain)
2012-08-07 15:33 UTC, Stephan Bergmann
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Petr Mladek 2012-08-06 09:26:59 UTC
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 ---
Comment 1 Petr Mladek 2012-08-06 09:29:01 UTC
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.
Comment 2 Rainer Bielefeld Retired 2012-08-06 09:59:06 UTC
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)
Comment 3 Lionel Elie Mamane 2012-08-06 11:01:42 UTC
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.
Comment 4 Lionel Elie Mamane 2012-08-06 11:03:32 UTC
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.
Comment 5 Stephan Bergmann 2012-08-06 11:08:41 UTC
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
Comment 6 Lionel Elie Mamane 2012-08-06 15:16:29 UTC
(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?
Comment 7 Lionel Elie Mamane 2012-08-06 16:51:32 UTC
(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
Comment 8 Lionel Elie Mamane 2012-08-06 16:56:33 UTC
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?
Comment 9 Rainer Bielefeld Retired 2012-08-07 05:39:16 UTC
Is this one a regression?
Comment 10 Lionel Elie Mamane 2012-08-07 06:46:03 UTC
(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...
Comment 11 Lionel Elie Mamane 2012-08-07 07:33:27 UTC
(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.
Comment 12 Lionel Elie Mamane 2012-08-07 07:39:09 UTC
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.
Comment 13 Michael Meeks 2012-08-07 11:24:44 UTC
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.
Comment 14 Stephan Bergmann 2012-08-07 13:45:21 UTC
(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...
Comment 15 Stephan Bergmann 2012-08-07 15:33:16 UTC
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.
Comment 16 Stephan Bergmann 2012-08-09 13:29:02 UTC
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."
Comment 17 Michael Meeks 2012-08-09 19:26:21 UTC
Radek / Thorsten - an SvxUnoDrawPage bug causing a Base bug ? :-)
Comment 18 Not Assigned 2012-08-09 22:14:39 UTC
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:
Comment 19 Michael Stahl (CIB) 2012-08-09 22:36:05 UTC
replacing XAggregation use as described in comment #15
with plain forwarding fixes the crash for me.
Comment 20 Jochen 2012-08-10 07:20:19 UTC
Why target 3.7.0 and not 3.6.x?
Comment 21 Lionel Elie Mamane 2012-08-10 07:59:23 UTC
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
Comment 22 Lionel Elie Mamane 2012-08-10 08:02:38 UTC
(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/)
Comment 23 Not Assigned 2012-08-10 08:03:01 UTC
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.
Comment 24 Not Assigned 2012-08-13 10:10:45 UTC
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.