Apache OpenOffice (AOO) Bugzilla – Issue 74392
aquavcl01: tooltip crash
Last modified: 2007-07-09 22:35:18 UTC
Hi, with clean m202 based aquavcl01, clean, just installed OOo and after the successful FirstStartWizard session: 1. start sofficebin -> initial window with three icons in the toolbar appear. 2. quickly move over them to see their tooltips. -> after a second or two, crash: >*>_> ReleaseGraphics >*>_> ~AquaSalFrame >*>_> SetPointer Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000009 0x00000009 in ?? () (gdb) where #0 0x00000009 in ?? () #1 0x0135c537 in SalFrame::CallCallback (this=0x54898455, nEvent=49284, pEvent=0x12f3e824) at salframe.hxx:315 Previous frame inner to this frame (corrupt stack?) (gdb) Please write here if you can reproduce it.
Adding to Meta Issue.
It is possible to reliably un-reproduce these crashes. You will need a combination of speed and careful mouse movement to avoid triggering any tooltips while doing this: Go to menu Tools - Options - OOo - General - Help - uncheck Tips. Now the tooltips crashing is no longer seen.
Carefully moving the mouse in from above the window, each of the tooltips can be displayed without a crash. See attached picture.
Created attachment 42920 [details] tooltips displayed slowly from above
Quickly move mouse over the toolbar icons, for me it always ends here: Thread 0 Crashed: 0 libvcl680mxi.dylib 0x011c150f Window::GetStyle() const + 15 (window2.cxx:1703) 1 libvcl680mxi.dylib 0x011b930e ImplHandleResize(Window*, long, long) + 28 2 libvcl680mxi.dylib 0x011ac39a Window::SetPosSizePixel(long, long, long, long, unsigned short) + 456 3 libvcl680mxi.dylib 0x011c1d88 Window::SetPosPixel(Point const&) + 82 (window2.cxx:2044) 4 libvcl680mxi.dylib 0x0100ad99 ImplSetHelpWindowPos(Window*, unsigned short, unsigned short, Point const&, Rectangle const*) + 1205
Created attachment 42921 [details] note frame 400
The long stacktrace with many times CallCallBack is made by slowly mouse over the top row of toolbar icons and showing the tooltips, repeat this many times. I just made another with 405 lines. I can reliably reproduce in range 50-130 backtrace with mulitple CallCallBack. Note that some icons are not drawn (not visible) until the mouse over. The mouse button is not pressed at any time.
Created attachment 42923 [details] reproduce - with extended tooltips
Test suggested by pjanik: disable MouseMove events. Now the tips work in the correct manner ( delay, then display, then removed ) when the mouse is moved over a toolbat icon and the mouse button held down for a while. How to disable: +++ aqua/source/window/salframe.cxx 13 Feb 2007 11:48:57 -0000 @@ -1202,7 +1202,7 @@ case kEventMouseUp: eventkind = SALEVENT_MOUSEBUTTONUP; break; - case kEventMouseMoved: +// case kEventMouseMoved: case kEventMouseDragged: eventkind = SALEVENT_MOUSEMOVE; break;
Another test: disable mouse button down (see how below). The mouse down action is stopped (for example the font name list cannot be activated). But the bad behaviour of tooltips continues, and crash still happens. +++ aqua/source/window/salframe.cxx 14 Feb 2007 09:15:20 -0000 @@ -1196,9 +1196,9 @@ switch (GetEventKind(inEvent)) { - case kEventMouseDown: - eventkind = SALEVENT_MOUSEBUTTONDOWN; - break; +// case kEventMouseDown: +// eventkind = SALEVENT_MOUSEBUTTONDOWN; +// break;
The proper behaviour of tool tips for an object would require events such as object.mouse_enter and object.mouse_leave. The tooltip starts when the mouse enters, and stops or will not start again until after object.mouse_leave. How does this work for X11? There is a test for these events in vcl/source/window/winproc.cxx line 680 and sets a flag MOUSE_ENTERWINDOW at line 721.
This patch stops the tooltip crashes, but the result is not quite correct ;) Index: aqua/source/window/salframe.cxx =================================================================== RCS file: /cvs/gsl/vcl/aqua/source/window/salframe.cxx,v retrieving revision 1.46.112.48 diff -u -r1.46.112.48 salframe.cxx --- aqua/source/window/salframe.cxx 13 Feb 2007 09:16:30 -0000 1.46.112.48 +++ aqua/source/window/salframe.cxx 15 Feb 2007 09:17:51 -0000 @@ -627,7 +627,7 @@ currentWindowRect.left, currentWindowRect.top, currentWindowRect.right - currentWindowRect.left, currentWindowRect.bottom - currentWindowRect.top); fprintf(stderr, "SetPosSize: New rect (x: %d, y: %d, w: %d, h: %d)\n", nX, nY, nWidth, nHeight); */ - SetWindowBounds(mrWindow, kWindowStructureRgn, &newWindowRect); +// SetWindowBounds(mrWindow, kWindowStructureRgn, &newWindowRect); UpdateFrameGeometry();
Next attachment is a screenshot of the behaviour with the last patch. There is no crash but every child window instead becomes a separate parent window/frame. (Not sure if that is the right description!). I cannot capture the tooltip example as it is timed - but imagine a little tooltip in the top left hand corner.
Created attachment 43030 [details] test patch to stop crash
While looking into this issue I noticed the following behavior, which may be getting s closer to the real problem: 1) Put breakpoints as shown: Breakpoint 8, Window::IsNativeControlSupported (this=0x6d87b00, nType=100, nPart=1) at window3.cxx:95 (gdb) Breakpoint 7, AquaSalGraphics::IsNativeControlSupported (this=0x6d83720, nType=140, nPart=1) at salnativewidgets.cxx:186 (gdb) 2) Move the mouse over the toolbars to activevate the tooltips. 3) Step from Window::IsNativeControlSupported into AquaSalGraphics::IsNativeControlSupported 4) Notice that nType changes from 100 to 140? I thought this meant that there is a conflicting definition for ControlType, but so far I have not been able to find it. Other ideas?
Here is a disassembly of the exact place where the value of nType changes - at the return from the thunk in AquaSalGraphics::IsNativeControlSupported: 1: nType = 100 0x01250afa <_ZN15AquaSalGraphics24IsNativeControlSupportedEmm+8>: call 0x127076c <__i686.get_pc_thunk.bx> 1: nType = 100 0x0127076c in __i686.get_pc_thunk.bx () at gcach_ftyp.cxx:325 0x0127076c <__i686.get_pc_thunk.bx+0>: mov (%esp),%ebx 0x0127076f <__i686.get_pc_thunk.bx+3>: ret 0x01250aff <_ZN15AquaSalGraphics24IsNativeControlSupportedEmm+13>: movb $0x0,-9(%ebp) 1: nType = 140 It seems like a problem with the inheritance, but beyond my capability at the moment. Does it happen for anyone else?
Created attachment 44027 [details] patch to salframe.cxx to fix tooltip crashes
Patch salframe_tooltip.cxx.diff works by limiting the events that windows of type kHelpWindowClass (tooltips) respond to. It seems that CreateNewSystemWindow was registering handlers for tooltip windows that could not be handled. Works on MacBook - others please try.
I confirm : the patch works fine : no more crash, tooltips appear, disappear when moving the mouse. This issue is IMHO fixed. +1 for it's integration ericb->msicotte Thank you very much for your patch, and your great work ! ( I imagine, it took you some time to analyse the situation with all those events)
Patch tested on iMac Intel with m202 and no other patches. The crash is gone and tooltips behave as expected on the toolbars. I notice in dialogs the tooltips only work *sometimes* but that will be a different issue.
msicotte: can you please identify which eventhandler exactly is causeing the crash? This way we could identify the real problem.
To get you started, HandleOOoSalUserEvent causes the crash with the corrupt stack frame. But other events cause different crashes. I will investigate all and come back with a comprehensive list.
I have to retract my previous comment - this week I have only removed HandleWindowBoundsChangedEvent for tooltips and I have had no crashes. I am attaching a patch that does only this, but includes all of the other events in a manner that allows for easy commenting if others would like to try. If this is the only troublemaker, then I can propose a much simpler patch.
Created attachment 44262 [details] patch for testing events to remove for tooltips
Created attachment 44295 [details] patch for testing - adds fix for menu to tooltip crash fix
I noticed that when the tooltip window was displayed, the menu bar was blanked. So I have amended the patch to add some code to keep the menu in view. Patch attached.
Created attachment 44298 [details] Fixed bug in earlier patch disabling closebox
The earlier patch had an error that caused the close box to be disabled on the windows. Corrected patch attached.
ericb->msicotte Thanks for all the work you do. @all : please test and report what you think important. It would be great to fix, or at least find a clean workaround to this bug.
Created attachment 45038 [details] Workaround for event that causes crash, with fix for disappearing menu
Created attachment 45061 [details] Workaround event that causes tooltip crash
Created attachment 45062 [details] Workaround event that causes tooltip crash (an extra hunk in the last one)
msicotte: please commit your last patch. Works OK.
final patch committed
Added issue to aquavcl01 cws
Verify that issue is indeed fixed in aquavcl01 cws through build provided by Eric Bachard. James McKenzie
Change target milestone to 2.3.
Still ok in SRC680_m220 Closing