Apache OpenOffice (AOO) Bugzilla – Issue 18773
Format->Character crasher ...
Last modified: 2004-05-07 20:36:09 UTC
This is very odd; for reasons inexplicable it's repeatable only in my (predominantly) non-debug build; it's also 100% repetable, and totally fatal. Simply start a writer instance, Format -> Character. The stack trace looks like this: #6 <signal handler called> #7 0x475fd4ac in SfxSlotServer::GetSlot() const (this=0x4aa11948) at ../inc/slotserv.hxx:114 No locals. #8 0x475fa296 in BindDispatch_Impl (this=0x4aa11948, rDisp=@0xbfffbae0, rURL=@0xbfffba80, pStateCache=0x0) at /opt/OpenOffice/openoffice/build/RC3_030729/sfx2/source/control/statcach.cxx:127 No locals. #9 0x47605089 in SfxBindings::QueryState(unsigned short, SfxPoolItem*&) (this=0x4a21db88, nSlot=10933, rpState=@0xbfffbb7c) at /opt/OpenOffice/openoffice/build/RC3_030729/sfx2/source/control/bindings.cxx:2639 eState = 48 pItem = (struct SfxPoolItem *) 0x0 pBind = (class BindDispatch_Impl *) 0x3 xTunnel = {<BaseReference> = {_pInterface = 0x0}, <No data fields>} pDisp = (struct SfxOfficeDispatch *) 0x0 pSlot = (const SfxSlot *) 0x0 aURL = {Complete = {pData = 0x4aa08d30}, Main = {pData = 0x4aa10320}, Protocol = {pData = 0x4aa08c30}, User = {pData = 0x409e5220}, Password = { pData = 0x409e5220}, Server = {pData = 0x409e5220}, Port = 0, Path = {pData = 0x4aa08c50}, Name = {pData = 0x409e5220}, Arguments = { pData = 0x409e5220}, Mark = {pData = 0x409e5220}} xTrans = {<BaseReference> = {_pInterface = 0x4aa0b000}, <No data fields>} xDisp = {<BaseReference> = {_pInterface = 0x4aa0d92c}, <No data fields>} pCache = (SfxStateCache *) 0x0 pItem = (const struct SfxPoolItem *) 0x4026d316 eState = 48 #10 0x46c74d70 in SvxCharNamePage::Initialize() (this=0x4a9713a8) at /opt/OpenOffice/openoffice/build/RC3_030729/svx/source/dialog/chardlg.cxx:816 pDummy = (struct SfxPoolItem *) 0x46904494 pFrame = (struct SfxViewFrame *) 0x4a21db40 pDocSh = (struct SfxObjectShell *) 0x4a1f96f8 pColorTable = (struct XColorTable *) 0x4a20e570 bKillTable = 0 pItem = (const struct SfxPoolItem *) 0x4a20f860 i = 1243732800 aLink = {pInst = 0x0, pFunc = 0x812af40} #11 0x46c73b5e in SvxCharNamePage (this=0x4a9713a8, pParent=0x4a96f6ec, rInSet=@0xbfffbff0) at /opt/OpenOffice/openoffice/build/RC3_030729/svx/source/dialog/chardlg.cxx:742 No locals. #12 0x46c781e7 in SvxCharNamePage::Create(Window*, SfxItemSet const&) (pParent=0x4a96f6ec, rSet=@0xbfffbff0) at /opt/OpenOffice/openoffice/build/RC3_030729/svx/source/dialog/chardlg.cxx:1696 No locals. #13 0x476aa57c in SfxTabDialog::ActivatePageHdl(TabControl*) () from /usr/lib/ooo-1.1/program/libsfx645li.so #14 0x476a977f in SfxTabDialog::Start_Impl() () from /usr/lib/ooo-1.1/program/libsfx645li.so #15 0x476a92ee in SfxTabDialog::Execute() () from /usr/lib/ooo-1.1/program/libsfx645li.so #16 0x49fc11ee in CreateObjSwGlobalDocShellDll () from /usr/lib/ooo-1.1/program/libsw645li.so #17 0x49fba666 in CreateObjSwGlobalDocShellDll () from /usr/lib/ooo-1.1/program/libsw645li.so #18 0x475f024b in SfxDispatcher::Call_Impl(SfxShell&, SfxSlot const&, SfxRequest&, unsigned char) () from /usr/lib/ooo-1.1/program/libsfx645li.so #19 0x475f2add in SfxDispatcher::PostMsgHandler(SfxRequest*) () from /usr/lib/ooo-1.1/program/libsfx645li.so #20 0x475f29f0 in SfxDispatcher::LinkStubPostMsgHandler(void*, void*) () from /usr/lib/ooo-1.1/program/libsfx645li.so #21 0x4761789f in SfxHintPoster::Event(SfxHint*) () from /usr/lib/ooo-1.1/program/libsfx645li.so #22 0x47617851 in SfxHintPoster::LinkStubDoEvent_Impl(void*, void*) () from /usr/lib/ooo-1.1/program/libsfx645li.so #23 0x4022cdfa in ImplHandleClose(Window*) () from /usr/lib/ooo-1.1/program/libvcl645li.so #24 0x4022d5e5 in ImplWindowFrameProc(void*, SalFrame*, unsigned short, void const*) () from /usr/lib/ooo-1.1/program/libvcl645li.so #25 0x4028d87b in SalFrameData::HandleClientMessage(XClientMessageEvent*) () from /usr/lib/ooo-1.1/program/libvcl645li.so #26 0x4028e2c4 in SalFrameData::Dispatch(_XEvent*) () from /usr/lib/ooo-1.1/program/libvcl645li.so #27 0x402ba9ad in SalDisplay::Dispatch(_XEvent*) () from /usr/lib/ooo-1.1/program/libvcl645li.so #28 0x402ba6fc in SalDisplay::Yield(unsigned char) () from /usr/lib/ooo-1.1/program/libvcl645li.so #29 0x402b65fb in SalDisplay::~SalDisplay() () from /usr/lib/ooo-1.1/program/libvcl645li.so #30 0x402b5014 in SalXLib::Yield(unsigned char) () from /usr/lib/ooo-1.1/program/libvcl645li.so #31 0x402bdfc8 in SalInstance::Yield(unsigned char) () from /usr/lib/ooo-1.1/program/libvcl645li.so #32 0x400e80a1 in Application::Yield() () from /usr/lib/ooo-1.1/program/libvcl645li.so #33 0x400e7fb3 in Application::Execute() () from /usr/lib/ooo-1.1/program/libvcl645li.so #34 0x080651c4 in desktop::Desktop::Main() () #35 0x400ece6f in SVMain() () from /usr/lib/ooo-1.1/program/libvcl645li.so #36 0x402b39e0 in main () from /usr/lib/ooo-1.1/program/libvcl645li.so #37 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6 From the code it's obvious that BindDispatch_Impl must never be called with a NULL SfxStateCache pointer since it derefenrences it in the chained construction. Quite how this has never been seen is not clear to me; perhaps Bindings' Execute_Impl usually gets called before QueryState (somehow) and ensures the cache is correctly initialized (I have no idea). A workaround patch for the crash appears to be to create a local SfxStateCache( nSlotId ), almost certainly not the right fix.
Created attachment 8846 [details] a hack that fixes the symptom.
TM->US: As talked about, please have a look, thanks !
@Michael: sure we are looking into this immediately. But this crash is not reproducible here. Hence Prio changed to P2. BTW: what is the meaning of "No locals." found multiple times on the stack. Debian GNU Linux??? us->os: pls. have a look.
os-mba: Your code.
'have to correct myself. We can now reproduce the issue: Perform the following steps with the mouse: 1. start OOo 2. File/New/Text document 3. Insert dummy text (type dt + F3) 4. select a line of text by triple-click 5. select Format/Character 5. Click to drop down the font combo box and select a different font => error report comes up
No Locals - means there were no local variables when we did a bt full; I binned all the 'No symbols' from the other frames which were not built with debugging information. Sadly my local build didn't behave like this [ which was weird ] also it 's slightly amazing, since none of the recent changes touch the files immediately related to this bug (it seems). Bumped to P1: since it's now repeatable (apparently ) - hope that's ok.
Usually that's a P2, but it doesn't matter. Should be fixed ASAP. ;-)
I'm not able to reproduce that bug on any platform, but the stacktrace (thanks Michael!) gives me a clear hint what's going wrong. I changed the code in appropriate manner and hope that somebody else can verify if that did the job. I'm still curious how this situation is triggered. There is indeed a bug in sfx, but I don't understand why it occurs in *that* case. It looks like there is a DispatchInterceptor working, but I don't know why and where.
.
us->mba: I can still reproduce on Linux even with a 680 debug built (not the one containing the fix). Not every time but reproducible.
Mathias - any chance of your (correct) fix - I'd like to be shipping it to my users instead of my temporary hack - since they see the problem frequently :-) just a branch / CWS name'd be enough. Thanks.
Ulf, you seem to be the perfect guy to verify my fix! :-) You can find the fix in CWS fwk02pp1. @Michael: my fix is pretty close to your fix. Creating a temporary cache object is OK here, all the code that handles external dispatch providers is done inside the cache, and removing the code from there just to avoid the creation of a temp. object doesn't seem a good idea for a patch. For "Q" this code will be reorganized anyway. I'm still curious which external dispatch provider is active here, I never was able to reproduce that situation.
Verified with CWS = No crash
Set to fixed.
Set to Verified.
Reopening task.
crash is still reproducible with provided patch in fwk02pp1
As we found out, the crash we could reproduce here (but only in very rare cases) is another one that was already none from a customer crash report and is also targeted to be fixed in OOO1.1.1. Michael, seems that you are the only one who is able to reproduce that bug. Can you canfirm that it is fixed by my changes in rev.1.25.78.1 of sfx2/source/control/bindings.cxx? I also would be very interested in finding out, *why* this bug was triggered, because I have no idea why the code ran that way. If you are willing to make a small debug session, please let me know it.
US: setting task back to verified. @Michael: pls. let me know if this issue is solved for you with Mathias' fix. Thx.
So I can no-longer reproduce this problem even without our patch, but as long as the patch covers the case we were seeing which it looks like it should, I think this is fixed. I guess it was some artefact of something odd with my system ...
Urk - I'm such a dofus - I could repeat this I was just compiling on 1 machine and running (a different version) on another by mistake - the miracles of ssh. Anyhow - it fails 100% repeatably for me without my patch, and it doesn't crash in 3-4 tries with the 1.25.78.1 diff applied - I'm merging that version back to our patch-set. Thanks.
*** Issue 28906 has been marked as a duplicate of this issue. ***