Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: killerbot on November 22, 2015, 09:15:53 pm

Title: Release 15.12, RC1 has arrived
Post by: killerbot on November 22, 2015, 09:15:53 pm
For the announcement see here:
http://forums.codeblocks.org/index.php/topic,20729.0.html

...this thread is for the feedback. Keep it coming!
Title: Re: Release 15.12, RC1 has arrived
Post by: stahta01 on November 22, 2015, 09:57:56 pm
From here http://sourceforge.net/projects/codeblocks/files/Binaries/15.12-RC1/ (http://sourceforge.net/projects/codeblocks/files/Binaries/15.12-RC1/) Note: It still mentions BerliOS.

Quote
Please do note that the primary download location with the official, up-to-date releases remains at BerliOS here: http://developer.berlios.de/projects/codeblocks The binaries available here have been downloaded from BerliOS and re-uploaded to SF.

Source: readme, updated 2012-02-12
Title: Re: Release 15.12, RC1 has arrived
Post by: stahta01 on November 22, 2015, 10:30:02 pm
The Installer displays 13.12, instead of 15.12, for a short time (on my slow computer it happens for about 1 second).

Tim S.

Title: Re: Release 15.12, RC1 has arrived
Post by: LETARTARE on November 23, 2015, 05:01:47 pm
For me too
Title: Re: Release 15.12, RC1 has arrived
Post by: killerbot on November 24, 2015, 08:52:52 am
I think I know why :

!define CB_SPLASH        ${CB_ADDONS}\setup_splash_15xx.bmp


and setup_splash_15xx.bmp still talks about 13.12 ==> which graphic designer will adapt this ?
Title: Re: Release 15.12, RC1 has arrived
Post by: Krice on November 24, 2015, 02:40:37 pm
I find it weird that plugins menu has plugins listed that are not installed with the IDE. Would be nicer if the menu only has plugins that actually exist.
Title: Re: Release 15.12, RC1 has arrived
Post by: BlueHazzard on November 24, 2015, 03:02:37 pm
I find it weird that plugins menu has plugins listed that are not installed with the IDE. Would be nicer if the menu only has plugins that actually exist.
Can you give some more details? I don't get any plugin listed, that is not installed (or active)

greetings
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on November 25, 2015, 12:06:01 am
I think I know why :

!define CB_SPLASH        ${CB_ADDONS}\setup_splash_15xx.bmp

and setup_splash_15xx.bmp still talks about 13.12 ==> which graphic designer will adapt this ?
Yes, that is a placeholder. That's Why I was asking for a new logo... :-)
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on November 25, 2015, 12:23:22 am
Yes, that is a placeholder. That's Why I was asking for a new logo... :-)
OK - I've taken care about that one now...
Title: Re: Release 15.12, RC1 has arrived
Post by: Krice on November 25, 2015, 12:11:08 pm
Can you give some more details? I don't get any plugin listed, that is not installed (or active)

This is the list in Plugins menu:

Find broken files in project - ok
Reload EditorConfig - ok
BYO Games - ok
Cccc - Failed to launch cccc.
Code profiler - ok (I guess)
Code Statistics - ok
Copy String to clipboard - ok
CppCheck - Failed to launch CppCheck. Please set up the cppcheck executable etc.
Devpak updater/installer - The DevC++ devpak plugin is not configured yet, do you want to.. etc.
Header Fixup - ok
Koders query - ok (at least shows the finder window, didn't try further)
Library finder - ok
Project options manipulator - ok
Regular expressions testbed - ok
Source code formatter (AStyle) - works, but is only messing the formatting (I guess this is its "style")
Symbol table plugin - ok
Windows XP Look'n'feel - nothing happens, do I already have XP look and feel?

Note that I have never selected or managed plugins, these ones are in the Plugin menu by default.
Title: Re: Release 15.12, RC1 has arrived
Post by: BlueHazzard on November 25, 2015, 09:15:29 pm
every single plugin works in your list, you are simply missing the main programs. Codeblocks is not responsible to ship the third party programs, but it supports them with its plugins:

cccc -> http://cccc.sourceforge.net/

CppCheck -> http://cppcheck.sourceforge.net/

Devpak -> Well, you have to configure it...

Source code formatter (AStyle) - works, but is only messing the formatting (I guess this is its "style") -> You can set up your style in the options: Settings->Editor->Source formatter. The standard is Allman formating...

Windows XP Look'n'feel -> You need a gui program. This plugin creates the manifest file that you get a XP Looking gui (this can probably be removed because it isn't necessary in windows > XP, but there are still people out there that use XP)

I have to admit that the plugin installation /handling is not ideal in C::B. I try to improve this at the moment, but it wont get in this release ;)
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on November 25, 2015, 09:47:34 pm
every single plugin works in your list, you are simply missing the main programs. Codeblocks is not responsible to ship the third party programs, but it supports them with its plugins:

cccc -> http://cccc.sourceforge.net/

CppCheck -> http://cppcheck.sourceforge.net/

Devpak -> Well, you have to configure it...

Source code formatter (AStyle) - works, but is only messing the formatting (I guess this is its "style") -> You can set up your style in the options: Settings->Editor->Source formatter. The standard is Allman formating...

Windows XP Look'n'feel -> You need a gui program. This plugin creates the manifest file that you get a XP Looking gui (this can probably be removed because it isn't necessary in windows > XP, but there are still people out there that use XP)

I have to admit that the plugin installation /handling is not ideal in C::B. I try to improve this at the moment, but it wont get in this release ;)
It would be worth to think about shipping a current release of these tools with the release. The two tools are really tiny...
Title: Re: Release 15.12, RC1 has arrived
Post by: mageia on November 26, 2015, 09:23:36 am
pretty good,font look much more better,two years finally have a new stable version out,congratulations
Title: Re: Release 15.12, RC1 has arrived
Post by: Krice on November 26, 2015, 11:35:30 am
CppCheck -> http://cppcheck.sourceforge.net/

I can see there is cppcheck.dll in the plugins directory, but how cppcheck is linked to C::B? I have CppCheck 1.70 installed, but it's 64-bit version so I think C::B doesn't find it. Right?
Title: Re: Release 15.12, RC1 has arrived
Post by: scarphin on November 26, 2015, 12:12:28 pm
You have to insert your cppcheck executable path in the cppcheck settings in codeblocks which I don't remember where now.
Title: Re: Release 15.12, RC1 has arrived
Post by: Krice on November 26, 2015, 02:21:10 pm
Settings - Environment... and it actually works for CppCheck.

Here some more finds:
-Compile doesn't switch to build log, which is annoying.
-How to clear build log?
-Find implementation doesn't work if declaration has typedef for variable type and definition doesn't (for example Uint8 - unsigned char which are the same type).
-gcc is showing compiler warnings for external header files (in this case SDL_stdinc.h of SDL2), I don't know if this is C::B problem or not.
Title: Re: Release 15.12, RC1 has arrived
Post by: BlueHazzard on November 26, 2015, 10:48:58 pm
-How to clear build log?
You can't clear the build log (Why would you clear it?). It gets cleared automatically if you hit the build button. You can hide the build log with the F2 key or set the auto hide setting: Settings->Environment->View->Auto hide/show message pane

-Find implementation doesn't work if declaration has typedef for variable type and definition doesn't (for example Uint8 - unsigned char which are the same type).
can you give a minimal code example?

Settings - Environment... and it actually works for CppCheck.

Here some more finds:
-gcc is showing compiler warnings for external header files (in this case SDL_stdinc.h of SDL2), I don't know if this is C::B problem or not.
Are you using SDL? Have you created your project with the SDL wizard? Can you post a full rebuild log?

thank you for reporting your findings
Title: Re: Release 15.12, RC1 has arrived
Post by: BlueHazzard on November 26, 2015, 10:50:00 pm
It would be worth to think about shipping a current release of these tools with the release. The two tools are really tiny...
And answer all the cppcheck related questions from noobs in this forum  ???
Title: Re: Release 15.12, RC1 has arrived
Post by: Krice on November 27, 2015, 10:40:05 am
You can't clear the build log (Why would you clear it?).

I wanted that stuff to clear when compiling a single file, but now I noticed there is also Build messages.. I think it's kind of confusing to have two logs for the same thing, but I guess there is some kind of logic there.

Quote
can you give a minimal code example?

surface.h:
void Set_Colorkey(Uint8 r, Uint8 g, Uint8 b);

surface.cpp:
void G_Surface::Set_Colorkey(unsigned char r, unsigned char g, unsigned char b)

If you try to find implementation from the header, it doesn't find it because while types are same the definition is not using typedef (which could be fixed, but..)

Quote
Have you created your project with the SDL wizard?

No. I always create an empty project for that. However I found the reason: if you put SDL file locations to Compiler search directory then it's warning about SDL header problems. I fixed that by copying SDL include directory to gcc's include and also SDL library files to gcc library directory and of course removing search directory locations.
Title: Re: Release 15.12, RC1 has arrived
Post by: Miguel Gimenez on November 27, 2015, 11:37:12 am
You can't clear the build log (Why would you clear it?). It gets cleared automatically if you hit the build button. You can hide the build log with the F2 key or set the auto hide setting: Settings->Environment->View->Auto hide/show message pane

I think that the build log (and build messages) should be cleared when closing a workspace. If I change workspaces, the old build log is there.
Title: Re: Release 15.12, RC1 has arrived
Post by: Pecan on November 27, 2015, 05:57:03 pm
Right-click the tab (eg. Build Log) and click "clear contents"

One log is for messages from CodeBlocks while the other log is for message from the compiler.

IMHO, merging the two would be most confusing.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on November 28, 2015, 05:45:47 am
-How to clear build log?
You can clear any log (including the build log) if you right-click on the tab ans select "clear".
Title: Re: Release 15.12, RC1 has arrived
Post by: Krice on November 28, 2015, 10:53:11 am
IMHO, merging the two would be most confusing.

Visual Studio has only one Output window for compiler messages (which also clear when you compile a file or build the project). I think it's less confusing.
Title: Re: Release 15.12, RC1 has arrived
Post by: Morwenn on November 28, 2015, 12:11:48 pm
It would be worth to think about shipping a current release of these tools with the release. The two tools are really tiny...

Yes please :p

While the tools are easy to install, people won't generally bother if they are not installed by default. When I started using Code::Blocks, I think that the time I actually started using CppCheck and CCCC was delayed by a few because I didn't really want to install a few tools I didn't know and whose value I didn't understand at the time. I think that it would make people discover the tools sooner and avoid questions about why they don't work out-of-the-box.

To sum up, while these tools are easy to install, people aren't likely to install them if they don't already know what they do (which they could discover in no time if the binaries shipped with Code::Blocks).
Title: Re: Release 15.12, RC1 has arrived
Post by: scarphin on December 01, 2015, 12:29:16 pm
Shipping 3rd party tools with cb won't be a good idea imo. I can think of at least 2 reasons:
1- I prefer not to add cb binary path to my system path as it's a mess already,
2- Updating the 3rd party tool by hand might generate other problems for the users that has manually installed the tool.
Title: Re: Release 15.12, RC1 has arrived
Post by: White-Tiger on December 01, 2015, 01:39:31 pm
[...]
Windows XP Look'n'feel -> You need a gui program. This plugin creates the manifest file that you get a XP Looking gui (this can probably be removed because it isn't necessary in windows > XP, but there are still people out there that use XP)
[...]
well... it's still necessary even though I've never used the plugin as it is lacking important features and I'm also preferring tabs to spaces to reduce my program's size.
And also quite important: it's useless for x86_64.

A proper (and "minimal") manifest would have to look like this (for XP and >Vista support)
Code: xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<dependency>
<dependentAssembly>
<assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*"/>
</dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/><!--7-->
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/><!--8-->
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/><!--8.1-->
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/><!--10-->
</application>
</compatibility>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>

For comparison, this is the generated XP manifest: (also note that it's using \n as line break which won't work for most Windows users as it'll look like a huge single line in Notepad)
Code: xml
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>"
<assembly
  xmlns="urn:schemas-microsoft-com:asm.v1"
  manifestVersion="1.0">
<assemblyIdentity
    name="PROJECT.TARGET.App"
    processorArchitecture="x86"
    version="1.0.0.0"
    type="win32"/>
<description>Executable</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="x86"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
</assembly>
Title: Re: Release 15.12, RC1 has arrived
Post by: stahta01 on December 04, 2015, 09:17:28 pm
Several months or a year or so ago, Cygwin redid their Compiler exe names.
The gcc-3.exe is no longer in the installation. Using GCC 4.9.? GCC version as of  today.

Tim S.

Code
From 1208d759474681795640e974263b74065241d324 Mon Sep 17 00:00:00 2001
From: Tim S <stahta01@users.sourceforge.net>
Date: Fri, 4 Dec 2015 14:46:56 -0500
Subject: [PATCH 2/2] * cygwin_support: Removed "-3" suffix from exe files.
 (Thanks stahta01)

---
 .../compilergcc/resources/compilers/options_cygwin.xml      | 13 +++++++------
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/src/plugins/compilergcc/resources/compilers/options_cygwin.xml b/src/plugins/compilergcc/resources/compilers/options_cygwin.xml
index fca1b7c..5f46924 100644
--- a/src/plugins/compilergcc/resources/compilers/options_cygwin.xml
+++ b/src/plugins/compilergcc/resources/compilers/options_cygwin.xml
@@ -1,12 +1,13 @@
 <?xml version="1.0"?>
 <!DOCTYPE CodeBlocks_compiler_options>
 <CodeBlocks_compiler_options extends="gcc">
-    <!-- NOTE: Cygwin's gcc.exe maybe a file link and
-         is not a good default name for running via cmd.exe
-         TODO: May also be gcc-4.exe!!! -->
-    <Program name="C"         value="gcc-3.exe"/>
-    <Program name="CPP"       value="g++-3.exe"/>
-    <Program name="LD"        value="g++-3.exe"/>
+    <!-- NOTE: In the old Cygwin's gcc.exe maybe a file
+         link and is not a good default name for
+         running via cmd.exe; tested good using gcc.exe
+         and g++.exe under Cygwin 2.873 32 bit -->
+    <Program name="C"         value="gcc.exe"/>
+    <Program name="CPP"       value="g++.exe"/>
+    <Program name="LD"        value="g++.exe"/>
     <Program name="DBGconfig" value="gdb_debugger:Default"/>
     <Program name="LIB"       value="ar.exe"/>
     <Program name="WINDRES"   value="windres.exe"/>
--
2.6.3.windows.1

Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 07, 2015, 08:04:00 pm
The gcc-3.exe is no longer in the installation. Using GCC 4.9.? GCC version as of  today.
I noted that one, too and had to modify my local (run-time) C::B already way back. I would say its more years than month. So its time to make it official. Your patch is in trunk now. Thank you!
Title: Re: Release 15.12, RC1 has arrived
Post by: dcorbit on December 11, 2015, 03:05:53 am
The Watcom compilers are now available in 64 bits (C/C++/Fortran77):
http://sourceforge.net/projects/openwatcom/

When I tried to configure the Watcom Fortran compiler using 15.12 RC1, it reverted to strange settings (gunk from GCC, Watcom C stuff, clearly did not understand what to do).

Feature request (I know, not for this release):
Run a batch file to set the environment for a given compiler.
For instance, for Watcom, it is:
C:\WATCOM\owsetenv.bat
in my case for Watcom.

Also, LLVM gets installed here when I run the Installation for Visual Studio:
C:\Program Files\LLVM

I would like to be able to run it from Code::Blocks also.
Title: Re: Release 15.12, RC1 has arrived
Post by: dcorbit on December 11, 2015, 03:10:06 am
F:\hello>wfl386 hello.f
Open Watcom F77 x86 32-bit Compile and Link Utility
Version 2.0 beta Apr  2 2015 10:17:14 (64-bit)
Copyright (c) 2002-2015 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1990-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
        wfc386 hello.f
Open Watcom FORTRAN 77 x86 32-bit Optimizing Compiler
Version 2.0 beta Apr  2 2015 10:10:56 (64-bit)
Copyright (c) 2002-2015 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1984-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
hello.f: 5 statements, 37 bytes, 2 extensions, 0 warnings, 0 errors
        wlink @__wfl__.lnk
Open Watcom Linker Version 2.0 beta Apr  2 2015 09:56:44 (64-bit)
Copyright (c) 2002-2015 The Open Watcom Contributors. All Rights Reserved.
Portions Copyright (c) 1985-2002 Sybase, Inc. All Rights Reserved.
Source code is available under the Sybase Open Watcom Public License.
See http://www.openwatcom.org/ for details.
loading object files
searching libraries
creating a Windows NT character-mode executable

F:\hello>hello
  Hello, world!

F:\hello>depends hello.exe

F:\hello>type hello.f
      program main

c*********************************************************************72
c
cc MAIN is the main program for HELLO.
c
c  Discussion:
c
c    HELLO is a simple FORTRAN77 program that says "Hello, world!".
c
c  Licensing:
c
c    This code is distributed under the GNU LGPL license.
c
c  Modified:
c
c    18 May 2009
c
c  Author:
c
c    John Burkardt
c
      implicit none

      write ( *, '(a)' ) '  Hello, world!'

      stop
      end

F:\hello>
Title: Re: Release 15.12, RC1 has arrived
Post by: dcorbit on December 11, 2015, 03:13:56 am
My default Watcom 64 bit Fortran compiler location:
c:\Watcom\binnt64\wfl386.exe

My default Watcom 64 bit C/C++ compiler location:
C:\WATCOM\binnt64\wcl386.exe
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 11, 2015, 07:26:31 am
Run a batch file to set the environment for a given compiler.
You know that you can setup environment variables per personality and per project using the envvars plugin? I don't think such feature is needed because you can do so already.
Title: Re: Release 15.12, RC1 has arrived
Post by: darmar on December 12, 2015, 04:12:34 pm
There are problems with parsing Gfortran v5.* compiler messages because in v5.* the format of some messages was a little bit changed. The patch attached solves this problem.

Another older problem is that -fopenmp option should be added to the compiler and to the linker when user selects "Enable the OpenMP extensions" compiler option. The patch solves this problem also.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 13, 2015, 07:07:10 am
There are problems with parsing Gfortran v5.* compiler messages because in v5.* the format of some messages was a little bit changed. The patch attached solves this problem.

Another older problem is that -fopenmp option should be added to the compiler and to the linker when user selects "Enable the OpenMP extensions" compiler option. The patch solves this problem also.
I've applied this on trunk. Before I move it to the release branch: Is it backwards compatible? Meaning what happens to older GFortran compiler messages now?
Title: Re: Release 15.12, RC1 has arrived
Post by: darmar on December 13, 2015, 08:37:17 am
Is it backwards compatible?

Yes, GFortran 4.* messages are recognized as before.

Title: Re: Release 15.12, RC1 has arrived
Post by: killerbot on December 13, 2015, 09:53:15 am
I am planning on preparing an RC2 today or tomorrow, or should we wait a little bit longer ?
Title: Re: Release 15.12, RC1 has arrived
Post by: Krice on December 13, 2015, 02:33:07 pm
I'm wondering why virtual folders can be created only outside sources and headers folders? Wouldn't it be more logical to create them inside the source structure to divide files into thematic groups.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 13, 2015, 07:39:03 pm
I am planning on preparing an RC2 today or tomorrow, or should we wait a little bit longer ?
Nope, feel free to do. I would go gold already, but if you do a RC2 today it should be fine.
Title: Re: Release 15.12, RC1 has arrived
Post by: killerbot on December 14, 2015, 07:21:53 am
gold is also OK, is there any blocking bug ? (I could think of one, the editor tabs splitup up, seems to happen sometimes during project reload ?) ?
Title: Re: Release 15.12, RC1 has arrived
Post by: Pecan on December 14, 2015, 04:46:16 pm
gold is also OK, is there any blocking bug ? (I could think of one, the editor tabs splitup up, seems to happen sometimes during project reload ?) ?

You might want to ignore the editor tabs splitup bug until after 15.12.
Just disable the bug for now with something like this:
Code
--- src/sdk/projectlayoutloader.cpp	(revision 10603)
+++ src/sdk/projectlayoutloader.cpp (working copy)
@@ -236,12 +236,12 @@
 
     if (major >= 1)
     {
-        elem = root->FirstChildElement("EditorTabsLayout");
-        if (elem)
-        {
-            m_NotebookLayout = cbC2U(elem->Attribute("layout"));
-        }
-        // else ?!
+// FIXME (ph#): //(pecan 2015/10/29)causes split window when loading second project //(ICC 2015/10/29)
+//        elem = root->FirstChildElement("EditorTabsLayout");
+//        if (elem)
+//        {
+//            m_NotebookLayout = cbC2U(elem->Attribute("layout"));
+//        }         // else ?!
     }
 
     return true;
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 14, 2015, 08:11:16 pm
Just disable the bug for now with something like this:
I wasn't aware this bug still exists. What else do we loose with this "work-around"? Any meaningful functionality?

And btw: How can I reproduce this split bug?
Title: Re: Release 15.12, RC1 has arrived
Post by: Jenna on December 14, 2015, 10:29:29 pm
I wasn't aware this bug still exists. What else do we loose with this "work-around"? Any meaningful functionality?
The whole layout restoring of single projects is lost.
Title: Re: Release 15.12, RC1 has arrived
Post by: Krice on December 14, 2015, 11:40:45 pm
Another problem with virtual folders is that you can move a file from the list into a virtual folder only if it's visible on screen. If the list of files is too long it doesn't scroll up when you try to move the file.
Title: Re: Release 15.12, RC1 has arrived
Post by: l_inc on December 14, 2015, 11:51:16 pm
I wasn't aware this bug still exists.
Not sure if it's related, but I actually reported (http://forums.codeblocks.org/index.php/topic,20667.msg140762.html#msg140762) that the bugfix had been done improperly.
Title: Re: Release 15.12, RC1 has arrived
Post by: Jenna on December 15, 2015, 12:15:48 am
I wasn't aware this bug still exists.
Not sure if it's related, but I actually reported (http://forums.codeblocks.org/index.php/topic,20667.msg140762.html#msg140762) that the bugfix had been done improperly.
I just answered there, I do not see where we read values from unallocated memory.
Title: Re: Release 15.12, RC1 has arrived
Post by: l_inc on December 15, 2015, 12:28:11 am
jens
I never said, you read values from unallocated memory. I said, such reading could become a possible manifestation of the unfixed bug. And in this case you'd have a crash, not tab splitting.
Title: Re: Release 15.12, RC1 has arrived
Post by: Jenna on December 15, 2015, 12:45:43 am
I answered in the other thread and suggest to do it there, to not clutter this one more.
http://forums.codeblocks.org/index.php/topic,20667.msg141682.html#msg141682
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 15, 2015, 03:27:05 pm
I wasn't aware this bug still exists. What else do we loose with this "work-around"? Any meaningful functionality?
The whole layout restoring of single projects is lost.
Is there any command or option that I can unsplitte all the editors?
sometimes, I see unwanted splitted editors when I open a second project. I need a way to unsplitte all editors. Thanks.
Title: Re: Release 15.12, RC1 has arrived
Post by: Jenna on December 15, 2015, 03:57:03 pm
Is there any command or option that I can unsplitte all the editors?
Unfortunately not.
If it would be so easy, it would not happen.
I'm aware of this issue, and look for a solution, but at the moment, I think the saving and restoring of tiled editors is more important,then the issue (in my opinion).
It works good for workspaces, to save the whole layout of many projects and it works much better for projects, that already have tiled editors, than for flat projects.

As you might have seen, I prefer not to talk about splitted editors, because that's not correct.
This might sound nitpicking, but a splitted editor has absolutely nothing to do with the tiled layout (whether it is broken or not). And restoring splitted editors should work correct.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on December 16, 2015, 03:16:50 am
Is there any command or option that I can unsplitte all the editors?
Unfortunately not.
If it would be so easy, it would not happen.
I'm aware of this issue, and look for a solution, but at the moment, I think the saving and restoring of tiled editors is more important,then the issue (in my opinion).
It works good for workspaces, to save the whole layout of many projects and it works much better for projects, that already have tiled editors, than for flat projects.

As you might have seen, I prefer not to talk about splitted editors, because that's not correct.
This might sound nitpicking, but a splitted editor has absolutely nothing to do with the tiled layout (whether it is broken or not). And restoring splitted editors should work correct.
Hi, Jens. Yes, you are right, I mainly mean the tiled window. For a small screen, a tiled window is half the size of the flat window(the client area of the cb frame), It is annoying(Just see pecan's screenshot). Because in this case, I need to manully close all the tiled editor.
Title: Re: Release 15.12, RC1 has arrived
Post by: Krice on December 25, 2015, 11:51:47 am
I think you should just 1:1 copy project management tab from Visual Studio. And I still think it would be a nice option to somehow change visual properties of filenames in the list (text color for example). I'm going to keep suggesting this until I get what I want.
Title: Re: Release 15.12, RC1 has arrived
Post by: killerbot on December 25, 2015, 12:15:44 pm
You can't clear the build log (Why would you clear it?). It gets cleared automatically if you hit the build button. You can hide the build log with the F2 key or set the auto hide setting: Settings->Environment->View->Auto hide/show message pane

I think that the build log (and build messages) should be cleared when closing a workspace. If I change workspaces, the old build log is there.

good idea
Title: Re: Release 15.12, RC1 has arrived
Post by: killerbot on December 25, 2015, 12:22:26 pm
It works good for workspaces

No it does not, adjust a project file outside CB (eg due to svn up ), CB asks to reload it (click yes) and this bug occurs. It is really annoying and bad user experience.
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on December 26, 2015, 02:48:33 am
So... my first post here... Hi :D
Here are few bugs that I found and ideas that I'd really like to see in Code::Blocks

1.When you open one (or more) files, there's a chance that C::B will hang after opening it. You will have to just kill the process, and start again... It took me 5 times to load all files I needed this time (it's not yet a project. I'm just testing something). And it's not just a recent bug, because it also occurs in 13.12.

2. It would be nice if C::B would create new empty file when you double-clicked on the tab bar with file names. (or maybe it already was implemented and it's somewhere in menu and I didn't find it?)

3. Could you please move the closing "x" button in Logs & others down to the tab bar, and maybe reserve some space at it's beginning for the title? It would add 1.6 - 2.3 lines of space to the editor.

4. Exporting Syntax highlighting settings into one file would be helpful, because everytime I format my disks (which is suprisingly often) I have to set Keywords and Filemasks again which is annoying.

5. C++ Parser hangs or just doing his job way too long, because sometimes it displays that popup (floating box? text? w/e) that it's still parsing files for more than an hour... in a project that includes 4 standard libraries and 5 small files.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 27, 2015, 07:06:48 pm
I think you should just 1:1 copy project management tab from Visual Studio.
Why and which version do you like us to copy?
I've not used any version newer that 2008, but I've seen there are differences.
Also keep in mind that adding this should happens naturally, by this I mean a developer should decide that this is useful and should do the work.
Until then your posts will be ignored.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 27, 2015, 07:12:11 pm
1.When you open one (or more) files, there's a chance that C::B will hang after opening it. You will have to just kill the process, and start again... It took me 5 times to load all files I needed this time (it's not yet a project. I'm just testing something). And it's not just a recent bug, because it also occurs in 13.12.
Can you share a file that will cause cb to crash?

2. It would be nice if C::B would create new empty file when you double-clicked on the tab bar with file names. (or maybe it already was implemented and it's somewhere in menu and I didn't find it?)
ctrl-shift-n or file -> new -> empty file

3. Could you please move the closing "x" button in Logs & others down to the tab bar, and maybe reserve some space at it's beginning for the title? It would add 1.6 - 2.3 lines of space to the editor.
Not possible, we're using the wxAui component and it doesn't have this feature.

4. Exporting Syntax highlighting settings into one file would be helpful, because everytime I format my disks (which is suprisingly often) I have to set Keywords and Filemasks again which is annoying.
You can copy the whole default.conf file or use the cb_share_config to copy parts of it, already. The default.conf is somewhere in %APP_DATA%/codeblocks (not a windows user, thus I might be wrong).

5. C++ Parser hangs or just doing his job way too long, because sometimes it displays that popup (floating box? text? w/e) that it's still parsing files for more than an hour... in a project that includes 4 standard libraries and 5 small files.
Share a project which can be used to reproduce the problem, please.
Title: Re: Release 15.12, RC1 has arrived
Post by: stahta01 on December 28, 2015, 11:58:33 am
Two of my past patches that would be good to get in RC2.

The setting of CMD_NULL to be just NUL is the most important one.

Code
From de1dfa465c5e8f059cf5e9acc02899f0d1249925 Mon Sep 17 00:00:00 2001
From: Tim S <stahta01@users.sourceforge.net>
Date: Sun, 8 Nov 2015 08:26:17 -0500
Subject: [PATCH 1/2] * sdk: Fixed value of "CMD_NULL" to be just "NUL".
 (Thanks stahta01)

---
 src/sdk/macrosmanager.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/sdk/macrosmanager.cpp b/src/sdk/macrosmanager.cpp
index 52c7888..1260a7d 100644
--- a/src/sdk/macrosmanager.cpp
+++ b/src/sdk/macrosmanager.cpp
@@ -130,11 +130,12 @@ void MacrosManager::ClearProjectKeys()
 
     if (platform::windows)
     {
+        m_Macros[_T("CMD_NULL")]  = _T("NUL");
+
         const wxString cmd(_T("cmd /c "));
         m_Macros[_T("CMD_CP")]    = cmd + _T("copy");
         m_Macros[_T("CMD_RM")]    = cmd + _T("del");
         m_Macros[_T("CMD_MV")]    = cmd + _T("move");
-        m_Macros[_T("CMD_NULL")]  = cmd + _T("NUL");
         m_Macros[_T("CMD_MKDIR")] = cmd + _T("md");
         m_Macros[_T("CMD_RMDIR")] = cmd + _T("rd");
     }
--
2.6.4.windows.1

Title: Re: Release 15.12, RC1 has arrived
Post by: CJS on December 28, 2015, 12:49:45 pm
4. Exporting Syntax highlighting settings into one file would be helpful...
You can copy the whole default.conf file or use the cb_share_config to copy parts of it, already. The default.conf is somewhere in %APP_DATA%/codeblocks (not a windows user, thus I might be wrong).

Typing %APPDATA% in the Win7 Start / Search box (no underscore) takes me to a directory "Roaming"
Under this is a directory \CodeBlocks where default.conf is found, containing xml format data.

On my system this also appears under C:\Users\%USERNAME%\AppData\Roaming\CodeBlocks
(Currently using nightly svn 10136)

It can be in different places, see FAQ-Settings (http://wiki.codeblocks.org/index.php/FAQ-Settings)

Open a CMD prompt and type set (or set | more) to get a list of definitions for all the Windows system path variables.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 28, 2015, 02:08:48 pm
stahta01: Do you have tickets for these two patches? If not please open two separate ones and describe the problems they fix (a link to forum discussion is fine), so we can decide if these can go or not.

Generally, it is too late for them to go in.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on December 30, 2015, 07:55:26 am
Generally, it is too late for them to go in.
I think the first one (NUL patch) is correct. If you want to pipe some output to NUL on Windows, the command is really wrong w/o the patch. It adds cmd /c in front, so for example:
$CMD_CP a b > $CMD_NUL
...becomes:
cmd.exe /c copy a b > cmd.exe /c NUL
...but really should be:
cmd.exe /c copy a b > NUL
The Linux part does it correct as expected. So this one I think we really should let go into.
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on December 31, 2015, 01:39:00 pm
1.When you open one (or more) files, there's a chance that C::B will hang after opening it. You will have to just kill the process, and start again... It took me 5 times to load all files I needed this time (it's not yet a project. I'm just testing something). And it's not just a recent bug, because it also occurs in 13.12.
Can you share a file that will cause cb to crash?

Started C::B and then File -> Recent Files -> typedefs.h and then doing File -> Recent Files -> reference.hpp freezed the program (opening through File -> Open... seems to freeze program less frequently).

2. It would be nice if C::B would create new empty file when you double-clicked on the tab bar with file names. (or maybe it already was implemented and it's somewhere in menu and I didn't find it?)
ctrl-shift-n or file -> new -> empty file

I am aware of that (I even changed ctrl+shift+n to ctrl+n) but still it doesn't change the fact that it would be nice :)
And sometimes it's just faster :)

5. C++ Parser hangs or just doing his job way too long, because sometimes it displays that popup (floating box? text? w/e) that it's still parsing files for more than an hour... in a project that includes 4 standard libraries and 5 small files.
Share a project which can be used to reproduce the problem, please.

It's a randomly occuring thing, and I will post you everything as soon as it happens again.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 31, 2015, 01:42:50 pm
I am aware of that (I even changed ctrl+shift+n to ctrl+n) but still it doesn't change the fact that it would be nice :)
And sometimes it's just faster :)
Double clicking on the tab bar switches to the minimal perspective, so this is already used for something else.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on December 31, 2015, 01:48:09 pm
Started C::B and then File -> Recent Files -> typedefs.h and then doing File -> Recent Files -> reference.hpp freezed the program (opening through File -> Open... seems to freeze program less frequently).
Didn't cause a crash here - rev10637, wx30, gentoo linux.
Does it crash every time or it is some random event?

Does it crash if you disable the code completion plugin?
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on December 31, 2015, 02:09:19 pm
Started C::B and then File -> Recent Files -> typedefs.h and then doing File -> Recent Files -> reference.hpp freezed the program (opening through File -> Open... seems to freeze program less frequently).
Didn't cause a crash here - rev10637, wx30, gentoo linux.
Does it crash every time or it is some random event?

Does it crash if you disable the code completion plugin?

Sadly it's a random event, but the chance it will occur is high enough to annoy me.

I'll disable code completion plugin and edit this post (except told otherwise) if it worked.

I'm using both
15.12 rev 10596 and
13.12 rev 9501
on 64-bit Windows 7
____________________________

Edit: Hanged on the first try :/

Problem details:
Quote
  Problem Event Name:   AppHangB1
  Application Name:   codeblocks.exe
  Application Version:   13.12.0.0
  Application Timestamp:   00000000
  Hang Signature:   2db8
  Hang Type:   0
  Additional Hang Signature 1:   2db8e61ac06ad6d7fa4d8409c314654f
  Additional Hang Signature 2:   2372
  Additional Hang Signature 3:   2372cbe6818f95cdc639c00feddd87e6
  Additional Hang Signature 4:   2db8
  Additional Hang Signature 5:   2db8e61ac06ad6d7fa4d8409c314654f
  Additional Hang Signature 6:   2372
  Additional Hang Signature 7:   2372cbe6818f95cdc639c00feddd87e6

Maybe it will help (it's 15.12, but I also have 13.12 installed, and I guess that old version number is in the registry or something).
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on January 01, 2016, 02:40:49 pm
Do you see a crash handler dialog which allows you to save some info about the crash?
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on January 01, 2016, 06:49:11 pm
If by crash handler dialog you mean this dialog on the screenshot (http://sta.sh/012vzo050vqs), then yes. Otherwise no. If yes - you have it's content in my previous post (it's the same every time).

It might be helpful - it seems that C::B is stuck somewhere waiting for something because windows won't realize that it stopped responding until I demand it to do something (for example switch focus to C::B window, or just click somewhere inside the window). It then goes white and... does nothing. The dialog from the screen shows once I press close button and wait for a while.
Yes I've tried waiting for an hour letting C::B do it's stuff, but the cpu usage was at 0%, and ram amount didn't change so I decided to terminate the process.

Btw, if you want me to collect some more data about this bug, tell me what to do because I have no idea on how to provide more info.
Oh, and on the screen C::B hang after opening typedefs.h (I opened my indexer.hpp file, then closed it, opened typedefs.h and program freezed).

And sorry for giving you a link to the screenshot, but it was too big (196kB) to send it as attachment.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on January 01, 2016, 07:02:32 pm
If by crash handler dialog you mean this dialog on the screenshot (http://sta.sh/012vzo050vqs), then yes. Otherwise no. If yes - you have it's content in my previous post (it's the same every time).
This is not the crash handler dialog I have in mind. :(

Can someone else (running windows) try to reproduce the problem?
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 01, 2016, 08:01:51 pm
Can someone else (running windows) try to reproduce the problem?
I tried hard but no issues here. Can you please try the following:
- download 15.xx-RC1
- install it somewhere
- do NOT run
- create an empty file "default.conf" in the installation folder
- run C::B
- configure the master path to you compiler
- close C::B
- open C::B, try to reproduce
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on January 01, 2016, 09:59:44 pm
I've tried downloading 15.xx (both nightly builds and normal RC) using chrome and firefox, but every time my antivirust told me that the temp to which the file was being saved, was infected, thus I cannot download binaries now. So my question is - is there an option to revert c::b to the state it's after installation but before first run? Because I already have 13.12 and 15.12 RC1 installed, so I could just revert my 15.12 to right-after-installation state.

Before you ask - no, I don't have binaries on my hdd. I deleted them right after installation was completed :/

May I ask what creating an empty default.conf would cause? I mean, aren't all settings stored in the appdata?

And I got app's call stack while it's freezed, would that help in any way?

Some "more detailed" (yeah, it's sooooooo detailed :l ) info about the moment when C::B hangs:
It opens and loads the file, then switches focus to the newly created tab... aaaand then it hangs...

So... I'll post after I get binaries or learn how to compile C::B under windows.
Title: Re: Release 15.12, RC1 has arrived
Post by: headkase on January 01, 2016, 10:03:44 pm
So my question is - is there an option to revert c::b to the state it's after installation but before first run? Because I already have 13.12 and 15.12 RC1 installed, so I could just revert my 15.12 to right-after-installation state.

Deleting the %APPDATA%\Roaming\CodeBlocks folder should be enough to restore it to a default state.

So... I'll post after I get binaries or learn how to compile C::B under windows.

Installing from source isn't terribly difficult: http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows

And if you don't want to go full-source you can always go nightly: http://wiki.codeblocks.org/index.php/Installing_Code::Blocks_nightly_build_on_Windows
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on January 01, 2016, 10:30:46 pm
And I got app's call stack while it's freezed, would that help in any way?
It might help if there are function names in it. Post it and we will tell you.

default.conf and any other conf file is stored somewhere (CodeBlocks folder) in %AppData%.
Delete this folder and you'll be in a state just-like-after-installation.
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on January 02, 2016, 05:32:10 am
Here's the call stack:

Code
ntoskrnl.exe!memset+0x64a
ntoskrnl.exe!KeWaitForMultipleObjects+0xd52
ntoskrnl.exe!KeWaitForMutexObject+0x19f
ntoskrnl.exe!PoStartNextPowerIrp+0xbb4
ntoskrnl.exe!PoStartNextPowerIrp+0x185d
ntoskrnl.exe!KeWaitForMultipleObjects+0xf5d
ntoskrnl.exe!KeDelayExecutionThread+0x186
ntoskrnl.exe!NtWaitForSingleObject+0x16e
ntoskrnl.exe!KeSynchronizeExecution+0x3a23
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x6c0
wow64cpu.dll!TurboDispatchJumpAddressEnd+0x56b
wow64.dll!Wow64SystemServiceEx+0x1ce
wow64.dll!Wow64LdrpInitialize+0x42a
ntdll.dll!RtlUniform+0x6e6
ntdll.dll!EtwEventSetInformation+0x1d7bd
ntdll.dll!LdrInitializeThunk+0xe
ntdll.dll!ZwDelayExecution+0x15
KERNELBASE.dll!Sleep+0xf
wxmsw28u_gcc_cb.dll!_Z9wxExecuteRK8wxStringiP9wxProcess+0xdfe
wxmsw28u_gcc_cb.dll!_ZN15wxMessageOutput3SetEPS_+0x407
codecompletion.dll+0x54a64
codecompletion.dll+0x54d8c
codecompletion.dll+0x56cd8
codecompletion.dll+0x57490
codecompletion.dll+0x57c82
codecompletion.dll+0x234d6
wxmsw28u_gcc_cb.dll!_ZNK12wxAppConsole11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_+0x22
wxmsw28u_gcc_cb.dll!_ZN11wxTimerBase6NotifyEv+0x9b
wxmsw28u_gcc_cb.dll!_ZN7wxTimer4InitEv+0xab
USER32.dll!gapfnScSendMessage+0x270
USER32.dll!gapfnScSendMessage+0x922
USER32.dll!LoadStringW+0x11f
USER32.dll!DispatchMessageW+0xf
USER32.dll!IsDialogMessageW+0x11e
wxmsw28u_gcc_cb.dll!_ZN11wxEventLoop17PreProcessMessageEP6tagMSG+0xac
wxmsw28u_gcc_cb.dll!_ZN11wxEventLoop8DispatchEv+0x11d
wxmsw28u_gcc_cb.dll!_ZN5wxApp5YieldEb+0xa9
wxmsw28u_gcc_cb.dll!_Z7wxYieldv+0x1e
wxmsw28u_gcc_cb.dll!_ZN15wxMessageOutput3SetEPS_+0x407
codecompletion.dll+0x553a4
codecompletion.dll+0x5607a
codecompletion.dll+0x5647b
codecompletion.dll+0x56b75
codecompletion.dll+0x56cab
codecompletion.dll+0x57490
codecompletion.dll+0x57c82
codecompletion.dll+0x234d6
wxmsw28u_gcc_cb.dll!_ZNK12wxAppConsole11HandleEventEP12wxEvtHandlerMS0_FvR7wxEventES3_+0x22
wxmsw28u_gcc_cb.dll!_ZN11wxTimerBase6NotifyEv+0x9b
wxmsw28u_gcc_cb.dll!_ZN7wxTimer4InitEv+0xab
USER32.dll!gapfnScSendMessage+0x270
USER32.dll!gapfnScSendMessage+0x922
USER32.dll!LoadStringW+0x11f
USER32.dll!DispatchMessageW+0xf
USER32.dll!IsDialogMessageW+0x11e
wxmsw28u_gcc_cb.dll!_ZN11wxEventLoop17PreProcessMessageEP6tagMSG+0xac
wxmsw28u_gcc_cb.dll!_ZN11wxEventLoop8DispatchEv+0x11d
wxmsw28u_gcc_cb.dll!_ZN17wxEventLoopManual3RunEv+0x128

Tomorrow I will delete the C::B folder in appdata, and see if it will solve the problem
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on January 02, 2016, 12:16:45 pm
It looks like it crashes in the code-completion plugin, but the backtrace is garbled, because the CC plugin is never calling wxMessageOutput as far as I can see.
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on January 03, 2016, 10:22:40 am
So... First i tried to turn off Code Completion and see if the call stack changes... it was exactly the same, so I guess it's corrupted.

After renaming CodeBlocks folder in Roaming and creating blank default.conf in the main dir the problem disappeared, and after reverting to my old settings it was back... so I guess it's caused by my settings... do you want me to upload my zipped %appdata%\CodeBlocks so you could examine it or should I just erase all my settings and start everything anew?

Here's something I think is worth mentioning - when I'm on my settings and open a file the c::b refreshes it's UI many times (and it's so slow that it takes about 0.5-1.2s), but after i load default settings, the process takes less than 0.3s and is barely visible.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 03, 2016, 10:38:54 am
May I ask what creating an empty default.conf would cause? I mean, aren't all settings stored in the appdata?
It makes C::B portable and ensures that:
- its like plain new, after a fresh installation
- no other settings interfere with this version

-> I wanted to have a clean version.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 03, 2016, 10:39:50 am
Deleting the %APPDATA%\Roaming\CodeBlocks folder should be enough to restore it to a default state.
Not necessarily - removing the whole folder would be correct. Or just follow the way I've told you.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 03, 2016, 10:41:33 am
do you want me to upload my zipped %appdata%\CodeBlocks so you could examine it or should I just erase all my settings and start everything anew?
Probably a good thing... please do.
Title: Re: Release 15.12, RC1 has arrived
Post by: Jenna on January 03, 2016, 10:57:36 am
May I ask what creating an empty default.conf would cause? I mean, aren't all settings stored in the appdata?
It makes C::B portable and ensures that:
- its like plain new, after a fresh installation
- no other settings interfere with this version

-> I wanted to have a clean version.
And it keeps the old settings, if you remove the newly created files in the Code::Blocks folder.
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on January 03, 2016, 11:12:13 am
do you want me to upload my zipped %appdata%\CodeBlocks so you could examine it or should I just erase all my settings and start everything anew?
Probably a good thing... please do.

Assuming that you've meant the first option, here's a zip with the needed folder :D
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 03, 2016, 11:28:03 am
Assuming that you've meant the first option, here's a zip with the needed folder :D
Works for me also with that config (having the compiler path adjusted, of course). What I don't have is exactly your compiler and the libs you've setup in the compiler options. So all I can say is that there is no issue with C::B and recent TDM GCC MinGW32/64.
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on January 03, 2016, 11:42:59 am
I think I'll just wait for 15.12 release and delete everything and set it up again (I've been thinking about this lately as I discovered that I have a "little" mess in files). So thanks for the time you spent trying to figure out what the problem is :)
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on January 03, 2016, 11:46:51 am
15.12 (or 16.01) won't help you I think.

Can you run codeblocks inside gdb in a console and when it crashes post the output of the "bt" or "thread apply all bt" commands here?

@devs: Probably would be good idea to have a non-stripped or even debug builds for 15.12, so people code post proper backtraces. What do you think?
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 03, 2016, 11:58:25 am
@devs: Probably would be good idea to have a non-stripped or even debug builds for 15.12, so people code post proper backtraces. What do you think?
I think I had mentioned that already: We can use the stripped version along with the original (unstripped) DLL's if provided by Lieven to get the symbols using the addr2line tool. (This will save us many bandwidth...) To make it easier to use - thats what the Addr2LineUI tool was designed for.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on January 03, 2016, 02:19:42 pm
@devs: Probably would be good idea to have a non-stripped or even debug builds for 15.12, so people code post proper backtraces. What do you think?
I think I had mentioned that already: We can use the stripped version along with the original (unstripped) DLL's if provided by Lieven to get the symbols using the addr2line tool. (This will save us many bandwidth...) To make it easier to use - thats what the Addr2LineUI tool was designed for.
Then, Killerbot still need to supply the "unstripped DLLs" somewhere, so that Addr2Lines tool can get the correct source file and line information.
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on January 04, 2016, 03:25:49 pm
So... after unsuccessfully trying to compile gdb with msys I found a compiled version, run the C::B, successfully crashed it, attached it to gdb and used "thread apply all bt", here's the gdb output:

Code
Attaching to process 5024
[New Thread 5024.0x3bc]
[New Thread 5024.0x1114]
[New Thread 5024.0x1084]
[New Thread 5024.0x1280]
[New Thread 5024.0x11b0]
[New Thread 5024.0x116c]
[New Thread 5024.0x1148]
[New Thread 5024.0x1150]
[New Thread 5024.0x1030]
[New Thread 5024.0xdc8]
[New Thread 5024.0x150c]
[New Thread 5024.0x1510]
[New Thread 5024.0x156c]
[New Thread 5024.0x15a8]
[New Thread 5024.0x15b4]
[New Thread 5024.0x15d0]
[New Thread 5024.0x15dc]
[New Thread 5024.0x1664]
Reading symbols from C:\Programy\CodeBlocks RC\codeblocks.exe...(no debugging symbols found)...done.
0x779e000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
(gdb) thread apply all bt

Thread 18 (Thread 5024.0x1664):
#0  0x779e000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
#1  0x77a6eede in ntdll!DbgUiRemoteBreakin () from C:\Windows\SysWOW64\ntdll.dll
#2  0x7afab70a in ?? ()
#3  0x00000000 in ?? ()

Thread 17 (Thread 5024.0x15dc):
#0  0x7579723b in USER32!GetPropW () from C:\Windows\syswow64\user32.dll
#1  0x7579cd81 in USER32!SendMessageW () from C:\Windows\syswow64\user32.dll
#2  0x6ccdb9b1 in wxExecuteThread(void*)@4 () from C:\Programy\CodeBlocks RC\wxmsw28u_gcc_cb.dll
#3  0x00002b10 in ?? ()
#4  0x00000000 in ?? ()

Thread 16 (Thread 5024.0x15d0):
#0  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x765614b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x0000052c in ?? ()
#4  0x00000000 in ?? ()

Thread 15 (Thread 5024.0x15b4):
#0  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x765614b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x0000051c in ?? ()
#4  0x00000000 in ?? ()

Thread 14 (Thread 5024.0x15a8):
#0  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x765614b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x00000554 in ?? ()
#4  0x00000000 in ?? ()

Thread 13 (Thread 5024.0x156c):
#0  0x779f1f26 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779f1f26 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SysWOW64\ntdll.dll
#2  0x77a15d56 in ntdll!TpSetTimer () from C:\Windows\SysWOW64\ntdll.dll
#3  0x773433aa in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#4  0x77a08fc2 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#5  0x77a08f95 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()

Thread 12 (Thread 5024.0x1510):
---Type <return> to continue, or q <return> to quit---
#0  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x765614b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x0000048c in ?? ()
#4  0x00000000 in ?? ()

Thread 11 (Thread 5024.0x150c):
#0  0x779f013d in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779f013d in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SysWOW64\ntdll.dll
#2  0x76561605 in WaitForMultipleObjectsEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x00000002 in ?? ()
#4  0x0accfd34 in ?? ()
#5  0x77341a3c in WaitForMultipleObjectsEx () from C:\Windows\syswow64\kernel32.dll
#6  0x630e6402 in ?? () from C:\Programy\CodeBlocks RC\share\codeblocks\plugins\FileManager.dll
#7  0x6ccd8aec in wxThreadInternal::DoThreadStart(wxThread*) () from C:\Programy\CodeBlocks RC\wxmsw28u_gcc_cb.dll
#8  0x6ccd8be5 in wxThreadInternal::WinThreadStart(void*)@4 () from C:\Programy\CodeBlocks RC\wxmsw28u_gcc_cb.dll
#9  0x058c1ec0 in ?? ()
#10 0x761a1328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#11 0x773433aa in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#12 0x77a08fc2 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#13 0x77a08f95 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#14 0x00000000 in ?? ()

Thread 10 (Thread 5024.0xdc8):
#0  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x765614b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x00000200 in ?? ()
#4  0x00000000 in ?? ()

Thread 9 (Thread 5024.0x1030):
#0  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x765614b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x00000294 in ?? ()
#4  0x00000000 in ?? ()

Thread 8 (Thread 5024.0x1150):
#0  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x765614b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x000001e0 in ?? ()
#4  0x00000000 in ?? ()

Thread 7 (Thread 5024.0x1148):
---Type <return> to continue, or q <return> to quit---
#0  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x765614b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x000001d8 in ?? ()
#4  0x00000000 in ?? ()

Thread 6 (Thread 5024.0x116c):
#0  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x765614b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x000001d0 in ?? ()
#4  0x00000000 in ?? ()

Thread 5 (Thread 5024.0x11b0):
#0  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779ef8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x765614b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x000001a4 in ?? ()
#4  0x00000001 in ?? ()
#5  0x038bff18 in ?? ()
#6  0x77341194 in WaitForSingleObjectEx () from C:\Windows\syswow64\kernel32.dll
#7  0x75b9cd63 in ole32!CoGetTreatAsClass () from C:\Windows\syswow64\ole32.dll
#8  0x75b9d86a in ole32!CoGetTreatAsClass () from C:\Windows\syswow64\ole32.dll
#9  0x773433aa in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#10 0x77a08fc2 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#11 0x77a08f95 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#12 0x00000000 in ?? ()

Thread 4 (Thread 5024.0x1280):
#0  0x779f1f26 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779f1f26 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SysWOW64\ntdll.dll
#2  0x77a15d56 in ntdll!TpSetTimer () from C:\Windows\SysWOW64\ntdll.dll
#3  0x773433aa in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#4  0x77a08fc2 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#5  0x77a08f95 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()

Thread 3 (Thread 5024.0x1084):
#0  0x779f1f26 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779f1f26 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SysWOW64\ntdll.dll
#2  0x77a15d56 in ntdll!TpSetTimer () from C:\Windows\SysWOW64\ntdll.dll
#3  0x773433aa in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#4  0x77a08fc2 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#5  0x77a08f95 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()
---Type <return> to continue, or q <return> to quit---

Thread 2 (Thread 5024.0x1114):
#0  0x779f013d in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SysWOW64\ntdll.dll
#1  0x779f013d in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SysWOW64\ntdll.dll
#2  0x77a15965 in ntdll!RtlDosPathNameToNtPathName_U () from C:\Windows\SysWOW64\ntdll.dll
#3  0x773433aa in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#4  0x77a08fc2 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#5  0x77a08f95 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()

Thread 1 (Thread 5024.0x3bc):
#0  0x779f2262 in ntdll!RtlLeaveCriticalSection () from C:\Windows\SysWOW64\ntdll.dll
#1  0x6d14023a in pthread_spin_unlock () from C:\Programy\CodeBlocks RC\wxmsw28u_gcc_cb.dll
#2  0x00712da8 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on January 04, 2016, 04:08:37 pm
So... after unsuccessfully trying to compile gdb with msys I found a compiled version, run the C::B, successfully crashed it, attached it to gdb and used "thread apply all bt", here's the gdb output:
Thanks for the report. But there is not much information I see about the crash. Can you build C::B yourself? I think if you can, then the crash bt can have many source line information.

BTW: I reread your old posts, and I still not sure what exact steps you have to reproduce the crash.
Title: Re: Release 15.12, RC1 has arrived
Post by: ollydbg on January 04, 2016, 04:13:53 pm
@Grabusz
I suggest write a bug report here Tickets (https://sourceforge.net/p/codeblocks/tickets/)
so that it won't lost, thanks.
Title: Re: Release 15.12, RC1 has arrived
Post by: oBFusCATed on January 04, 2016, 08:08:56 pm
ollydbg: See this post: http://forums.codeblocks.org/index.php/topic,20730.msg142057.html#msg142057
Title: Re: Release 15.12, RC1 has arrived
Post by: stahta01 on January 06, 2016, 04:16:47 am
I was able to get CB GTK2 Wizard and MSys2 GCC Compiler to work with a very minor patch. CB Thread http://forums.codeblocks.org/index.php/topic,20827.msg142175.html#msg142175 (http://forums.codeblocks.org/index.php/topic,20827.msg142175.html#msg142175)
The import library ends in .dll.a for the GTK2 file.

A user wanted GTK3 to work and I do NOT have the time to add the GUI front end to change between to two.
But, if the CB Devs can make this minor change before the next release it will be easy to write directions; so, an user can edit the current CB Wizard to use GTK3.

Thank you all for your hard work.

Tim S.

Code
From b609f23f9b1f85b7375bac6ab985d35533bd13a0 Mon Sep 17 00:00:00 2001
From: Tim S <stahta01@users.sourceforge.net>
Date: Mon, 4 Jan 2016 19:09:16 -0500
Subject: [PATCH] * scriptedwizard: Added option to look for "libGL.dll.a" if
 all else fails.(Thanks stahta01)

---
 src/plugins/scriptedwizard/resources/common_functions.script | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/plugins/scriptedwizard/resources/common_functions.script b/src/plugins/scriptedwizard/resources/common_functions.script
index f9691a1..15d8537 100644
--- a/src/plugins/scriptedwizard/resources/common_functions.script
+++ b/src/plugins/scriptedwizard/resources/common_functions.script
@@ -551,7 +551,8 @@ function SilentVerifyLibFile(dir, file)
             || IO.FileExists(dir + wxFILE_SEP_PATH + _T("lib") + file + _T(".a"))
             || IO.FileExists(dir + wxFILE_SEP_PATH + _T("lib") + file + _T(".lib"))
             || IO.FileExists(dir + wxFILE_SEP_PATH + _T("lib") + file + _T(".la"))
-            || IO.FileExists(dir + wxFILE_SEP_PATH + _T("lib") + file + _T(".so")) );
+            || IO.FileExists(dir + wxFILE_SEP_PATH + _T("lib") + file + _T(".so"))
+            || IO.FileExists(dir + wxFILE_SEP_PATH + _T("lib") + file + _T(".dll") + _T(".a")) );
 }
 
 // verify the existence of a file of library type (add prefix lib, postfix .a and .lib)
--
2.7.0.windows.1
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 06, 2016, 07:40:11 am
But, if the CB Devs can make this minor change before the next release it will be easy to write directions; so, an user can edit the current CB Wizard to use GTK3.
Done that in SVN (slightly modified).
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on January 06, 2016, 01:45:47 pm
I've been trying to build C::B and today, after I opened the project using File->Recent projects program freezed so I decided to get a backtrace, and it's different this time (and finally with no cc plugin wandering around) so I think it might be helpful.

Second thing (I think I should post it in "Help" but it's somewhat related to the problem so I posted it here. If it's a problem, just tell me and I'll split the post) is that I cannot build my own codeblocks to provide more information. Trying to both compile it with wx 2.8.12 and 3.0.2 and I always get "Undefined reference" errors. With 2.8.12 it seems to be linker error because all names start with "_imp__" while 3.0.2 outputs normal function names so I guess it's the compiler's error.
I built both 3.0.2 and 2.8.12 with the commands provided here (http://wiki.codeblocks.org/index.php?title=Installing_Code::Blocks_from_source_on_Windows#wxWidgets) and manually (no SVN, SF->Download Snapshot) dowloaded the latest (10638 at that time) version, set all the global variables ("wx" and "wx30" to D:\Grabusz\C++\wxMSW-2.8.12 and D:\Grabusz\C++\wxMSW-3.0.2 respectively - these are the folders in which the README_MSW are; "cb_release_type" to -g) and tried to compile using "All".
Looking at few first errors in 3.0.2 log I think the problem lies within wxWidget headers, but posted it here so that more experienced programmers can comment on it.

I've been using MinGW with gcc 4.9.2 to compile it (MinGW w64 with gcc 5.3.0 fails to compile it at the beginning)

Here's the call stack:
Code
Attaching to process 3128
[New Thread 3128.0x8fc]
[New Thread 3128.0x850]
[New Thread 3128.0xbd4]
[New Thread 3128.0xc84]
[New Thread 3128.0x928]
[New Thread 3128.0xc10]
[New Thread 3128.0xcd8]
[New Thread 3128.0x11c8]
[New Thread 3128.0x10a4]
[New Thread 3128.0x10c8]
[New Thread 3128.0x10d4]
[New Thread 3128.0x12d4]
[New Thread 3128.0x11b4]
[New Thread 3128.0x1324]
[New Thread 3128.0x11ec]
[New Thread 3128.0x1134]
Reading symbols from C:\Programy\CodeBlocks RC\codeblocks.exe...(no debugging symbols found)...done.
0x7766000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
(gdb) thread apply all bt

Thread 16 (Thread 3128.0x1134):
#0  0x7766000d in ntdll!DbgBreakPoint () from C:\Windows\SysWOW64\ntdll.dll
#1  0x776eeede in ntdll!DbgUiRemoteBreakin () from C:\Windows\SysWOW64\ntdll.dll
#2  0x7a5d6c2f in ?? ()
#3  0x00000000 in ?? ()

Thread 15 (Thread 3128.0x11ec):
#0  0x77671f26 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SysWOW64\ntdll.dll
#1  0x77671f26 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SysWOW64\ntdll.dll
#2  0x77695d56 in ntdll!TpSetTimer () from C:\Windows\SysWOW64\ntdll.dll
#3  0x764533aa in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#4  0x77688fc2 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#5  0x77688f95 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()

Thread 14 (Thread 3128.0x1324):
#0  0x7526723b in USER32!GetPropW () from C:\Windows\syswow64\user32.dll
#1  0x7526cd81 in USER32!SendMessageW () from C:\Windows\syswow64\user32.dll
#2  0x6ccdb9b1 in wxExecuteThread(void*)@4 () from C:\Programy\CodeBlocks RC\wxmsw28u_gcc_cb.dll
#3  0x00002b10 in ?? ()
#4  0x00000000 in ?? ()

Thread 13 (Thread 3128.0x11b4):
---Type <return> to continue, or q <return> to quit---thread apply all bt
#0  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x760514b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x0000050c in ?? ()
#4  0x00000000 in ?? ()

Thread 12 (Thread 3128.0x12d4):
#0  0x7526723b in USER32!GetPropW () from C:\Windows\syswow64\user32.dll
#1  0x7526cd81 in USER32!SendMessageW () from C:\Windows\syswow64\user32.dll
#2  0x6ccdb9b1 in wxExecuteThread(void*)@4 () from C:\Programy\CodeBlocks RC\wxmsw28u_gcc_cb.dll
#3  0x00002b10 in ?? ()
#4  0x00000000 in ?? ()

Thread 11 (Thread 3128.0x10d4):
#0  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x760514b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x0000052c in ?? ()
#4  0x00000000 in ?? ()

Thread 10 (Thread 3128.0x10c8):
#0  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x760514b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
---Type <return> to continue, or q <return> to quit---
#3  0x00000478 in ?? ()
#4  0x00000000 in ?? ()

Thread 9 (Thread 3128.0x10a4):
#0  0x7767013d in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7767013d in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SysWOW64\ntdll.dll
#2  0x76051605 in WaitForMultipleObjectsEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x00000002 in ?? ()
#4  0x0a94fd34 in ?? ()
#5  0x76451a3c in WaitForMultipleObjectsEx () from C:\Windows\syswow64\kernel32.dll
#6  0x630e6402 in ?? () from C:\Programy\CodeBlocks RC\share\codeblocks\plugins\FileManager.dll
#7  0x6ccd8aec in wxThreadInternal::DoThreadStart(wxThread*) () from C:\Programy\CodeBlocks RC\wxmsw28u_gcc_cb.dll
#8  0x6ccd8be5 in wxThreadInternal::WinThreadStart(void*)@4 () from C:\Programy\CodeBlocks RC\wxmsw28u_gcc_cb.dll
#9  0x05788f38 in ?? ()
#10 0x76e01328 in msvcrt!_endthreadex () from C:\Windows\syswow64\msvcrt.dll
#11 0x764533aa in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#12 0x77688fc2 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#13 0x77688f95 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#14 0x00000000 in ?? ()

Thread 8 (Thread 3128.0x11c8):
#0  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x760514b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
---Type <return> to continue, or q <return> to quit---
#3  0x00000158 in ?? ()
#4  0x00000000 in ?? ()

Thread 7 (Thread 3128.0xcd8):
#0  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x760514b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x00000294 in ?? ()
#4  0x00000000 in ?? ()

Thread 6 (Thread 3128.0xc10):
#0  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x760514b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x000001e0 in ?? ()
#4  0x00000000 in ?? ()

Thread 5 (Thread 3128.0x928):
#0  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x760514b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x000001d4 in ?? ()
#4  0x00000000 in ?? ()

---Type <return> to continue, or q <return> to quit---
Thread 4 (Thread 3128.0xc84):
#0  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7766f8b1 in ntdll!ZwWaitForSingleObject () from C:\Windows\SysWOW64\ntdll.dll
#2  0x760514b9 in WaitForSingleObjectEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x000001cc in ?? ()
#4  0x00000000 in ?? ()

Thread 3 (Thread 3128.0xbd4):
#0  0x77671f26 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SysWOW64\ntdll.dll
#1  0x77671f26 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SysWOW64\ntdll.dll
#2  0x77695d56 in ntdll!TpSetTimer () from C:\Windows\SysWOW64\ntdll.dll
#3  0x764533aa in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#4  0x77688fc2 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#5  0x77688f95 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()

Thread 2 (Thread 3128.0x850):
#0  0x7767013d in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7767013d in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SysWOW64\ntdll.dll
#2  0x77695965 in ntdll!RtlDosPathNameToNtPathName_U () from C:\Windows\SysWOW64\ntdll.dll
#3  0x764533aa in KERNEL32!BaseThreadInitThunk () from C:\Windows\syswow64\kernel32.dll
#4  0x77688fc2 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#5  0x77688f95 in ntdll!RtlInitializeExceptionChain () from C:\Windows\SysWOW64\ntdll.dll
#6  0x00000000 in ?? ()
---Type <return> to continue, or q <return> to quit---

Thread 1 (Thread 3128.0x8fc):
#0  0x7766fd71 in ntdll!ZwDelayExecution () from C:\Windows\SysWOW64\ntdll.dll
#1  0x7766fd71 in ntdll!ZwDelayExecution () from C:\Windows\SysWOW64\ntdll.dll
#2  0x76053bdd in SleepEx () from C:\Windows\syswow64\KernelBase.dll
#3  0x00000000 in ?? ()

Build logs are in the attachment

And two more things:
1. It would be nice if C::B didn't save global variable as invalid, when nothing is entered, but rather passed it as an empty string (I would leave "cb_release_type" empty if I didn't want any custom compiler parameters).
2. Should I compile it with -g or maybe -ggdb? Since I'm going to debug it with GDB, -ggdb sounds beter.

EDIT:

No I didn't compile wxWidget with -g.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 07, 2016, 10:57:54 am
1. It would be nice if C::B didn't save global variable as invalid, when nothing is entered, but rather passed it as an empty string (I would leave "cb_release_type" empty if I didn't want any custom compiler parameters).
That is by design because empty global variables are perfectly valid but we really want to differ here between invalid and empty.

2. Should I compile it with -g or maybe -ggdb? Since I'm going to debug it with GDB, -ggdb sounds beter.
I believe -ggdb ingerits -g but I never used it. -g works fine with gdb, too.
You don't need to compile wx with -g, too.
Title: Re: Release 15.12, RC1 has arrived
Post by: Grabusz on January 11, 2016, 02:55:26 pm
Finally successfuly compiled, run and reproduced the bug using 64-bit C::B 15.12 rev.10640 with wxWidget 3.0.2 compiled respectively with:
Code
-std=c11 -std=gnu++14 -m64 -g -ggdb
Code
CFLAGS ?= -O3 -std=c11 -D_WIN32_IE=0x0603 -Wno-unused-local-typedefs -Wno-deprecated-declarations -m64 -fomit-frame-pointer
CXXFLAGS ?= -O3 -std=gnu++14 -D_WIN32_IE=0x0603 -Wno-unused-local-typedefs -Wno-deprecated-declarations -m64 -fomit-frame-pointer
mingw32-make -j2 -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1  clean
mingw32-make -j2 -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=release UNICODE=1

Backtrace from gdb:
Code
Attaching to process 4240
[New Thread 4240.0x102c]
[New Thread 4240.0x98]
[New Thread 4240.0x11b8]
[New Thread 4240.0xcbc]
[New Thread 4240.0xfa0]
[New Thread 4240.0x13d0]
[New Thread 4240.0x12b8]
[New Thread 4240.0x139c]
[New Thread 4240.0xc58]
[New Thread 4240.0x11b4]
[New Thread 4240.0x1384]
[New Thread 4240.0x1178]
[New Thread 4240.0x1188]
[New Thread 4240.0x123c]
[New Thread 4240.0x6b4]
[New Thread 4240.0x1430]
[New Thread 4240.0x1438]
[New Thread 4240.0x143c]
[New Thread 4240.0x1444]
[New Thread 4240.0x145c]
[New Thread 4240.0x1740]
Reading symbols from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\codeblocks.exe...done.
0x00000000777bb111 in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
(gdb) thread apply all bt

Thread 21 (Thread 4240.0x1740):
#0  0x00000000777bb111 in ntdll!DbgBreakPoint () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x0000000077861e88 in ntdll!DbgUiRemoteBreakin () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#3  0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#4  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 20 (Thread 4240.0x145c):
#0  0x00000000777bbf6a in ntdll!ZwRemoveIoCompletion () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefcef5941 in ?? () from C:\Windows\System32\mswsock.dll
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 19 (Thread 4240.0x1444):
#0  0x00000000777bbf1a in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda010dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2  0x000007feff1664d7 in WININET!InternetCloseHandle () from C:\Windows\system32\wininet.dll
#3  0x000007feff16cbe3 in WININET!InternetOpenUrlA () from C:\Windows\system32\wininet.dll
#4  0x000007feff16caac in WININET!InternetOpenUrlA () from C:\Windows\system32\wininet.dll
#5  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#6  0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#7  0x0000000000000000 in ?? ()
---Type <return> to continue, or q <return> to quit---
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 18 (Thread 4240.0x143c):
#0  0x00000000777bd7da in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000000007778ecfd in ntdll!RtlValidateHeap () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 17 (Thread 4240.0x1438):
#0  0x00000000777bbf1a in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda010dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2  0x000007fef2ca1fae in rasman!RasAddNotification () from C:\Windows\system32\rasman.dll
#3  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#4  0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#5  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 16 (Thread 4240.0x1430):
#0  0x00000000777bd7da in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000000007778ecfd in ntdll!RtlValidateHeap () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 15 (Thread 4240.0x6b4):
---Type <return> to continue, or q <return> to quit---
#0  0x00000000777bbf1a in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda010dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2  0x000000006a2104ca in wxSemaphoreInternal::WaitTimeout(unsigned long) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#3  0x0000000001945ff1 in cbThreadPool::cbWorkerThread::Entry (this=0xe654b10) at D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\sdk\cbthreadpool.cpp:202
#4  0x000000006a20e012 in wxThread::CallEntry() () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#5  0x000000006a21361d in wxThreadInternal::DoThreadStart(wxThread*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#6  0x000000006a213781 in wxThreadInternal::WinThreadStart(void*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#7  0x000007feff71415f in srand () from C:\Windows\system32\msvcrt.dll
#8  0x000007feff716ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll
#9  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#10 0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 14 (Thread 4240.0x123c):
#0  0x00000000777bc48a in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda01420 in KERNELBASE!GetCurrentProcess () from C:\Windows\system32\KernelBase.dll
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 13 (Thread 4240.0x1188):
#0  0x00000000777bbf1a in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda010dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2  0x000000006a2104ca in wxSemaphoreInternal::WaitTimeout(unsigned long) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
---Type <return> to continue, or q <return> to quit---
#3  0x0000000001945ff1 in cbThreadPool::cbWorkerThread::Entry (this=0xe654870) at D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\sdk\cbthreadpool.cpp:202
#4  0x000000006a20e012 in wxThread::CallEntry() () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#5  0x000000006a21361d in wxThreadInternal::DoThreadStart(wxThread*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#6  0x000000006a213781 in wxThreadInternal::WinThreadStart(void*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#7  0x000007feff71415f in srand () from C:\Windows\system32\msvcrt.dll
#8  0x000007feff716ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll
#9  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#10 0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 12 (Thread 4240.0x1178):
#0  0x00000000777bc48a in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda01420 in KERNELBASE!GetCurrentProcess () from C:\Windows\system32\KernelBase.dll
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 11 (Thread 4240.0x1384):
#0  0x00000000777bbf1a in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda010dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2  0x000000006a2104ca in wxSemaphoreInternal::WaitTimeout(unsigned long) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#3  0x0000000001945ff1 in cbThreadPool::cbWorkerThread::Entry (this=0xa51efe0) at D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\sdk\cbthreadpool.cpp:202
#4  0x000000006a20e012 in wxThread::CallEntry() () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#5  0x000000006a21361d in wxThreadInternal::DoThreadStart(wxThread*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
---Type <return> to continue, or q <return> to quit---
#6  0x000000006a213781 in wxThreadInternal::WinThreadStart(void*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#7  0x000007feff71415f in srand () from C:\Windows\system32\msvcrt.dll
#8  0x000007feff716ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll
#9  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#10 0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 10 (Thread 4240.0x11b4):
#0  0x00000000777bbf1a in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda010dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2  0x000000006a2104ca in wxSemaphoreInternal::WaitTimeout(unsigned long) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#3  0x0000000065fd1eba in ClassBrowserBuilderThread::Entry (this=0xa774480) at D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\plugins\codecompletion\classbrowserbuilderthread.cpp:204
#4  0x000000006a20e012 in wxThread::CallEntry() () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#5  0x000000006a21361d in wxThreadInternal::DoThreadStart(wxThread*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#6  0x000000006a213781 in wxThreadInternal::WinThreadStart(void*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#7  0x000007feff71415f in srand () from C:\Windows\system32\msvcrt.dll
#8  0x000007feff716ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll
#9  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#10 0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 9 (Thread 4240.0xc58):
---Type <return> to continue, or q <return> to quit---
#0  0x00000000777bbf1a in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda010dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2  0x000000006a2104ca in wxSemaphoreInternal::WaitTimeout(unsigned long) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#3  0x0000000001945ff1 in cbThreadPool::cbWorkerThread::Entry (this=0xa5bbb70) at D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\sdk\cbthreadpool.cpp:202
#4  0x000000006a20e012 in wxThread::CallEntry() () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#5  0x000000006a21361d in wxThreadInternal::DoThreadStart(wxThread*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#6  0x000000006a213781 in wxThreadInternal::WinThreadStart(void*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#7  0x000007feff71415f in srand () from C:\Windows\system32\msvcrt.dll
#8  0x000007feff716ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll
#9  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#10 0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 8 (Thread 4240.0x139c):
#0  0x00000000777bbf1a in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda010dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2  0x000000006a2104ca in wxSemaphoreInternal::WaitTimeout(unsigned long) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#3  0x0000000001b9557c in BackgroundThread::Entry (this=0x6eca138) at include/backgroundthread.h:138
#4  0x000000006a20e012 in wxThread::CallEntry() () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#5  0x000000006a21361d in wxThreadInternal::DoThreadStart(wxThread*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#6  0x000000006a213781 in wxThreadInternal::WinThreadStart(void*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#7  0x000007feff71415f in srand () from C:\Windows\system32\msvcrt.dll
#8  0x000007feff716ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll
---Type <return> to continue, or q <return> to quit---
#9  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#10 0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 7 (Thread 4240.0x12b8):
#0  0x00000000777bbf1a in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda010dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2  0x000000006a2104ca in wxSemaphoreInternal::WaitTimeout(unsigned long) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#3  0x0000000001b9557c in BackgroundThread::Entry (this=0x6eca0e0) at include/backgroundthread.h:138
#4  0x000000006a20e012 in wxThread::CallEntry() () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#5  0x000000006a21361d in wxThreadInternal::DoThreadStart(wxThread*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#6  0x000000006a213781 in wxThreadInternal::WinThreadStart(void*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#7  0x000007feff71415f in srand () from C:\Windows\system32\msvcrt.dll
#8  0x000007feff716ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll
#9  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#10 0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 6 (Thread 4240.0x13d0):
#0  0x00000000777bbf1a in ntdll!ZwWaitForSingleObject () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda010dc in WaitForSingleObjectEx () from C:\Windows\system32\KernelBase.dll
#2  0x000000006a2104ca in wxSemaphoreInternal::WaitTimeout(unsigned long) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
---Type <return> to continue, or q <return> to quit---
#3  0x0000000001b9557c in BackgroundThread::Entry (this=0x6eca088) at include/backgroundthread.h:138
#4  0x000000006a20e012 in wxThread::CallEntry() () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#5  0x000000006a21361d in wxThreadInternal::DoThreadStart(wxThread*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#6  0x000000006a213781 in wxThreadInternal::WinThreadStart(void*) () from D:\Grabusz\C++\CodeBlocks\codeblocks-code-10640-trunk\src\devel30_64\wxmsw30u_gcc_custom.dll
#7  0x000007feff71415f in srand () from C:\Windows\system32\msvcrt.dll
#8  0x000007feff716ebd in msvcrt!_ftime64_s () from C:\Windows\system32\msvcrt.dll
#9  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#10 0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#11 0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 5 (Thread 4240.0xfa0):
#0  0x00000000777bc48a in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda01420 in KERNELBASE!GetCurrentProcess () from C:\Windows\system32\KernelBase.dll
#2  0x00cc663300996633 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 4 (Thread 4240.0xcbc):
#0  0x00000000777bc48a in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda01420 in KERNELBASE!GetCurrentProcess () from C:\Windows\system32\KernelBase.dll
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 3 (Thread 4240.0x11b8):
---Type <return> to continue, or q <return> to quit---
#0  0x00000000777bd7da in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000000007778ecfd in ntdll!RtlValidateHeap () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 2 (Thread 4240.0x98):
#0  0x00000000777bc48a in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000000007778a427 in ntdll!TpIsTimerSet () from C:\Windows\SYSTEM32\ntdll.dll
#2  0x00000000775659dd in KERNEL32!BaseThreadInitThunk () from C:\Windows\system32\kernel32.dll
#3  0x000000007779a651 in ntdll!RtlUserThreadStart () from C:\Windows\SYSTEM32\ntdll.dll
#4  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 4240.0x102c):
#0  0x00000000777bc48a in ntdll!ZwWaitForMultipleObjects () from C:\Windows\SYSTEM32\ntdll.dll
#1  0x000007fefda01420 in KERNELBASE!GetCurrentProcess () from C:\Windows\system32\KernelBase.dll
#2  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

+screenshot of wx debug alert in attachments

btw why, after running update30_64.bat I find .exe and libraries in output without the debugging symbols? I mean, I only compiled version containing them... does that .bar file remove them or sth?

Oh, and I found (through compiler warnings so I'm sure you're aware of that, but it won't hurt  mentioning it) that there's a variable haveTextString of type bool which is set to false, and later it's only changed to true. Nothing more than that doesn't seem to happen to it, so I think it could removed. It's in the "src\sdk\wxscintilla\src\ScintillaWX.cpp" at 628th line.
Title: Re: Release 15.12, RC1 has arrived
Post by: MortenMacFly on January 12, 2016, 08:24:58 pm
btw why, after running update30_64.bat I find .exe and libraries in output without the debugging symbols? I mean, I only compiled version containing them... does that .bar file remove them or sth?
After running update.bat the "devel" contains everything (including linker libs) with symbols. The "output" folder contains only whats really needed to run everything (without linker libs) and stripped symbols. That what the batch file does.