https://bz.apache.org/ooo/show_bug.cgi?id=128612
--- Comment #13 from [email protected] --- The failure can be determined earlier, by the behaviour inside ScTransferObj::GetOwnClipboard() from main/sc/source/ui/app/transobj.cxx: 216 ScTransferObj* ScTransferObj::GetOwnClipboard( Window* pUIWin ) 217 { 218 ScTransferObj* pObj = SC_MOD()->GetClipData().pCellClipboard; 219 if ( pObj && pUIWin ) 220 { 221 // check formats to see if pObj is really in the system clipboard 222 223 // pUIWin is NULL when called from core (IsClipboardSource), 224 // in that case don't access the system clipboard, because the call 225 // may be from other clipboard operations (like flushing, #86059#) 226 227 TransferableDataHelper aDataHelper( TransferableDataHelper::CreateFromSystemClipboard( pUIWin ) ); 228 if ( !aDataHelper.HasFormat( SOT_FORMATSTR_ID_DIF ) ) 229 { 230 // DBG_ERROR("ScTransferObj wasn't released"); 231 pObj = NULL; 232 } 233 } 234 return pObj; 235 } When the paste is correct, this function is called twice. The first call has: ---snip--- #0 ScTransferObj::GetOwnClipboard (pUIWin=0x0) at main/sc/source/ui/app/transobj.cxx:219 #1 0x000000080e147581 in lcl_IsCellPastePossible (rData=...) at main/sc/source/ui/view/cellsh.cxx:405 #2 0x000000080e147706 in ScCellShell::ClipboardChanged (this=0x80bbc2f10, pDataHelper=0x7fffffffd1a0) at main/sc/source/ui/view/cellsh.cxx:437 #3 ScCellShell::LinkStubClipboardChanged (pThis=0x80bbc2f10, pCaller=0x7fffffffd1a0) at main/sc/source/ui/view/cellsh.cxx:433 #4 0x00000008017c4c5f in Link::Call (this=0x80946ca70, pCaller=0x7fffffffd1a0) at main/solver/450/unxfbsdx/inc/tools/link.hxx:135 #5 TransferableClipboardListener::changedContents (this=0x80946ca40, rEventObject=<optimized out>) at main/svtools/source/misc/cliplistener.cxx:63 #6 0x0000000805e73b3e in x11::X11Clipboard::fireChangedContentsEvent (this=this@entry=0x80bbe1f00) at main/vcl/unx/generic/dtrans/X11_clipboard.cxx:116 #7 0x0000000805e740b0 in x11::X11Clipboard::setContents (this=0x80bbe1f00, xTrans=..., xClipboardOwner=...) at main/vcl/unx/generic/dtrans/X11_clipboard.cxx:188 #8 0x00000008017e3df4 in TransferableHelper::CopyToClipboard (this=0x80be467c0, pWindow=<optimized out>) at main/svtools/source/misc/transfer.cxx:1152 #9 0x000000080e0b8f40 in ScViewFunc::CopyToClip (this=0x80bbe4090, pClipDoc=0x81006b810, bCut=<optimized out>, bApi=0 '\000', bIncludeObjects=1 '\001', bStopEdit=<optimized out>) at main/sc/source/ui/view/viewfun3.cxx:390 ---snip--- but in ScTransferObj::GetOwnClipboard(), pObj and pUIWin are both NULL (line 219 above). Only the second call has valid pObj and pUIWin, and takes place as described in my previous message. When the paste is incorrect, this function is called 5 times: from ScCellShell::ClipboardChanged() -> lcl_IsCellPastePossible(), from x11::X11Clipboard::setContents(), again from ScCellShell::ClipboardChanged() -> lcl_IsCellPastePossible(), then ScCellShell::PasteFromClipboard() which breaks because ScTransferObj::GetOwnClipboard() returns the wrong result, leading to the final broken ScViewFunc::PasteFromSystem(). But in all these calls, pObj is ALWAYS NULL, unlike the correct case where pObj is valid! In ScTransferObj::GetOwnClipboard(): 218 ScTransferObj* pObj = SC_MOD()->GetClipData().pCellClipboard; and that pCellClipboard field can only be set by: 694 void ScModule::SetClipObject( ScTransferObj* pCellObj, ScDrawTransferObj* pDrawObj ) 695 { 696 DBG_ASSERT( !pCellObj || !pDrawObj, "SetClipObject: not allowed to set both objects" ); 697 698 aClipData.pCellClipboard = pCellObj; 699 aClipData.pDrawClipboard = pDrawObj; 700 } a breakpoint on ScModule::SetClipObject should help find who is setting it incorrectly. Apparently this is how pObj becomes NULL: Thread 7 hit Breakpoint 4.2, ScModule::SetClipObject (this=0x80aba9410, pCellObj=0x0, pDrawObj=0x0) at main/sc/source/ui/app/scmod.cxx:696 696 DBG_ASSERT( !pCellObj || !pDrawObj, "SetClipObject: not allowed to set both objects" ); $142 = (ScTransferObj *) 0x0 #0 ScModule::SetClipObject (this=0x80aba9410, pCellObj=0x0, pDrawObj=0x0) at main/sc/source/ui/app/scmod.cxx:696 #1 0x000000080e01a638 in ScTransferObj::ObjectReleased (this=0x80be467c0) at main/sc/source/ui/app/transobj.cxx:484 #2 0x00000008017e0cd5 in TransferableHelper::lostOwnership (this=0x80be467c0) at main/svtools/source/misc/transfer.cxx:578 #3 0x0000000805e73d2a in x11::X11Clipboard::clearContents (this=0x80bbe1f00) at main/vcl/unx/generic/dtrans/X11_clipboard.cxx:141 #4 0x0000000805e7c28e in x11::SelectionManager::handleXEvent (this=this@entry=0x8056e1400, rEvent=...) at main/vcl/unx/generic/dtrans/X11_selection.cxx:3668 #5 0x0000000805e85330 in x11::SelectionManager::dispatchEvent (this=this@entry=0x8056e1400, millisec=millisec@entry=1000) at main/vcl/unx/generic/dtrans/X11_selection.cxx:3749 #6 0x0000000805e854ef in x11::SelectionManager::run (pThis=0x8056e1400) at main/vcl/unx/generic/dtrans/X11_selection.cxx:3781 #7 0x00000008003f8762 in osl_thread_start_Impl (pData=0x80a94bf90) at thread.c:266 #8 0x00000008006f0b52 in ??? () at /lib/libthr.so.3 #9 0x0000000000000000 in ??? () The X11 clipboard selection ownership is lost, and we are sent a SelectionClear event. But how does that happen? Who takes over the selection's ownership? Why? -- You are receiving this mail because: You are the assignee for the issue.
