Apache OpenOffice (AOO) Bugzilla – Issue 27529
Crash when configuring status bar
Last modified: 2006-02-09 08:55:16 UTC
using a new 1.1.1 install: - open a new text document - double click the empty section of the status bar - verify that fields dialog appears - tools->configure->status bar - add check mark beside "Current Time" - click OK - double click the empty section of the status bar - got the following trace Fatal exception: Signal 11 Stack: /opt/OpenOffice.org1.1.1/program/libsal.so.3[0x40bd2378] /opt/OpenOffice.org1.1.1/program/libsal.so.3[0x40bd2502] /opt/OpenOffice.org1.1.1/program/libsal.so.3[0x40bd25c8] /lib/libpthread.so.0[0x411301ec] /lib/libc.so.6[0x412ec3a8] /opt/OpenOffice.org1.1.1/program/libvcl645li. so(_Z20ImplHandleMouseEventP6Windowthllmtt+0x105c)[0x40229fd4] /opt/OpenOffice.org1.1.1/program/libvcl645li. so(_Z19ImplWindowFrameProcPvP8SalFrametPKv+0x16a)[0x4022ca9e] /opt/OpenOffice.org1.1.1/program/libvcl645li. so(_ZN12SalFrameData16HandleMouseEventEP7_XEvent+0x46e)[0x4028b5b8] /opt/OpenOffice.org1.1.1/program/libvcl645li. so(_ZN12SalFrameData8DispatchEP7_XEvent+0x123)[0x4028d323] /opt/OpenOffice.org1.1.1/program/libvcl645li. so(_ZN10SalDisplay8DispatchEP7_XEvent+0x28f)[0x402b931f] /opt/OpenOffice.org1.1.1/program/libvcl645li.so(_ZN10SalDisplay5YieldEh+0xf1) [0x402b906d] /opt/OpenOffice.org1.1.1/program/libvcl645li.so[0x402b5017] /opt/OpenOffice.org1.1.1/program/libvcl645li.so(_ZN7SalXLib5YieldEh+0x39a) [0x402b3b68] /opt/OpenOffice.org1.1.1/program/libvcl645li.so(_ZN11SalInstance5YieldEh+0x34) [0x402bc948] /opt/OpenOffice.org1.1.1/program/libvcl645li.so(_ZN11Application5YieldEv+0x61) [0x400e732d] /opt/OpenOffice.org1.1.1/program/libvcl645li.so(_ZN11Application7ExecuteEv+0x35) [0x400e723f] /opt/OpenOffice.org1.1.1/program/soffice.bin(_ZN7desktop7Desktop4MainEv+0x1e6d) [0x8065a3f] /opt/OpenOffice.org1.1.1/program/libvcl645li.so(_Z6SVMainv+0x49)[0x400ec15b] /opt/OpenOffice.org1.1.1/program/libvcl645li.so(main+0x4c)[0x402b256c] /lib/libc.so.6(__libc_start_main+0xc7)[0x412d8857] /opt/OpenOffice.org1.1.1/program/soffice. bin(_ZN6Window11RequestHelpERK9HelpEvent+0x31)[0x805e971] Aborted
cannot reproduce here does it crash every time you double-click the status bar now? Or does the crash only occur if you follow your description (e.g. only after the fields-dialog was launched from the status bar and then the status bar has been configured...) are you using a localized build?
it only crashes if i follow the description, and is fine on the next startup. i am using OOo_1.1.1_LinuxIntel_install.tar.gz, size 79899184. i just reinstalled from scratch and can still reproduce. i untarred the distribution, went into the directory, and did './setup -net' as root, keeping all defaults. i am running a SuSE 8.2 box with all updates. my java RPM is j2re-1.4.2_04-fcs. Next, as a normal user i typed '/opt/OpenOffice.org1.1.1/setup' and did a workstation install, keeping all defaults. Finally, i did '~/OpenOffice.org1.1.1/soffice' and followed the previous instructions, and reproduced the crash.
Hi rayll, thanks for using and supporting OpenOffice.org... I followed your steps on RedHatLinux9 using OOo1.1.1 (from OpenOffice.org) and didn't get that crash...
ok, maybe a SuSE specific thing then. it also happens reliably on my home machine, which is also a SuSE 8.2 machine with all online updates applied. does anyone else have a SuSE machine to test on?
ok, i dug into this one with gdb and a copy of the source tarball.... it's my first time touching the ooo code, and my copy has no debugging symbols, so this might be way out to lunch, but here goes: it seems that SfxStatusBar_Impl::MouseButtonDown(MouseEvent const&) () is calling SfxStatusBar_Impl::GetItemAt(MouseEvent const&) () and not liking what comes back. i debugged it a few times, and when it crashes, it is the call to *0x1c(%eax) which craps out, where eax is derived from the return value of the GetItemAt call. in GetItemAt, it seems that the aLastItemRect.IsInside(aMousePos) call is returning true, so the function returns the value of pLastControl, which is a cached value obtained from pMgr->FindControl_Impl( nId ) a few lines below. Looking into the pMgr, it seems that it's just an array of pointers. That is well and good, but the void SfxPtrArr::Append( void* aElem ) may realloc that array. if that happens, nobody (apparently) notifies pLastControl to flush the cached pointer, therefore the next call to GetItemAt will return a pointer to deleted memory. sound plausible?
No I managed to reproduce. The trick is not to dismiss the fields dialog! So here's again the reciepe: 1) Open a new writer document 2) double-click the status bar to bring up the fields dialog (but don't close it, keep it open) 3) Choose Tools|Configure and check the time to be displayed on the status bar and confirm the configure-dialog with "OK" 4) With the fields-dialog still open double click the status bar -> crash (normally double clicking the status bar with an open fields-dialog will dismiss the dialog)
interesting... mine crashes whether i dismiss the fields dialog or not...
MRU->ES: please have a look. Perhaps a good 1.1.3 issue...
Reproduced on SuSE Linux following the first description
OS->ES: Could you please create a _valid_ stacktrace.
Have a look at crash report 124750
That looks like a gsl problem. libpthread.so.0 + 0x912b -- could not find checksum in database libc.so.6 + 0x29d68 -- could not find checksum in database ImplHandleMouseEvent(Window*, unsigned short, unsigned char, long, long, unsigned long, unsigned short, unsigned short) /net/jumbo.germany/sol1/SRC680/src.m34/vcl/source/window/winproc.cxx:843 ImplWindowFrameProc(void*, SalFrame*, unsigned short, void const*) /net/jumbo.germany/sol1/SRC680/src.m34/vcl/source/window/winproc.cxx:2207 X11SalFrame::HandleMouseEvent(_XEvent*) ../../../inc/salframe.hxx:271 .L2696 /net/jumbo.germany/sol1/SRC680/src.m34/vcl/unx/source/window/salframe.cxx:3471 SalDisplay::Dispatch(_XEvent*) /net/jumbo.germany/sol1/SRC680/src.m34/vcl/unx/source/app/saldisp.cxx:2493 SalX11Display::Yield(unsigned char) .
SBA:This doesn't affect the average user. Those who know about this one are probably only the ones who read this and they know convenient workarounds. So nobody's work is in real danger. Target set to "OOo later".
The solution to the problem can be seen in http://bugzilla.ximian.com/show_bug.cgi?id=59374 The patch can be found in the above URL.
setting to type patch...
Created attachment 16521 [details] patch from apremchandran posted to ximian's bugzilla
ssa: reassign to hdu
HDU->CD: when cleaning up my intray it stumbled over this nice patch to the framework. Please handle.
cd: Thanks for the patch and the support. OOo 2.0.x doesn't have a status bar configuration anymore. I think we will rewrite the whole configuration code for the next major. Due to limited resources we cannot fix every minor bug on OOo 1.1.x, therefore I set this bug to "WONTFIX".
closing