Author Topic: The 22 March 2014 build (9744) is out.  (Read 104696 times)

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: The 22 March 2014 build (9744) is out.
« Reply #30 on: April 04, 2014, 07:06:02 am »
@ollydbg: I will see if I can test your patch for side effects this weekend.
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)?
« Last Edit: April 04, 2014, 07:11:20 am by MortenMacFly »
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #31 on: April 04, 2014, 07:28:27 am »
@ollydbg: I will see if I can test your patch for side effects this weekend.
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)?
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.

« Last Edit: April 04, 2014, 07:49:07 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #32 on: April 04, 2014, 08:26:33 am »
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();
}
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;
}

Here, HandleKillFocus() function call return false, so we have a chance to call
Code
rc.result = MSWDefWindowProc(message, wParam, lParam);
Which is actually
Code
rc.result = this->MSWDefWindowProc(message, wParam, lParam);
But "this" is already deleted, so we get a crash here.

If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #33 on: April 04, 2014, 08:37:22 am »
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();
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline White-Tiger

  • Multiple posting newcomer
  • *
  • Posts: 83
Re: The 22 March 2014 build (9744) is out.
« Reply #34 on: April 04, 2014, 01:10:39 pm »
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
Windoze 8.1 x86_64 16GiB RAM, wxWidgets-2.8x (latest,trunk), MinGW-builds (latest, posix-threads)
Code::Blocks (x86 , latest , selection length patch , build option fixes/additions , toggle comments)

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: The 22 March 2014 build (9744) is out.
« Reply #35 on: April 06, 2014, 10:58:05 pm »
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" [...]
Unfortunately, if we do not cancel the tip window, it can become "stuck" on top of everything until Code::Blocks is reactivated.

@all: If you are experiencing this crash, please test the following patch.
Code
Index: src/sdk/ccmanager.cpp
===================================================================
--- src/sdk/ccmanager.cpp (revision 9745)
+++ src/sdk/ccmanager.cpp (working copy)
@@ -114,6 +114,8 @@
 const int idCallTipNext = wxNewId();
 const int idCallTipPrevious = wxNewId();
 
+DEFINE_EVENT_TYPE(cbDEFERRED_CALLTIP_CANCEL_EVENT)
+
 // milliseconds
 #define CALLTIP_REFRESH_DELAY 90
 #define AUTOCOMP_SELECT_DELAY 35
@@ -292,6 +294,7 @@
     Connect(idCallTipTimer,        wxEVT_TIMER, wxTimerEventHandler(CCManager::OnTimer));
     Connect(idAutoLaunchTimer,     wxEVT_TIMER, wxTimerEventHandler(CCManager::OnTimer));
     Connect(idAutocompSelectTimer, wxEVT_TIMER, wxTimerEventHandler(CCManager::OnTimer));
+    Connect(cbDEFERRED_CALLTIP_CANCEL_EVENT, wxCommandEventHandler(CCManager::OnDeferredCallTipCancel));
 }
 
 // class destructor
@@ -309,6 +312,7 @@
     Disconnect(idCallTipTimer);
     Disconnect(idAutoLaunchTimer);
     Disconnect(idAutocompSelectTimer);
+    Disconnect(cbDEFERRED_CALLTIP_CANCEL_EVENT);
 }
 
 cbCodeCompletionPlugin* CCManager::GetProviderFor(cbEditor* ed)
@@ -463,7 +467,10 @@
     {
         cbStyledTextCtrl* stc = ed->GetControl();
         if (stc->CallTipActive())
-            stc->CallTipCancel();
+        {
+            wxCommandEvent pendingCancel(cbDEFERRED_CALLTIP_CANCEL_EVENT);
+            AddPendingEvent(pendingCancel);
+        }
         m_CallTipActive = wxSCI_INVALID_POSITION;
     }
     event.Skip();
@@ -880,6 +887,13 @@
         m_CallTipTimer.Start(CALLTIP_REFRESH_DELAY, wxTIMER_ONE_SHOT);
 }
 
+void CCManager::OnDeferredCallTipCancel(wxCommandEvent& WXUNUSED(event))
+{
+    cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
+    if (ed)
+        ed->GetControl()->CallTipCancel();
+}
+
 #ifdef __WXMSW__
 void CCManager::OnPopupScroll(wxMouseEvent& event)
 {
Index: src/include/ccmanager.h
===================================================================
--- src/include/ccmanager.h (revision 9745)
+++ src/include/ccmanager.h (working copy)
@@ -57,6 +57,7 @@
         /** event handler to show documentation, when user changes autocomplete selection */
         void OnAutocompleteSelect(wxListEvent& event);
         void OnAutocompleteHide(wxShowEvent& event);
+        void OnDeferredCallTipCancel(wxCommandEvent& event);
 #ifdef __WXMSW__
         /** intercept cbStyledTextCtrl scroll events and forward to autocomplete/documentation popups */
         void OnPopupScroll(wxMouseEvent& event);

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #36 on: April 07, 2014, 04:54:56 am »
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" [...]
Unfortunately, if we do not cancel the tip window, it can become "stuck" on top of everything until Code::Blocks is reactivated.
I don't see such issue, at least on my XP with my patch. But the "stuck" may happens in other OS/system.

Quote
@all: If you are experiencing this crash, please test the following patch.
Code
Index: src/sdk/ccmanager.cpp
===================================================================
--- src/sdk/ccmanager.cpp (revision 9745)
+++ src/sdk/ccmanager.cpp (working copy)
@@ -114,6 +114,8 @@
 const int idCallTipNext = wxNewId();
 const int idCallTipPrevious = wxNewId();
 
+DEFINE_EVENT_TYPE(cbDEFERRED_CALLTIP_CANCEL_EVENT)
+
 // milliseconds
 #define CALLTIP_REFRESH_DELAY 90
 #define AUTOCOMP_SELECT_DELAY 35
@@ -292,6 +294,7 @@
     Connect(idCallTipTimer,        wxEVT_TIMER, wxTimerEventHandler(CCManager::OnTimer));
     Connect(idAutoLaunchTimer,     wxEVT_TIMER, wxTimerEventHandler(CCManager::OnTimer));
     Connect(idAutocompSelectTimer, wxEVT_TIMER, wxTimerEventHandler(CCManager::OnTimer));
+    Connect(cbDEFERRED_CALLTIP_CANCEL_EVENT, wxCommandEventHandler(CCManager::OnDeferredCallTipCancel));
 }
 
 // class destructor
@@ -309,6 +312,7 @@
     Disconnect(idCallTipTimer);
     Disconnect(idAutoLaunchTimer);
     Disconnect(idAutocompSelectTimer);
+    Disconnect(cbDEFERRED_CALLTIP_CANCEL_EVENT);
 }
 
 cbCodeCompletionPlugin* CCManager::GetProviderFor(cbEditor* ed)
@@ -463,7 +467,10 @@
     {
         cbStyledTextCtrl* stc = ed->GetControl();
         if (stc->CallTipActive())
-            stc->CallTipCancel();
+        {
+            wxCommandEvent pendingCancel(cbDEFERRED_CALLTIP_CANCEL_EVENT);
+            AddPendingEvent(pendingCancel);
+        }
         m_CallTipActive = wxSCI_INVALID_POSITION;
     }
     event.Skip();
@@ -880,6 +887,13 @@
         m_CallTipTimer.Start(CALLTIP_REFRESH_DELAY, wxTIMER_ONE_SHOT);
 }
 
+void CCManager::OnDeferredCallTipCancel(wxCommandEvent& WXUNUSED(event))
+{
+    cbEditor* ed = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
+    if (ed)
+        ed->GetControl()->CallTipCancel();
+}
+
 #ifdef __WXMSW__
 void CCManager::OnPopupScroll(wxMouseEvent& event)
 {
Index: src/include/ccmanager.h
===================================================================
--- src/include/ccmanager.h (revision 9745)
+++ src/include/ccmanager.h (working copy)
@@ -57,6 +57,7 @@
         /** event handler to show documentation, when user changes autocomplete selection */
         void OnAutocompleteSelect(wxListEvent& event);
         void OnAutocompleteHide(wxShowEvent& event);
+        void OnDeferredCallTipCancel(wxCommandEvent& event);
 #ifdef __WXMSW__
         /** intercept cbStyledTextCtrl scroll events and forward to autocomplete/documentation popups */
         void OnPopupScroll(wxMouseEvent& event);
Tested, and works fine! I think your patch is better than mine.  ;)
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

tuldok89

  • Guest
Re: The 22 March 2014 build (9744) is out.
« Reply #37 on: April 09, 2014, 01:47:32 am »
Any steps to reproduce this crash?
1) Open Notepad
2) Open Codeblocks with a test project and check "Display info when hovering mouse over a token in the editor" from Settings->Editor->Code completion->Code completion
3) Put the mouse cursor over a token in editor and let to apear the little pop-up with description.
4) Now click on Notepad window...

BOOM!!!  :D
Code
codeblocks.exe caused an Access Violation at location bc68551c Reading from location bc68551c.

Registers:
eax=bc68551c ebx=00000d88 ecx=071398a8 edx=00000000 esi=071398a8 edi=00000d88
eip=bc68551c esp=0022f548 ebp=0022f9c4 iopl=0         nv up ei pl nz ac po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010216

Call stack:
BC68551C
6852EC49  wxmsw28u.dll:6852EC49  _ZN8wxWindow13MSWWindowProcEjjl
68527BA0  wxmsw28u.dll:68527BA0  _Z9wxWndProcP6HWND__jjl@16
775EC4E7  USER32.dll:775EC4E7  gapfnScSendMessage
775EC5E7  USER32.dll:775EC5E7  gapfnScSendMessage
775E4F0E  USER32.dll:775E4F0E  GetScrollBarInfo
775E4F7D  USER32.dll:775E4F7D  GetScrollBarInfo
77B8702E  ntdll.dll:77B8702E  KiUserCallbackDispatcher
68511E35  wxmsw28u.dll:68511E35  _ZN11wxEventLoop8DispatchEv
6858B3B2  wxmsw28u.dll:6858B3B2  _ZN17wxEventLoopManual3RunEv
685724D0  wxmsw28u.dll:685724D0  _ZN9wxAppBase8MainLoopEv
00402922  codeblocks.exe:00402922
684F1D1C  wxmsw28u.dll:684F1D1C  _Z7wxEntryP11HINSTANCE__S0_Pci
00401D00  codeblocks.exe:00401D00
004010FD  codeblocks.exe:004010FD
77BA37EB  ntdll.dll:77BA37EB  RtlInitializeExceptionChain
77BA37BE  ntdll.dll:77BA37BE  RtlInitializeExceptionChain

I think that the error was introduced in latest commits with new CC plugin.

I am not able to reproduce this bug. Using the posted CB archive, under Windows 7 x64 Professional.

Offline cacb

  • Lives here!
  • ****
  • Posts: 536
Re: The 22 March 2014 build (9744) is out.
« Reply #38 on: April 21, 2014, 12:07:01 pm »
I have got a question relating to pre-built Nightly builds of Code::Blocks:

Under Win7 I am using the pre-built nightly build of C::B in combination with the MSVC2010 compiler and wxWidgets 3.0 self-built using MSVC2010. This all works fine.  However, sometimes I'd like to use things in wxContribItems (e.g. wxled) , but apparently there is no MSVC makefile support or any other direct way of compiling wxContribItems with this setup. Am I right?

On Linux, where I build C::B from source, I can see  wxContribItems  under codeblocks-13.12svn/src/plugins/contrib/wxContribItems/ , but I'm not really sure if things like wxled, KWIK need to be considered "plugins", or at least it would be nice to have the ability to use them in projects using the MSVC compiler, just like the rest of wxWidgets.

Any thoughts?

Offline stahta01

  • Lives here!
  • ****
  • Posts: 7582
    • My Best Post
Re: The 22 March 2014 build (9744) is out.
« Reply #39 on: April 21, 2014, 05:27:02 pm »
I have got a question relating to pre-built Nightly builds of Code::Blocks:

Under Win7 I am using the pre-built nightly build of C::B in combination with the MSVC2010 compiler and wxWidgets 3.0 self-built using MSVC2010. This all works fine.  However, sometimes I'd like to use things in wxContribItems (e.g. wxled) , but apparently there is no MSVC makefile support or any other direct way of compiling wxContribItems with this setup. Am I right?

On Linux, where I build C::B from source, I can see  wxContribItems  under codeblocks-13.12svn/src/plugins/contrib/wxContribItems/ , but I'm not really sure if things like wxled, KWIK need to be considered "plugins", or at least it would be nice to have the ability to use them in projects using the MSVC compiler, just like the rest of wxWidgets.

Any thoughts?

wxContribItems is not a CB Plugins; but, are wxWidgets addons. Most are from wxCode website. http://wxcode.sourceforge.net/
I suggest looking to wxCode website on how to build them for under MSVC2010 compiler and wxWidgets 3.0.
If you can NOT find them, I suggest a new post in the "General (but related to Code::Blocks)" sub-forum on the source of the wxContribItems components.

Tim S.
C Programmer working to learn more about C++ and Git.
On Windows 7 64 bit and Windows 10 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #40 on: April 22, 2014, 10:06:20 am »
and that handler function was added in r9680 ... that's why it crashes since then :P
Forgot to say that this crash is already fixed in trunk (r9746).
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline carra

  • Multiple posting newcomer
  • *
  • Posts: 117
Re: The 22 March 2014 build (9744) is out.
« Reply #41 on: April 22, 2014, 12:38:26 pm »
Abbreviations have stopped working correctly (at least under Windows) if trying to replace them when partially written. I have attached an image showing what happens instead.

This does not seem to happen when I trigger their replacement having written the full abreviation name.

Offline carra

  • Multiple posting newcomer
  • *
  • Posts: 117
Re: The 22 March 2014 build (9744) is out.
« Reply #42 on: April 22, 2014, 01:09:48 pm »
OK reading my own message I'm nof sure if I have explained it correctly so I will write it as "steps to reproduce":

1) Write the beginning of some abbreviation, but leave it incomplete. for instance, using a built-in one: "tod" for today
2) Trigger auto-complete, either selecting its menu option or pressing a hotkey. The pop-up list appears, but all elements end in "?0"
3) Press enter, and instead of today's date, you will get "today?0"

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: The 22 March 2014 build (9744) is out.
« Reply #43 on: April 23, 2014, 04:25:53 pm »
Abbreviations have stopped working correctly (at least under Windows) if trying to replace them when partially written. [...]
Oops, my fault.  I forgot to commit some local changes.  ... Unfortunately, the introduction of CCManager has further destabilized this feature of Abbreviations (which was already bugged, because it required event handling to be in a specific order, which it could not control).
This code will half-fix the problem (the easy part, which was sitting on my computer and hiding the problem from me).  I will try to deal with the event handling this weekend.
Code
Index: src/plugins/abbreviations/abbreviations.cpp
===================================================================
--- src/plugins/abbreviations/abbreviations.cpp (revision 9755)
+++ src/plugins/abbreviations/abbreviations.cpp (working copy)
@@ -169,6 +169,8 @@
 void Abbreviations::OnEditAutoComplete(cb_unused wxCommandEvent& event)
 {
     cbEditor* editor = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
+    if (!editor)
+        return;
     cbStyledTextCtrl* control = editor->GetControl();
 
     const AutoCompleteMap& acm = *GetCurrentACMap(editor);
@@ -200,6 +202,7 @@
             items.Sort();
             wxString itemsStr = GetStringFromArray(items, _T(" "));
             control->AutoCompSetSeparator(_T(' '));
+            control->AutoCompSetTypeSeparator(_T('?'));
             control->AutoCompShow(endPos-startPos, itemsStr);
         }
         m_IsAutoCompVisible = control->AutoCompActive();

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: The 22 March 2014 build (9744) is out.
« Reply #44 on: April 26, 2014, 12:24:43 am »
Code completion always kicks in after the 3rd character regardless of the setting in 'settings->editor->code completion->code completion tab->automatically launch when typed # letters'. It even kicks in even if the box is unchecked. Is that something by my side, a bug or intentional? I prefer the setting to be 4 and it was working correctly before.

Win7 SP1