User forums > Nightly builds

The 22 March 2014 build (9744) is out.

<< < (7/15) > >>

MortenMacFly:

--- Quote from: Alpha on April 04, 2014, 12:09:29 am ---@ollydbg: I will see if I can test your patch for side effects this weekend.

--- End quote ---
The side effect is that we leak memory with every calltip. :P

Edit: And thee is also no crash for me on Windows. I am doing exactly as shown in the video...

Did you try with the most recent C::B from trunk (wxScintilla 3.4.1)?

ollydbg:

--- Quote from: MortenMacFly on April 04, 2014, 07:06:02 am ---
--- Quote from: Alpha on April 04, 2014, 12:09:29 am ---@ollydbg: I will see if I can test your patch for side effects this weekend.

--- End quote ---
The side effect is that we leak memory with every calltip. :P

Edit: And thee is also no crash for me on Windows. I am doing exactly as shown in the video...

Did you try with the most recent C::B from trunk (wxScintilla 3.4.1)?

--- End quote ---
Ok, I will try it right now, I was using rev 9744(which I think is wxScintilla 3.3.9).

EDIT: Same crash here in latest svn rev 9745. I'm under WinXP, wx2.8.12, MinGW-Build-GCC-4.7.3.

ollydbg:
I debug for a while, and I found that:
1, if another APP was activate, the C::B will receive a "de-active" event. If currently the Tooltip is the active window, it is the window to receive such event.

2, to handle the event, CCManager try to do these

--- Code: ---// cbEVT_APP_DEACTIVATED
void CCManager::OnDeactivateApp(CodeBlocksEvent& event)
{
    DoHidePopup();
    cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
    if (ed)
    {
        cbStyledTextCtrl* stc = ed->GetControl();
        if (stc->CallTipActive())
            stc->CallTipCancel();
        m_CallTipActive = wxSCI_INVALID_POSITION;
    }
    event.Skip();
}

--- End code ---
Here, in the  stc->CallTipCancel();, the window who receive the "de-active" event was destroyed. By internally run a "delete this" of the wxWindow, the wxWindow is totally destroyed.

3, But note the destroy happens in a member function of the wxWindow, which is:

--- Code: ---WXLRESULT wxWindowMSW::MSWWindowProc(WXUINT message, WXWPARAM wParam, WXLPARAM lParam)
{
    // did we process the message?
    bool processed = false;
.....
.....
        case WM_KILLFOCUS:
            processed = HandleKillFocus((WXHWND)(HWND)wParam);
            break;


.....
.....
    if ( !processed )
    {
#ifdef __WXDEBUG__
        wxLogTrace(wxTraceMessages, wxT("Forwarding %s to DefWindowProc."),
                   wxGetMessageName(message));
#endif // __WXDEBUG__
        rc.result = MSWDefWindowProc(message, wParam, lParam);
    }

    return rc.result;
}

--- End code ---

Here, HandleKillFocus() function call return false, so we have a chance to call

--- Code: ---rc.result = MSWDefWindowProc(message, wParam, lParam);
--- End code ---
Which is actually

--- Code: ---rc.result = this->MSWDefWindowProc(message, wParam, lParam);
--- End code ---
But "this" is already deleted, so we get a crash here.

ollydbg:
With the analysis of my previous post, I find a better way to solve this crash issue. I mean "Do not destroy the tip window in CCManager::OnDeactivateApp"
Just see the patch below, tested and works fine.


--- Code: --- src/sdk/ccmanager.cpp | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/sdk/ccmanager.cpp b/src/sdk/ccmanager.cpp
index 58c25cc..9d5fb39 100644
--- a/src/sdk/ccmanager.cpp
+++ b/src/sdk/ccmanager.cpp
@@ -463,7 +463,7 @@ void CCManager::OnDeactivateApp(CodeBlocksEvent& event)
     {
         cbStyledTextCtrl* stc = ed->GetControl();
         if (stc->CallTipActive())
-            stc->CallTipCancel();
+            ;//stc->CallTipCancel();
         m_CallTipActive = wxSCI_INVALID_POSITION;
     }
     event.Skip();

--- End code ---

White-Tiger:
and that handler function was added in r9680 ... that's why it crashes since then :P

btw. my CB didn't only crash when I switched focus to other window... it also crashes when just using CB as well... maybe because another control gets focus? Or is it a different one?
Anyway... I tried to debug it once, but didn't gave me any better or useful back trace

Navigation

[0] Message Index

[#] Next page

[*] Previous page