Code::Blocks Forums

User forums => Nightly builds => Topic started by: killerbot on March 28, 2014, 09:39:02 pm

Title: The 22 March 2014 build (9744) is out.
Post by: killerbot on March 28, 2014, 09:39:02 pm
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works (http://forums.codeblocks.org/index.php/topic,3232.0.html).

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc481-TDM.7z

The 22 March 2014 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20140322_rev9744_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 22 March 2014 build (9744) is out.
Post by: dmoore on March 29, 2014, 10:56:35 pm
My nightly Ubuntu PPA building now (will try to keep up with this again)
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Jenna on March 29, 2014, 11:26:54 pm
On my server since some hours:

Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (http://apt.jenslody.de/).
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc19, fc20 and rawhide) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo (http://rpm.jenslody.de) .

No fc18 packages any more (removed from mock due to end of live).
Title: Re: The 22 March 2014 build (9744) is out.
Post by: carra on March 31, 2014, 09:36:07 am
Up and running under Windows. The new CC pop ups with information about identifiers are really useful! Cool work, guys  ;D
Title: Re: The 22 March 2014 build (9744) is out.
Post by: vwdvaan on March 31, 2014, 01:01:06 pm
Crash ;) on Win 7 x32:
Code
codeblocks.exe caused an Access Violation at location 006ccc1f Reading from location 006ccc1f.

Registers:
eax=006ccc1f ebx=0000001c ecx=0747e2d8 edx=00000000 esi=004dd828 edi=00000000
eip=006ccc1f esp=0022f7d8 ebp=0022f9a4 iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010212

Call stack:
006CCC1F
6CD111EE  wxmsw28u_gcc_cb.dll:6CD111EE  _ZN8wxWindow13MSWWindowProcEjjl
6CD0ADAE  wxmsw28u_gcc_cb.dll:6CD0ADAE  _Z9wxWndProcP6HWND__jjl@16
7758C4E7  USER32.dll:7758C4E7  gapfnScSendMessage
7758C5E7  USER32.dll:7758C5E7  gapfnScSendMessage
77584F0E  USER32.dll:77584F0E  GetScrollBarInfo
77584F7D  USER32.dll:77584F7D  GetScrollBarInfo
7773702E  ntdll.dll:7773702E  KiUserCallbackDispatcher
6CCEFA40  wxmsw28u_gcc_cb.dll:6CCEFA40  _ZN11wxEventLoop8DispatchEv

Latest working copy for me was svn9677.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: oBFusCATed on March 31, 2014, 02:07:21 pm
Any steps to reproduce this crash?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: damorin on March 31, 2014, 02:24:38 pm
Hi,

got something similar (see attached report file).

Project Test project' parsing stage done (952 total parsed files, 8954 tokens in 0 minute(s), 0.015 seconds).
ClassBrowser::OnThreadEvent(): Updating class browser...
ClassBrowser::OnThreadEvent(): Class browser updated.
Re-parsed 1 files.
Can't find compiler executable in your configured search path's (for MingW32)...
Can't find compiler executable in your configured search path's (for MingW32)...
Segmentation fault
/cygdrive/c/...iles/codeblocks $
Title: Re: The 22 March 2014 build (9744) is out.
Post by: vwdvaan on April 01, 2014, 09:50:54 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.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ToApolytoXaos on April 01, 2014, 10:06:15 am
On my server since some hours:

Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my debian-repo (http://apt.jenslody.de/).
Fedora packages (binaries and sources) for 32-bit and 64-bit systems (fc19, fc20 and rawhide) and RedHat/CentOS 5 and 6 packages (also 32-bit and 64-bit) can be found in my rpm-repo (http://rpm.jenslody.de) .

No fc18 packages any more (removed from mock due to end of live).
jens, after many attempts to compile codeblocks on my debian testing 64-bit, i gave up. the issue was beyond my limited knowledge as of why it would crash and decided to use your nightly builds. I have finally found my piece!

Thank you so much for your amazing work. I wish I knew how you managed to make it work :/
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha on April 01, 2014, 02:58:53 pm
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...
Under Windows 7 x64, this does not crash for me (both self compiled, and prebuilt nightly).  Is there anything non-standard about the configuration of your machine?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: vwdvaan on April 01, 2014, 03:50:09 pm
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...
Under Windows 7 x64, this does not crash for me (both self compiled, and prebuilt nightly).  Is there anything non-standard about the configuration of your machine?
Hi Alpha!

I don't know what is a non-standard configuration.

I have svn 9677 compiled by me and it's working very well.
Both svn 9677 and svn 9744 have the same settings and the same plugins.

Do you know how to catch a more complex debug message from CodeBlocks?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg on April 01, 2014, 04:29:44 pm
Do you know how to catch a more complex debug message from CodeBlocks?
Can you start the C::B from debugger(I mean debug C::B under C::B), and if it crashed, you can see a full call stack about every thread.
From what I see in your call-stack
Quote
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
....
I can not guess any thing related to CC.  :)

I think it is better you can share us a test project, so we can test it on our system.

BTW: you say "Notepad" means Editor window of C::B?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: vwdvaan on April 01, 2014, 06:59:40 pm
Do you know how to catch a more complex debug message from CodeBlocks?
Can you start the C::B from debugger(I mean debug C::B under C::B), and if it crashed, you can see a full call stack about every thread.
From what I see in your call-stack
Quote
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
....
I can not guess any thing related to CC.  :)

I think it is better you can share us a test project, so we can test it on our system.

BTW: you say "Notepad" means Editor window of C::B?

:)
Recompiled with -g -O0 for cb_release_type and no break or detailed threads in Call stack.

Running standalone and intercepted with Dr. MinGW:
Code
codeblocks.exe caused an Access Violation at location 4cb22a68 Reading from location 4cb22a68.

Registers:
eax=4cb22a68 ebx=00000ad4 ecx=11a5ba18 edx=00000000 esi=11a5ba18 edi=00000ad4
eip=4cb22a68 esp=0022f518 ebp=0022f994 iopl=0         nv up ei pl nz ac po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00210216

Call stack:
4CB22A68
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
00405B8E  codeblocks.exe:00405B8E  CodeBlocksApp::OnRun  app.cpp:818

...
    try
    {
>         int retval = wxApp::OnRun();
        // wx 2.6.3 docs says that OnRun() function's return value is used as exit code
        return m_Batch ? m_BatchExitCode : retval;
...

684A9954  wxmsw28u.dll:684A9954  _Z14wxUninitializev
684F1D1C  wxmsw28u.dll:684F1D1C  _Z7wxEntryP11HINSTANCE__S0_Pci
00401DD6  codeblocks.exe:00401DD6  WinMain@16  app.cpp:278

...
} // namespace

> IMPLEMENT_APP(CodeBlocksApp) // TODO: This gives a "redundant declaration" warning, though I think it's false. Dig through macro and check.

BEGIN_EVENT_TABLE(CodeBlocksApp, wxApp)
...

0050074B  codeblocks.exe:0050074B  _ZNK8cbPlugin9CanDetachEv
004010FD  codeblocks.exe:004010FD
77BA37EB  ntdll.dll:77BA37EB  RtlInitializeExceptionChain
77BA37BE  ntdll.dll:77BA37BE  RtlInitializeExceptionChain

Title: Re: The 22 March 2014 build (9744) is out.
Post by: White-Tiger on April 01, 2014, 07:17:07 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

But yeah... debugging CB on Windows is a pain... best is indeed to debug it with CB itself... or to attach gdb manually...
but even a backtrace on all threads (t a a bt full) using gdb after a crash or while a freeze gives almost no information... my CB is currently >1GiB in size because I've increased debugging output to maximum..
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Miguel Gimenez on April 01, 2014, 08:17:50 pm
I've the same problem than Vali29. I'm using SVN9744 (self compiled) over Windows XP SP3, and if you remove focus from Codeblocks when CC is showing the tip you always get a segmentation fault.

Debuging within Codeblocks or within gdb alone shows the same results: the backtrace is truncated to two (sometimes three) lines. Using gdb:

Code
Program received signal SIGSEGV, Segmentation fault.
0x00002265 in ?? ()
(gdb) bt
#0  0x00002265 in ?? ()
#1  0x627a190d in ?? ()
#2  0x003f0450 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Compiled with gcc 4.7.0 (MinGW) and wxWidgets 2.8.12

HTH

Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha 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.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: White-Tiger 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.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: vwdvaan 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]
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: oBFusCATed 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?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: vwdvaan on April 02, 2014, 07:06:54 pm
I've recorded a short video with this crash.

https://app.box.com/s/obf7xjt9qvr78mvd43e9
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Miguel Gimenez 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.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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  :)
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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.

(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2014-04-03142214_zps4ea5ac15.png)

This happens after the application lose focus(after this event handler call).
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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. :)
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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 (http://forums.codeblocks.org/index.php/topic,17316.0.html)
And I think p2rkw (http://forums.codeblocks.org/index.php?action=profile;u=32558) has a fix to the CC's auto suggestion list. Maybe we should have a similar fix for the tooltip window.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: vwdvaan 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!
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha 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.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: MortenMacFly 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)?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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.

Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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.

Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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();
Title: Re: The 22 March 2014 build (9744) is out.
Post by: White-Tiger 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
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha 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);
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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.  ;)
Title: Re: The 22 March 2014 build (9744) is out.
Post by: tuldok89 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.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: cacb 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?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: stahta01 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/ (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.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ollydbg 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).
Title: Re: The 22 March 2014 build (9744) is out.
Post by: carra 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.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: carra 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"
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha 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();
Title: Re: The 22 March 2014 build (9744) is out.
Post by: scarphin 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
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha on April 26, 2014, 05:12:12 am
Code completion always kicks in after the 3rd character regardless of the setting [...]
My apologies, the migration to CCManager of the settings was incomplete (marked with several TODOs in sdk/ccmanager.cpp), but I just have not gotten around to (and sort of forgot about :-[) building a settings dialogue for CCManager, so this (and several other items) are currently hardcoded.
This is on my todo list, but patches adding the UI would be greatly appreciated, as I am currently extremely limited on time.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: scarphin on April 26, 2014, 06:22:26 am
No apology needed, it's good to know it's not by my side. ;)

Out of curiosity, is that the new interface for Clang completion?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: oBFusCATed on April 26, 2014, 09:41:05 am
Not only clang, but python or anything someone would like to make a plugin for.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: scarphin on April 26, 2014, 02:40:27 pm
Good to know. Is it possible to provide a binary for Clang plugin somehow for volunteers like me to beta test? I couldn't manage to compile the plugin myself as I'm not using TDM compiler and being a 'using xxx::xxx;' guy current implementation doesn't really help me much with that.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: vwdvaan on April 27, 2014, 09:58:30 am
Good to know. Is it possible to provide a binary for Clang plugin somehow for volunteers like me to beta test? I couldn't manage to compile the plugin myself as I'm not using TDM compiler and being a 'using xxx::xxx;' guy current implementation doesn't really help me much with that.

I have successfully compiled the ClangLib plugin but always crash at clang_getInclusions when they start to parse the project.

Code
codeblocks.exe caused an Access Violation at location 66261318 in module libclang.dll Reading from location 00000010.

Registers:
eax=00000000 ebx=01d9f078 ecx=01d52158 edx=00000512 esi=00000010 edi=00000000
eip=66261318 esp=0022f528 ebp=0022f870 iopl=0         nv up ei pl zr na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246

Call stack:
66261318  libclang.dll:66261318  clang_getInclusions
68481249  wxmsw28u.dll:68481249  _ZNK12wxAppConsole11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_
684ED9EC  wxmsw28u.dll:684ED9EC  _ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
684EDDC6  wxmsw28u.dll:684EDDC6  _ZN12wxEvtHandler23SearchDynamicEventTableER7wxEvent
684EDE44  wxmsw28u.dll:684EDE44  _ZN12wxEvtHandler12ProcessEventER7wxEvent
685C4ED9  wxmsw28u.dll:685C4ED9  _ZN11wxTimerBase6NotifyEv
68520858  wxmsw28u.dll:68520858  _ZN7wxTimer4InitEv
7613C4E7  USER32.dll:7613C4E7  gapfnScSendMessage
7613C5E7  USER32.dll:7613C5E7  gapfnScSendMessage
7613CC19  USER32.dll:7613CC19  gapfnScSendMessage
7613CC70  USER32.dll:7613CC70  DispatchMessageW
761341EB  USER32.dll:761341EB  IsDialogMessageW
6851214D  wxmsw28u.dll:6851214D  _ZN11wxEventLoop17PreProcessMessageEP6tagMSG
68511D8A  wxmsw28u.dll:68511D8A  _ZN11wxEventLoop14ProcessMessageEP6tagMSG
68511EEC  wxmsw28u.dll:68511EEC  _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
776237EB  ntdll.dll:776237EB  RtlInitializeExceptionChain
776237BE  ntdll.dll:776237BE  RtlInitializeExceptionChain



Title: Re: The 22 March 2014 build (9744) is out.
Post by: nasty_wolverine on April 30, 2014, 09:49:18 pm
when is the next nightly scheduled???
I tried this and the last nightly, both crash when attempting code completion. So, i went back to using the 13.12 release. I hear the crashes have been fixed in trunk, so patiently waiting for the next nightly.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ToApolytoXaos on April 30, 2014, 10:44:35 pm
@jens: the latest nightly build from your repository on my Debian jessie 64-bit crashed a few seconds after i closed it and upon reopen the crash got reproduced.

Code
user@debian:~$ gdb codeblocks
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
(gdb) bt
#0  0x00007ffff27589f8 in main_arena () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff61fea44 in wxAppBase::SendIdleEvents(wxWindow*, wxIdleEvent&) ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#2  0x00007ffff61fee74 in wxAppBase::ProcessIdle() ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#3  0x00007ffff6179e91 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#4  0x00007ffff33e4ce5 in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff33e5048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x00007ffff33e530a in g_main_loop_run ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x00007ffff52f9147 in gtk_main ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#8  0x00007ffff618d36a in wxEventLoop::Run() ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#9  0x00007ffff61fec1c in wxAppBase::MainLoop() ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#10 0x00000000004484fb in CodeBlocksApp::OnRun (this=0x7d3bb0) at app.cpp:818
#11 0x00007ffff589df7d in wxEntry(int&, wchar_t**) ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#12 0x000000000043b962 in main (argc=3, argv=<optimized out>) at app.cpp:278
(gdb) continue
Continuing.

Program received signal SIGABRT, Aborted.
0x00007ffff23ea3a9 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) continue
Continuing.
[Thread 0x7fffd7dc1700 (LWP 12975) exited]
[Thread 0x7fffd85c2700 (LWP 12946) exited]
[Thread 0x7fffe7309700 (LWP 12939) exited]
[Thread 0x7fffe7b0a700 (LWP 12938) exited]
[Thread 0x7fffe830b700 (LWP 12937) exited]

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb) continue
The program is not being run.
(gdb) q
user@debian:~$
Title: Re: The 22 March 2014 build (9744) is out.
Post by: oBFusCATed on April 30, 2014, 11:46:05 pm
try executing: "thread apply all bt" gdb command. The bt from the main trace doesn't look interesting or revealing...
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha on May 01, 2014, 12:14:30 am
Good to know. Is it possible to provide a binary for Clang plugin somehow for volunteers like me to beta test? [...]
I will try to package a nightly build compatible Windows binary soon.

I have successfully compiled the ClangLib plugin but always crash at clang_getInclusions when they start to parse the project.
Odd...  Did you self-compile everything, or is this linking against a nightly?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: vwdvaan on May 01, 2014, 09:37:21 am

I have successfully compiled the ClangLib plugin but always crash at clang_getInclusions when they start to parse the project.
Odd...  Did you self-compile everything, or is this linking against a nightly?
Hi Alpha!

Compiled myself with TDM GCC 4.6.1, CB svn 9760, LLVM + Clang 3.3 and your ClangLib plugin.
On small CB projects, ex. c++ Hello World it's working but on projects with wxWidgets always crash.

Do you have a special build steps to compile LLVM with gcc on Windows?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ToApolytoXaos on May 01, 2014, 03:40:46 pm
try executing: "thread apply all bt" gdb command. The bt from the main trace doesn't look interesting or revealing...

I hope I have done it properly @oBFusCATed. If I missed anything, please let me know.

Code
$ gdb codeblocks 
GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1)
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/bin/codeblocks...Reading symbols from /usr/lib/debug/usr/bin/codeblocks...done.
done.
(gdb) run -d -v
Starting program: /usr/bin/codeblocks -d -v
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe830b700 (LWP 9153)]
[New Thread 0x7fffe7b0a700 (LWP 9154)]
[New Thread 0x7fffe7309700 (LWP 9155)]
[New Thread 0x7fffd85c2700 (LWP 9163)]
[New Thread 0x7fffd7dc1700 (LWP 9167)]
[Thread 0x7fffd7dc1700 (LWP 9167) exited]
[New Thread 0x7fffd7dc1700 (LWP 9192)]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) thread apply all bt

Thread 7 (Thread 0x7fffd7dc1700 (LWP 9192)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff58ee653 in wxConditionInternal::Wait() ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#2  0x00007ffff58ef1a8 in wxSemaphoreInternal::Wait() ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#3  0x00007fffdcfb4a62 in ClassBrowserBuilderThread::Entry (this=0x4474360)
    at classbrowserbuilderthread.cpp:193
#4  0x00007ffff58ef983 in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#5  0x00007ffff3187062 in start_thread (arg=0x7fffd7dc1700)
    at pthread_create.c:312
#6  0x00007ffff249aa3d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 5 (Thread 0x7fffd85c2700 (LWP 9163)):
#0  0x00007ffff2493c33 in select () at ../sysdeps/unix/syscall-template.S:81
#1  0x00007fffe66924a3 in do_select (this=0x7fffd85c0b20)
    at directorymonitor.cpp:70
#2  DirMonitorThread::Entry (this=0x1a734f0) at directorymonitor.cpp:164
#3  0x00007ffff58ef983 in wxThreadInternal::PthreadStart(wxThread*) ()
---Type <return> to continue, or q <return> to quit---
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#4  0x00007ffff3187062 in start_thread (arg=0x7fffd85c2700)
    at pthread_create.c:312
#5  0x00007ffff249aa3d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7fffe7309700 (LWP 9155)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff58ee653 in wxConditionInternal::Wait() ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#2  0x00007ffff58ef1a8 in wxSemaphoreInternal::Wait() ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#3  0x00007ffff779984a in BackgroundThread::Entry (this=0xefc0e8)
    at ./backgroundthread.h:152
#4  0x00007ffff58ef983 in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#5  0x00007ffff3187062 in start_thread (arg=0x7fffe7309700)
    at pthread_create.c:312
#6  0x00007ffff249aa3d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7fffe7b0a700 (LWP 9154)):
---Type <return> to continue, or q <return> to quit---
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff58ee653 in wxConditionInternal::Wait() ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#2  0x00007ffff58ef1a8 in wxSemaphoreInternal::Wait() ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#3  0x00007ffff779984a in BackgroundThread::Entry (this=0xefc0b0)
    at ./backgroundthread.h:152
#4  0x00007ffff58ef983 in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#5  0x00007ffff3187062 in start_thread (arg=0x7fffe7b0a700)
    at pthread_create.c:312
#6  0x00007ffff249aa3d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111
Thread 2 (Thread 0x7fffe830b700 (LWP 9153)):
#0  pthread_cond_wait@@GLIBC_2.3.2 ()
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff58ee653 in wxConditionInternal::Wait() ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#2  0x00007ffff58ef1a8 in wxSemaphoreInternal::Wait() ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#3  0x00007ffff779984a in BackgroundThread::Entry (this=0xefc078)
---Type <return> to continue, or q <return> to quit---
    at ./backgroundthread.h:152
#4  0x00007ffff58ef983 in wxThreadInternal::PthreadStart(wxThread*) ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#5  0x00007ffff3187062 in start_thread (arg=0x7fffe830b700)
    at pthread_create.c:312
#6  0x00007ffff249aa3d in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7ffff7fb0a00 (LWP 8647)):
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff61fea44 in wxAppBase::SendIdleEvents(wxWindow*, wxIdleEvent&) ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#2  0x00007ffff61fee74 in wxAppBase::ProcessIdle() ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#3  0x00007ffff6179e91 in ?? ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#4  0x00007ffff33e4ce5 in g_main_context_dispatch ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff33e5048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x00007ffff33e530a in g_main_loop_run ()
   from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x00007ffff52f9147 in gtk_main ()
   from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
---Type <return> to continue, or q <return> to quit---
#8  0x00007ffff618d36a in wxEventLoop::Run() ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#9  0x00007ffff61fec1c in wxAppBase::MainLoop() ()
   from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#10 0x00000000004484fb in CodeBlocksApp::OnRun (this=0x7d3bb0) at app.cpp:818
#11 0x00007ffff589df7d in wxEntry(int&, wchar_t**) ()
   from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#12 0x000000000043b962 in main (argc=3, argv=<optimized out>) at app.cpp:278

(gdb) continue
Continuing.

Program received signal SIGABRT, Aborted.
0x00007ffff23ea3a9 in __GI_raise (sig=sig@entry=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory

(gdb) continue
Continuing.
[Thread 0x7fffe7b0a700 (LWP 9154) exited]
[Thread 0x7fffe7309700 (LWP 9155) exited]
[Thread 0x7fffd7dc1700 (LWP 9192) exited]
[Thread 0x7fffe830b700 (LWP 9153) exited]
[Thread 0x7ffff7fb0a00 (LWP 8647) exited]

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Jenna on May 01, 2014, 04:39:05 pm
try executing: "thread apply all bt" gdb command. The bt from the main trace doesn't look interesting or revealing...

I hope I have done it properly @oBFusCATed. If I missed anything, please let me know.

Can you try it with filemanager-plugin disabled, or if this does not work (disabling it might not be saved if C::B crashes) with renaming /usr/lib{64}/codeblocks/plugins/libFileManager.so to anyting without .so-ending ?
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ToApolytoXaos on May 02, 2014, 02:46:15 pm
Can you try it with filemanager-plugin disabled, or if this does not work (disabling it might not be saved if C::B crashes) with renaming /usr/lib{64}/codeblocks/plugins/libFileManager.so to anyting without .so-ending ?
Now that's interesting. I did what you said @jens (disabling the plugin that is) and opens lightning fast! I will be playing more with Code::Blocks and hopefully I won't be reporting another crashing bug issue.

Cheers mate.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha on May 06, 2014, 06:18:37 am
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).
[...]  I will try to deal with the event handling this weekend.
Okay, I guess I was somewhat later than expected.  Should be fixed in trunk now.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: carra on May 06, 2014, 09:08:23 am
Good to hear alpha! I'll test them extensively when the next nightly is up  :D
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ToApolytoXaos on May 07, 2014, 10:03:06 pm
@jens: Update about the crashing issue; it remains the same, but I think I got an idea of why it would crash (I hope i'm wrong with this):

Code
(gdb) run -d -v
Starting program: /usr/bin/codeblocks -d -v
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe8303700 (LWP 16872)]
[New Thread 0x7fffe7b02700 (LWP 16873)]
[New Thread 0x7fffe7301700 (LWP 16874)]
[New Thread 0x7fffd8533700 (LWP 16907)]

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) thread apply all bt

Thread 5 (Thread 0x7fffd8533700 (LWP 16907)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff58ee653 in wxConditionInternal::Wait() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#2  0x00007ffff58ef1a8 in wxSemaphoreInternal::Wait() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#3  0x00007fffdcfb4a62 in ClassBrowserBuilderThread::Entry (this=0x446d000) at classbrowserbuilderthread.cpp:193
#4  0x00007ffff58ef983 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#5  0x00007ffff3187062 in start_thread (arg=0x7fffd8533700) at pthread_create.c:312
#6  0x00007ffff2492bfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 4 (Thread 0x7fffe7301700 (LWP 16874)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff58ee653 in wxConditionInternal::Wait() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#2  0x00007ffff58ef1a8 in wxSemaphoreInternal::Wait() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#3  0x00007ffff779984a in BackgroundThread::Entry (this=0xefbb48) at ./backgroundthread.h:152
#4  0x00007ffff58ef983 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#5  0x00007ffff3187062 in start_thread (arg=0x7fffe7301700) at pthread_create.c:312
#6  0x00007ffff2492bfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 3 (Thread 0x7fffe7b02700 (LWP 16873)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff58ee653 in wxConditionInternal::Wait() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#2  0x00007ffff58ef1a8 in wxSemaphoreInternal::Wait() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#3  0x00007ffff779984a in BackgroundThread::Entry (this=0xefbb10) at ./backgroundthread.h:152
#4  0x00007ffff58ef983 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#5  0x00007ffff3187062 in start_thread (arg=0x7fffe7b02700) at pthread_create.c:312
#6  0x00007ffff2492bfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 2 (Thread 0x7fffe8303700 (LWP 16872)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x00007ffff58ee653 in wxConditionInternal::Wait() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#2  0x00007ffff58ef1a8 in wxSemaphoreInternal::Wait() () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#3  0x00007ffff779984a in BackgroundThread::Entry (this=0xefbad8) at ./backgroundthread.h:152
#4  0x00007ffff58ef983 in wxThreadInternal::PthreadStart(wxThread*) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#5  0x00007ffff3187062 in start_thread (arg=0x7fffe8303700) at pthread_create.c:312
#6  0x00007ffff2492bfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

Thread 1 (Thread 0x7ffff7fb0a00 (LWP 16370)):
#0  0x0000000000000000 in ?? ()
#1  0x00007ffff61fea44 in wxAppBase::SendIdleEvents(wxWindow*, wxIdleEvent&) () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#2  0x00007ffff61fee74 in wxAppBase::ProcessIdle() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#3  0x00007ffff6179e91 in ?? () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#4  0x00007ffff33e4ce5 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x00007ffff33e5048 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x00007ffff33e530a in g_main_loop_run () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x00007ffff52f9147 in gtk_main () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#8  0x00007ffff618d36a in wxEventLoop::Run() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#9  0x00007ffff61fec1c in wxAppBase::MainLoop() () from /usr/lib/x86_64-linux-gnu/libwx_gtk2u_core-2.8.so.0
#10 0x00000000004484fb in CodeBlocksApp::OnRun (this=0x7d3bb0) at app.cpp:818
#11 0x00007ffff589df7d in wxEntry(int&, wchar_t**) () from /usr/lib/x86_64-linux-gnu/libwx_baseu-2.8.so.0
#12 0x000000000043b962 in main (argc=3, argv=<optimized out>) at app.cpp:278
(gdb) continue
Continuing.

Program received signal SIGABRT, Aborted.
0x00007ffff23e23a9 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56      ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) continue
Continuing.
[Thread 0x7fffd8533700 (LWP 16907) exited]
[Thread 0x7fffe8303700 (LWP 16872) exited]
[Thread 0x7ffff7fb0a00 (LWP 16370) exited]
[Thread 0x7fffe7b02700 (LWP 16873) exited]

Program terminated with signal SIGABRT, Aborted.
The program no longer exists.
(gdb)

While I am in xterm or whatever terminal that might be, and call Code::Blocks via GDB and keep event's attention to terminal, it works fine. If I run Code::Blocks inside GDB and use alt-TAB to switch to Code::Blocks' splash screen, it would work until the final GUI frame drawing on the right sidebar; that is where it breaks for some reason.

Is there a (painfully, thorough) way to debug UI layer on top of layer? I really am curious to see whether this issue is

Cheers
Title: Re: The 22 March 2014 build (9744) is out.
Post by: oBFusCATed on May 07, 2014, 11:35:21 pm
It is a bug in the splash screen... Use -ns and you won't see it.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: BlueHazzard on May 08, 2014, 07:17:41 am
I can confirm that the splashscreen is buggy under linux (mint 15) see some other posts...
Disablin the splashscreen avoids the bug... (but it won't fix it ;-) )
Title: Re: The 22 March 2014 build (9744) is out.
Post by: carra on May 08, 2014, 09:50:55 am
A minor bug I just came across: I was creating some custom variables in a project, and they contain spaces. I was prompted if I wanted to add quotes, so I checked "don't annoy me again" and clicked on "leave unquoted". However, the choice stored by C::B was "quote" and I have had to re-enable the dialog and click on it every time.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: oBFusCATed on May 09, 2014, 01:28:31 am
@carra: Reproduced and fixed. Thank you for reporting.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ToApolytoXaos on May 09, 2014, 03:35:00 pm
PC Specs:
Windows 7 Enterprise 64-bit
TDM's GCC 4.8.1 32-bit
Code::Blocks svn9760


I think I have detected something that might be a bug.

Press Ctrl-J at any empty area of your choice: this works as expected
(http://i58.tinypic.com/28wls6.png)

Press hash key and auto-completion works as expected:
(http://i61.tinypic.com/2z6gvir.png)

Press ESC to close (interrupt) auto-completion suggestions and press again Ctrl-J: voila!
(http://i60.tinypic.com/k9ufyg.png)

Is this behavior normal?

cheers.

P.S.: I have had a similar issue on my Debian PC with include guards adding randomly mixed characters as name before I even type it.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha on May 09, 2014, 03:52:32 pm
[...]
Code::Blocks svn9760
I think I have detected something that might be a bug. [...]
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).
[...]  I will try to deal with the event handling this weekend.
Okay, I guess I was somewhat later than expected.  Should be fixed in trunk now.
Rev. 9761 is the commit that should have addressed this.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: carra on May 09, 2014, 08:06:41 pm
Thanks Obfuscated, that was quick!  :D
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ToApolytoXaos on May 10, 2014, 11:46:59 am
Rev. 9761 is the commit that should have addressed this.
I'm afraid it's not working. I just finished compiling the latest HEAD and the issue remains similarly the same.

First, I pressed Ctrl-J; it worked as expected.

Then by mistake I pressed \ character, then deleted it with backspace. I pressed hash key and then Ctrl-J and got this:

(http://i59.tinypic.com/nyaao4.png)
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha on May 10, 2014, 07:59:04 pm
I'm afraid it's not working. I just finished compiling the latest HEAD and the issue remains similarly the same.
Hmm, are you certain the relevant components were actually (re)compiled and are being used (ran update)?

First, I pressed Ctrl-J; it worked as expected.
Then by mistake I pressed \ character, then deleted it with backspace. I pressed hash key and then Ctrl-J and got this: [...]
This looks even more odd, but I cannot seem to reproduce it (tried both Linux and Windows).  Is your local build completely vanilla?  Edit: never mind... just figured it out...
Title: Re: The 22 March 2014 build (9744) is out.
Post by: Alpha on May 10, 2014, 08:27:01 pm
I'm afraid it's not working. I just finished compiling the latest HEAD and the issue remains similarly the same.
Try it now.
Title: Re: The 22 March 2014 build (9744) is out.
Post by: ToApolytoXaos on May 10, 2014, 08:39:24 pm
It seems OK now on my Debian PC. On Monday when I will go to work, I will test it as well.

Cheers @Alpha.