Apache OpenOffice (AOO) Bugzilla – Issue 122095
[sidebar] Crash inserting table in Draw/Impress
Last modified: 2017-05-20 11:42:07 UTC
build: r1463876 steps: 1)create a new impress 2)Insert new table with default 5 columns and 2 rows defect: step2 will crash OO.
This isn't reproducible in a build previous sidebar integration
Program received signal SIGSEGV, Segmentation fault. 0x00007fe7f0ae11c0 in sd::DrawViewShell::GetAttrState (this=0x3a522d8, rSet=...) at /build/aoo/src/playground/trunk/main/sd/source/ui/view/drviewsf.cxx:407 407 mpDrawView->GetAttributes( aAttrs ); (gdb) bt #0 0x00007fe7f0ae11c0 in sd::DrawViewShell::GetAttrState (this=0x3a522d8, rSet=...) at /build/aoo/src/playground/trunk/main/sd/source/ui/view/drviewsf.cxx:407 #1 0x00007fe7f0ae7f2f in SfxStubGraphicViewShellGetAttrState (pShell=0x3a522d8, rSet=...) at ../../../unxlngx6/inc/sdgslots.hxx:1178 #2 0x00007fe8139db6e0 in SfxShell::CallState(void (*)(SfxShell*, SfxItemSet&), SfxItemSet&) () from /home/ariel/aoo/openoffice4/program/../basis-link/program/libsfx.so #3 0x00007fe8139d9887 in SfxDispatcher::_FillState(SfxSlotServer const&, SfxItemSet&, SfxSlot const*) () from /home/ariel/aoo/openoffice4/program/../basis-link/program/libsfx.so #4 0x00007fe81384ec8e in SfxBindings::Update_Impl(SfxStateCache*) () from /home/ariel/aoo/openoffice4/program/../basis-link/program/libsfx.so #5 0x00007fe81385153a in SfxBindings::NextJob_Impl(Timer*) () from /home/ariel/aoo/openoffice4/program/../basis-link/program/libsfx.so #6 0x00007fe811770b98 in Link::Call (this=0x33cc0c8, pCaller=0x33cc0a8) at /build/aoo/src/playground/trunk/main/solver/400/unxlngx6/inc/tools/link.hxx:135 #7 0x00007fe81177f035 in Timer::Timeout (this=0x33cc0a8) at /build/aoo/src/playground/trunk/main/vcl/source/app/timer.cxx:253 #8 0x00007fe81177ec9e in Timer::ImplTimerCallbackProc () at /build/aoo/src/playground/trunk/main/vcl/source/app/timer.cxx:141 #9 0x00007fe806909561 in SalTimer::CallCallback (this=0x296e358) at /build/aoo/src/playground/trunk/main/vcl/inc/saltimer.hxx:61 #10 0x00007fe80690927a in X11SalData::Timeout (this=0x1d9d608) at /build/aoo/src/playground/trunk/main/vcl/unx/generic/app/saltimer.cxx:45 #11 0x00007fe806c122ca in GtkXLib::timeoutFn (data=0x1d9efc8) at /build/aoo/src/playground/trunk/main/vcl/unx/gtk/app/gtkdata.cxx:745 #12 0x00007fe806c1221d in call_timeoutFn (data=0x1d9efc8, data@entry=<error reading variable: value has been optimized out>) at /build/aoo/src/playground/trunk/main/vcl/unx/gtk/app/gtkdata.cxx:725 #13 0x0000003633c485db in g_timeout_dispatch (source=source@entry=0x40110f0, callback=<optimized out>, user_data=<optimized out>) at gmain.c:4026 #14 0x0000003633c47a55 in g_main_dispatch (context=0x1dd9bb0) at gmain.c:2715 #15 g_main_context_dispatch (context=context@entry=0x1dd9bb0) at gmain.c:3219 #16 0x0000003633c47d88 in g_main_context_iterate (context=context@entry=0x1dd9bb0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at gmain.c:3290 #17 0x0000003633c47e44 in g_main_context_iteration (context=0x1dd9bb0, may_block=1) at gmain.c:3351 #18 0x00007fe806c1274c in GtkXLib::Yield (this=0x1d9efc8, bWait=true, bHandleAllCurrentEvents=false) at /build/aoo/src/playground/trunk/main/vcl/unx/gtk/app/gtkdata.cxx:874 #19 0x00007fe806906f78 in X11SalInstance::Yield (this=0x1d9d1a8, bWait=true, bHandleAllCurrentEvents=false) at /build/aoo/src/playground/trunk/main/vcl/unx/generic/app/salinst.cxx:278 #20 0x00007fe81177b73a in ImplYield(bool, bool) () from /home/ariel/aoo/openoffice4/program/../basis-link/program/libvcl.so #21 0x00007fe8117794c0 in Application::Execute() () from /home/ariel/aoo/openoffice4/program/../basis-link/program/libvcl.so #22 0x00007fe814a04c52 in desktop::Desktop::Main (this=0x7fff2c64a4d0) at /build/aoo/src/playground/trunk/main/desktop/source/app/app.cxx:2204 #23 0x00007fe81177e849 in ImplSVMain() () from /home/ariel/aoo/openoffice4/program/../basis-link/program/libvcl.so #24 0x00007fe81177e99c in SVMain() () from /home/ariel/aoo/openoffice4/program/../basis-link/program/libvcl.so #25 0x00007fe814a3a9af in soffice_main () at /build/aoo/src/playground/trunk/main/desktop/source/app/sofficemain.cxx:45 #26 0x00000000004012dc in sal_main () at main.c:31 #27 0x00000000004012c1 in main (argc=2, argv=0x7fff2c64a688) at main.c:30 (gdb) print mpDrawView $1 = (sd::DrawView *) 0xa1
It seems the key of the crash is to expand the Table Design panel in the sidebar. I and 2 other people reproduced this issue (on Win7).
Andre, please take over. Investigation reveals that due to a somehow not 'valid' SfxShell stack the Slots SID_ATTR_PARA_LRSPACE and SID_ATTR_PARA_ULSPACE are called at an <TableObjectBar> instance instead of a <DrawViewShell> instance. Note: On Windows having module sfx2 build with debug information no crash occurs due to the fact that the corresponding Windows exception is caught in <IMPL_LINK( SfxBindings, NextJob_Impl, Timer *, pTimer )>
The root cause of this crash (on Windows this manifests as a looping attempt to update a slot with a lot of exceptions thrown) is that the SidebarController reacts to context change synchronously. The insertion of a table is also notified synchronously, so the SidebarController creates new panels after new tool bars and, more importantly, new shells (in this case the table and the text tool bar shells) have been created but before SFX2 has fully updated its internal state. What is missing in SFX2 seems to be an invalidate of at least one SfxStateCache object. That references the wrong shell (has an index of before the new tool bar shells where pushed on the shell stack). That wrong shell is accessed like it where another shell (in this case there is a hard cast from TableObjectBar to DrawViewShell) and this leads to either a crash (on Linux) or an exception (Windows/Debug). While debugging this I have seen scary things: - SfxStateChache indexes the shells on the shell stack by index. When, like in this case, such an index is not invalidated after a change of the shell stack, this causes a crash or other subtle errors. - In SfxBindings::CreateSet_Impl() there is this code: const SfxSlot *pSibling = pRealSlot->GetNextSlot(); while ( pSibling > pRealSlot ) { ... pSibling = pSibling->GetNextSlot(); } I have yet to understand why this works.
Fixed in revision 1470597 by reacting asynchronously to context changes.
"af" committed SVN revision 1470597 into trunk: 122095: React asynchronously to context changes to avoid problems in SFX2.
*** Issue 122158 has been marked as a duplicate of this issue. ***
verify build on Win7 on Rev 1489073, passed