Issue 18773 - Format->Character crasher ...
Summary: Format->Character crasher ...
Status: CLOSED FIXED
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: OOo 1.1 RC3
Hardware: PC Linux, all
: P1 (highest) Trivial (vote)
Target Milestone: OOo 1.1.1
Assignee: Mathias_Bauer
QA Contact: issues@framework
URL:
Keywords:
: 28906 (view as issue list)
Depends on:
Blocks:
 
Reported: 2003-08-28 13:57 UTC by mmeeks
Modified: 2004-05-07 20:36 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
a hack that fixes the symptom. (1.36 KB, patch)
2003-08-28 14:06 UTC, mmeeks
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description mmeeks 2003-08-28 13:57:42 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.
Comment 1 mmeeks 2003-08-28 14:06:28 UTC
Created attachment 8846 [details]
a hack that fixes the symptom.
Comment 2 thorsten.martens 2003-08-28 14:36:24 UTC
TM->US: As talked about, please have a look, thanks !
Comment 3 ulf.stroehler 2003-08-28 14:53:54 UTC
@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.
Comment 4 Oliver Specht 2003-08-28 15:02:17 UTC
os-mba: Your code.
Comment 5 ulf.stroehler 2003-08-28 15:41:39 UTC
'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
Comment 6 mmeeks 2003-08-29 10:11:20 UTC
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.
Comment 7 Mathias_Bauer 2003-09-12 17:26:41 UTC
Usually that's a P2, but it doesn't matter. Should be fixed ASAP. ;-)
Comment 8 Mathias_Bauer 2003-10-17 13:11:14 UTC
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.
Comment 9 Mathias_Bauer 2003-10-17 17:08:35 UTC
.
Comment 10 ulf.stroehler 2003-10-17 18:58:01 UTC
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.
Comment 11 mmeeks 2003-10-24 12:17:17 UTC
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.
Comment 12 Mathias_Bauer 2003-10-30 12:33:46 UTC
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.
Comment 13 h.ilter 2003-10-31 14:11:13 UTC
Verified with CWS = No crash
Comment 14 h.ilter 2003-10-31 14:11:40 UTC
Set to fixed.
Comment 15 h.ilter 2003-10-31 14:12:18 UTC
Set to Verified.
Comment 16 ulf.stroehler 2003-11-03 17:08:49 UTC
Reopening task.
Comment 17 ulf.stroehler 2003-11-03 17:10:26 UTC
crash is still reproducible with provided patch in fwk02pp1
Comment 18 Mathias_Bauer 2003-11-04 12:21:58 UTC
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.
Comment 19 ulf.stroehler 2003-11-04 12:53:19 UTC
US: setting task back to verified.
@Michael: pls. let me know if this issue is solved for you with
Mathias' fix. Thx.
Comment 20 mmeeks 2003-12-03 16:22:26 UTC
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 ...
Comment 21 mmeeks 2003-12-03 16:30:40 UTC
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.
Comment 22 lohmaier 2004-05-07 20:36:09 UTC
*** Issue 28906 has been marked as a duplicate of this issue. ***