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

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: The 22 March 2014 build (9744) is out.
« Reply #15 on: April 01, 2014, 09:46:45 pm »
I still wonder why it seems like you guys never got a crash.. my CB is crashing since the CC changes... and it crashes just after a few minutes running... Crashes while writing code, while scrolling, while compiling... actually at every single moment a crash can happen...
Bugs seem to magically not occur whenever the writer of the piece of code is present :-\.

I am in the process of recompiling everything with MinGW 4.7 (I normally use TDM 4.8) to see if that enables me to reproduce these crashes.

Edit: wxWidgets has build errors with my new 4.7 installation; this might take a bit longer than expected.
« Last Edit: April 02, 2014, 12:08:12 am by Alpha »

Offline White-Tiger

  • Multiple posting newcomer
  • *
  • Posts: 83
Re: The 22 March 2014 build (9744) is out.
« Reply #16 on: April 02, 2014, 03:57:04 pm »
[...]
I am in the process of recompiling everything with MinGW 4.7 (I normally use TDM 4.8) to see if that enables me to reproduce these crashes.
[...]
That's one of the reasons I didn't look to much into it... Since I've updated my compiler as well when the problem started to occur, I can't be sure it's not a compiler problem... (MinGW-builds 4.8.2 rev3 SJLJ posix-threads, but DWARF had the same problem. And before that, I used the older MinGW-builds (same GCC, older MinGW64) from sourceforge.. but they are now part of MinGW64 directly)
It shouldn't be the compiler since my current Code::Blocks backup uses my rebuild wxWidgets and runs stable without any new crash so far..

As I said... it's just sad that debugging under Windows is a pain xD Even with WinSDK thus VC compiler and Code::Blocks... some symbols are just missing from time to time... not sure if Visual Studio is any better... (since it also uses cdb or WinDBG, I guess symbols will be missing from time to time anyway)
Is debugging under GNU/Linux reliable? So that symbols are never missing and a back trace is complete? I guess so... but don't know for sure.
« Last Edit: April 02, 2014, 04:03:42 pm by White-Tiger »
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 vwdvaan

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: The 22 March 2014 build (9744) is out.
« Reply #17 on: April 02, 2014, 04:02:45 pm »
I still wonder why it seems like you guys never got a crash.. my CB is crashing since the CC changes... and it crashes just after a few minutes running... Crashes while writing code, while scrolling, while compiling... actually at every single moment a crash can happen...
Bugs seem to magically not occur whenever the writer of the piece of code is present :-\.

I am in the process of recompiling everything with MinGW 4.7 (I normally use TDM 4.8) to see if that enables me to reproduce these crashes.

Edit: wxWidgets has build errors with my new 4.7 installation; this might take a bit longer than expected.
TDM-GCC 4.7.1, wxWidgets 2.8.12

// Debug
mingw32-make -j3 -f makefile.gcc CXXFLAGS="-fno-keep-inline-dllexport" SHARED=1 BUILD=debug UNICODE=1 DEBUG_INFO=1 DEBUG_FLAG=1 MONOLITHIC=1
mingw32-make -j3 -f makefile.gcc CXXFLAGS="-fno-keep-inline-dllexport" SHARED=0 BUILD=debug UNICODE=1 DEBUG_INFO=1 DEBUG_FLAG=1 MONOLITHIC=1

// Release
mingw32-make -j3 -f makefile.gcc CXXFLAGS="-Os -fno-keep-inline-dllexport" LDFLAGS=-s SHARED=1 BUILD=release UNICODE=1 DEBUG_INFO=0 DEBUG_FLAG=0 MONOLITHIC=1
mingw32-make -j3 -f makefile.gcc CXXFLAGS="-Os -fno-keep-inline-dllexport" LDFLAGS=-s SHARED=0 BUILD=release UNICODE=1 DEBUG_INFO=0 DEBUG_FLAG=0 MONOLITHIC=1

Attached is modified config.gcc and makefile.gcc to remove VENDOR and GCC version from dll names.

[attachment deleted by admin]
Win 10, MinGW 122.0, wxWidgets 3.1.7

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #18 on: April 02, 2014, 04:16:36 pm »
I still wonder why it seems like you guys never got a crash.. my CB is crashing since the CC changes... and it crashes just after a few minutes running... Crashes while writing code, while scrolling, while compiling... actually at every single moment a crash can happen...
That's why I'm using my stable #9673 :P
I can't see the crash issue in my system, so I have no idea how to hunt such bug. Sorry.
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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13406
    • Travis build status
Re: The 22 March 2014 build (9744) is out.
« Reply #19 on: April 02, 2014, 06:04:20 pm »
No crash on linux, too.
Can you describe the exact steps in greater detail?
How do you change between apps?
Can you reproduce it with a simple hello world projec or using codeblocks.cbp file?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline vwdvaan

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: The 22 March 2014 build (9744) is out.
« Reply #20 on: April 02, 2014, 07:06:54 pm »
I've recorded a short video with this crash.

https://app.box.com/s/obf7xjt9qvr78mvd43e9
Win 10, MinGW 122.0, wxWidgets 3.1.7

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1643
Re: The 22 March 2014 build (9744) is out.
« Reply #21 on: April 02, 2014, 07:41:55 pm »
No crash on linux, too.
Can you describe the exact steps in greater detail?
How do you change between apps?
Can you reproduce it with a simple hello world projec or using codeblocks.cbp file?

Open C::B, select File->New->Project->Console application->C++

Now open main.cpp. When CC ends parsing, put the mouse over (for example) cout. Then a box with "ostream std::cout" will pop up. Now, while the box is shown, if you give focus to any other application (by clicking on it or using Alt+Tab) C::B gives a segmentation fault.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #22 on: April 03, 2014, 01:48:58 am »
I've recorded a short video with this crash.

https://app.box.com/s/obf7xjt9qvr78mvd43e9
OK, thanks for the video, I can reproduce this crash on my system. I will debug it soon  :)
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: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #23 on: April 03, 2014, 08:26:32 am »
I build C::B against debug version of wx2.8.12, I found the bug happens in the line, see the image shot, the ebx value is ZERO.
So, "call ebx" get a crash.



This happens after the application lose focus(after this event handler call).
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: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #24 on: April 03, 2014, 08:37:42 am »
I noticed that the function   
Quote
// Calls an appropriate default window procedure
    virtual WXLRESULT MSWDefWindowProc(WXUINT nMsg, WXWPARAM wParam, WXLPARAM lParam);
is a virtual function, but I see from the previous image shot, the address is 0.
So, I guess this is caused by a wrong static_cast?
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: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #25 on: April 03, 2014, 03:34:50 pm »
OK, I found some clue.

When a tooltip window is destroyed, a function will be called
In sdk\wxscintilla\src\PlatWX.cpp line 749
Code
void Window::Destroy()
{
    if (wid) {
        Show(false);
        GETWIN(wid)->Destroy();
    }
    wid = 0;
}
This will internally call a "delete this" statement, so the whole Window object is deleted.

But later, I see that this deleted Window is still used, so some function like:
Code
// Main window proc
LRESULT WXDLLEXPORT APIENTRY _EXPORT wxWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    // trace all messages - useful for the debugging
#ifdef __WXDEBUG__
    wxLogTrace(wxTraceMessages,
               wxT("Processing %s(hWnd=%08lx, wParam=%8lx, lParam=%8lx)"),
               wxGetMessageName(message), (long)hWnd, (long)wParam, lParam);
#endif // __WXDEBUG__

    wxWindowMSW *wnd = wxFindWinFromHandle((WXHWND) hWnd);

    // when we get the first message for the HWND we just created, we associate
    // it with wxWindow stored in gs_winBeingCreated
    if ( !wnd && gs_winBeingCreated )
    {
        wxAssociateWinWithHandle(hWnd, gs_winBeingCreated);
        wnd = gs_winBeingCreated;
        gs_winBeingCreated = NULL;
        wnd->SetHWND((WXHWND)hWnd);
    }

    LRESULT rc;

    if ( wnd && wxEventLoop::AllowProcessing(wnd) )
        rc = wnd->MSWWindowProc(message, wParam, lParam);
    else
        rc = ::DefWindowProc(hWnd, message, wParam, lParam);

    return rc;
}
Will still be called. Note that in this case, "wnd" (in the statement of rc = wnd->MSWWindowProc(message, wParam, lParam);) is an already destroyed pointer in In sdk\wxscintilla\src\PlatWX.cpp line 749.


If I remember correctly, I have see such crash issue when I debug CC. Some one has a fix patch, let's see I can find it on the forum. :)
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: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #26 on: April 03, 2014, 03:40:03 pm »

If I remember correctly, I have see such crash issue when I debug CC. Some one has a fix patch, let's see I can find it on the forum. :)

It is here annoying crash when debugging CC's auto-suggestion
And I think p2rkw has a fix to the CC's auto suggestion list. Maybe we should have a similar fix for the tooltip window.
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: 6034
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 22 March 2014 build (9744) is out.
« Reply #27 on: April 03, 2014, 04:58:03 pm »
Code
 src/sdk/wxscintilla/src/scintilla/src/CallTip.cxx | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/sdk/wxscintilla/src/scintilla/src/CallTip.cxx b/src/sdk/wxscintilla/src/scintilla/src/CallTip.cxx
index 7dc23a4..64c9f0d 100644
--- a/src/sdk/wxscintilla/src/scintilla/src/CallTip.cxx
+++ b/src/sdk/wxscintilla/src/scintilla/src/CallTip.cxx
@@ -297,7 +297,11 @@ PRectangle CallTip::CallTipStart(int pos, Point pt, int textHeight, const char *
 void CallTip::CallTipCancel() {
  inCallTipMode = false;
  if (wCallTip.Created()) {
- wCallTip.Destroy();
+/* C::B begin */
+// wCallTip.Destroy();
+ wCallTip.Show(false);
+/* C::B end */
+
  }
 }
 
this fix the crash issue. but not sure it cause other issue, since I'm not quite familiar with the scintilla control, I just follow the way p2rkw did.
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 vwdvaan

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: The 22 March 2014 build (9744) is out.
« Reply #28 on: April 03, 2014, 07:34:45 pm »
Code
 src/sdk/wxscintilla/src/scintilla/src/CallTip.cxx | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/sdk/wxscintilla/src/scintilla/src/CallTip.cxx b/src/sdk/wxscintilla/src/scintilla/src/CallTip.cxx
index 7dc23a4..64c9f0d 100644
--- a/src/sdk/wxscintilla/src/scintilla/src/CallTip.cxx
+++ b/src/sdk/wxscintilla/src/scintilla/src/CallTip.cxx
@@ -297,7 +297,11 @@ PRectangle CallTip::CallTipStart(int pos, Point pt, int textHeight, const char *
 void CallTip::CallTipCancel() {
  inCallTipMode = false;
  if (wCallTip.Created()) {
- wCallTip.Destroy();
+/* C::B begin */
+// wCallTip.Destroy();
+ wCallTip.Show(false);
+/* C::B end */
+
  }
 }
 
this fix the crash issue. but not sure it cause other issue, since I'm not quite familiar with the scintilla control, I just follow the way p2rkw did.
Thank you Olly! It's working now!
Win 10, MinGW 122.0, wxWidgets 3.1.7

Offline Alpha

  • Developer
  • Lives here!
  • *****
  • Posts: 1513
Re: The 22 March 2014 build (9744) is out.
« Reply #29 on: April 04, 2014, 12:09:29 am »
For whatever reason, I still have been unable to replicate this crash ( ??? ).

@ollydbg: I will see if I can test your patch for side effects this weekend.