Code::Blocks

User forums => Nightly builds => Topic started by: killerbot on December 20, 2014, 03:56:13 pm

Title: The 06 December 2014 build (10050) is out.
Post by: killerbot on December 20, 2014, 03:56:13 pm
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

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

A link to the unicode windows wxWidget dll for Code::Blocks : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/wxmsw28u_gcc_cb_wx2812_gcc481-TDM.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/Prerequisites/mingwm10_gcc481-TDM.7z

The 06 December 2014 build is out.
  - Windows :
   http://sourceforge.net/projects/codeblocks/files/Binaries/Nightlies/2014/CB_20141206_rev10050_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on December 31, 2014, 08:57:02 am
I have noticed a bizarre occurrence...

I have created a custom File Type association for .vcproj using the other Code::Block entries as a template...
Quote
Project File  (MS Visual C++)(v7.0+)
C:\Dev-CodeBlocks\codeblocks.exe "%1"
[Open("%1")]
CODEBLOCKS
[IfExec_Open("%1")]
CodeBlocksDDEServer

It automatically tries to import but doesn't explicitly say so...
note first since I already have a cbp for notepad2 it asks to confirm overwriting click [OK]

then it just pops up with the "Compiler selection" small-window,
so as I have MinGW set to default its auto selected so I just click [OK]....
next window is the config import window in this case:
Notepad2
- Debug   win32
- Release win32
I again click [OK]...
then the confirm overwriting again?! clicks [OK]
AND asks for Compiler selection AGAIN!?....
I click ok again and C.R.A.S.H. Bwhahaha... =(

Quote
Faulting application codeblocks.exe,
version 13.12.0.0,

faulting module wxmsw28u_gcc_cb.dll,
version 2.8.12.0,

fault address 0x00413d40.

when I try to run it through the GDB... DING DING!! We have a winner!  ^_^ lol

Quote
Program received signal SIGSEGV, Segmentation fault.

0x6cc8ded4 in
wxmsw28u_gcc_cb!_ZNK13wxArrayString5IndexEPKwbb ()
from C:\Dev-CodeBlocks\wxmsw28u_gcc_cb.dll



ps: if this deserves its own thread I or a mod can move  it there. =)


EDIT:
I tested out deleting all CodeBlocks project files including the layout file..
then re-ran it through gdb still crashes like above

Notepad2(v4.2.25)_src.rar (http://public.joe_devore.mailhaven.com/Notepad2(v4.2.25)_src.rar)
here is the archive with the src for testing... (;p because I couldn't upload it here as an attachment =P)
Includes Notepad 2's src, scintilla src, and the cmd-batch file I created for debugging (customize to your system layout)
Title: Re: The 06 December 2014 build (10050) is out.
Post by: oBFusCATed on December 31, 2014, 10:33:11 am
You need to rebuild codeblocks with symbols to get meaningful backtraces.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on December 31, 2014, 11:53:20 am
I am not compiling it myself.... if you dev's feel like adding the debugging symbols to the next lightly build.. I will try again...

otherwise I linked to a archive containing the notepad 2 src code and mentioned steps so some one else can test it too

I updated txt file with back trace info I could get...

.... considering this is a nightly why is it all being compiled with debugging symbols to begin with?!
Title: Re: The 06 December 2014 build (10050) is out.
Post by: oBFusCATed on December 31, 2014, 12:07:08 pm
.... considering this is a nightly why is it all being compiled with debugging symbols to begin with?!
I don't see any symbols in the txt file. Everything has been stripped.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on December 31, 2014, 03:35:17 pm
statement correction:
.... considering that this is a nightly, why is it not  always being compiled with debugging symbols to begin with?!

I what I am trying to say is considering that it is a nightly dev build why are there not already symbols built into it?



while it is true the symbols have been stripped.... there are some clues maybe not enough but some....
Quote
(gdb) bt
#0  0x6cc8ded4 in wxmsw28u_gcc_cb!_ZNK13wxArrayString5IndexEPKwbb () from C:\Dev-CodeBlocks\wxmsw28u_gcc_cb.dll
#1  0x618cf91e in codeblocks!_ZN11ProjectFile14AddBuildTargetERK8wxString () from C:\Dev-CodeBlocks\codeblocks.dll
#2  0x7050a83d in ?? () from C:\Dev-CodeBlocks\share\codeblocks\plugins\projectsimporter.dll
#3  0x7050a6a0 in ?? () from C:\Dev-CodeBlocks\share\codeblocks\plugins\projectsimporter.dll
#4  0x70510591 in ?? () from C:\Dev-CodeBlocks\share\codeblocks\plugins\projectsimporter.dll
#5  0x7051118d in ?? () from C:\Dev-CodeBlocks\share\codeblocks\plugins\projectsimporter.dll
#6  0x70523205 in ?? () from C:\Dev-CodeBlocks\share\codeblocks\plugins\projectsimporter.dll
#7  0x705244b5 in ?? () from C:\Dev-CodeBlocks\share\codeblocks\plugins\projectsimporter.dll
#8  0x00483634 in ?? ()
#9  0x00483b39 in ?? ()
#10 0x004068a9 in ?? ()
#11 0x004082e7 in ?? ()
#12 0x6cc71e85 in wxmsw28u_gcc_cb!_Z14wxUninitializev () from C:\Dev-CodeBlocks\wxmsw28u_gcc_cb.dll
#13 0x6ccc9010 in wxmsw28u_gcc_cb!_Z7wxEntryP11HINSTANCE__S0_Pci () from C:\Dev-CodeBlocks\wxmsw28u_gcc_cb.dll
#14 0x004022a8 in ?? ()
#15 0x004010fd in ?? ()
#16 0x00000000 in ?? ()
wxmsw28u_gcc_cb.dll
codeblocks.dll
projectsimporter.dll
Title: Re: The 06 December 2014 build (10050) is out.
Post by: killerbot on January 01, 2015, 03:22:34 pm
the binaries of a nightly are indeed stripped, in order to keep the upload/dowload size acceptable.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 01, 2015, 05:01:54 pm
understandable... but unless you plan to upload a debug version for me to test you guys will have to do it on your own...
I gave the instructions to repeat and a copy of Notepad2's src code complete with the Codeblocks & VC project files
plus the batch file I used to  test it.

Debugging (gdb)_CodeBlocks opening Notepad2 vcproj file.cmd
Code: [Select]
@ECHO on
gdb -readnow --args "C:\Dev-CodeBlocks\codeblocks.exe" Notepad2.vcproj
pause
shortened version.... as I copied and customized an older cmd to make it easier...


oohh yah if you are using a newer version of Windows like 7+
you can use a neat program called Types, comment on FileHippo is where I originally heard of it..

http://izt.name/apps/types/
http://izt.name/apps/types/new.rss  <<-- Suffices as a change-log. =D

that and it requires .NET framework 2+
it seems to be loading with .NET(v2), in the JIT debug-log I am getting on this latest crash I am testing on WinXP-64bit...
overall its a good program and at last  ihad what I needed to make the best use of Windows 7,
that is I could finally create ALL of the custom file type associations I use... ;^_^;
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 06, 2015, 11:24:10 am
IO got the repo downloaded  I love TortoiseSVN ^_^

got wxWidgets downloaded now just figuring out where to put it....
I had stored archives of wxWidgets v2.8.11 and v2.9.5 from years ago (2010 & 2013) can't recall ever using them.. I must have had something I intended to compile but got frustrated with it so let it go...

so I have v2.8.12 &  v3.0.2 ^_^
should I bother with v2.8 or just go for v3?!

Title: Re: The 06 December 2014 build (10050) is out.
Post by: BlueHazzard on January 06, 2015, 11:44:05 am
use v2.8. v3 has still some annoying error messages and bugs. With v2.8 you are sure that all is working.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 06, 2015, 11:59:35 am
use v2.8. v3 has still some annoying error messages and bugs. With v2.8 you are sure that all is working.
Hi BlueHazzard, thx for the advice =D

Question....

Do I want

wxMSW (v2.8.12)_src        (97MB)
or
wxWidgets (v2.8.12)_src   (122MB)

I am going with the wxMSW one....
and the setup.h HELL ;_;
and that was trying to import the MS VS workspace (wx_dll.dsw).....
so I am trying the cmd/makefile method now..


Code: [Select]
mingw32-make -f makefile.gcc BUILD=release UNICODE=1 MONOLITHIC=1 SHARED=1
pause


Code: [Select]
mingw32-make -f makefile.gcc BUILD=debug UNICODE=1 MONOLITHIC=1 SHARED=1
pause


Code: [Select]
mingw32-make -f makefile.gcc BUILD=debug   clean
mingw32-make -f makefile.gcc BUILD=release clean
pause


I had to create the batch files myself... wxWidgets needs help   :'( :-\

nope that didn't work either.... needed the "SHARED=1" as well duh?!


whats worse than that  headache...

is CodeBlocks src does not seem to have a debug target...

aside from manually telling each project to to add "-g"..
there is a target "all" just no debug target...   ;;;;___;;;;;

so far I have "wxmsw28ud_gcc_custom.dll" built....

though I made note that "wxmsw28u_gcc_cb.dll" is listed internally as said name...

will there be any issues using this one, wxmsw28ud_gcc_custom.dll
and do I have to rename it to wxmsw28u_gcc_cb.dll?
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 08, 2015, 11:46:28 am
So compiling done (yesterday).... after hours I had to manually add 'd' to the append 'ud' for the wx..
and  I to manually set the -g flag in each and ever project file ;_;

I compiled wx as 
- wxmsw28ud_gcc_custom.dll
mingw32-make -f makefile.gcc SHARED=1 MONOLITHIC=1 BUILD=debug UNICODE=1

so I could debug/report... but trying to run errors out with
dll is debug but exe is not debug...

and I modified the update.bat to comment out the strip commands...

so what am I missing
Title: Re: The 06 December 2014 build (10050) is out.
Post by: BlueHazzard on January 08, 2015, 03:35:50 pm
So compiling done (yesterday).... after hours I had to manually add 'd' to the append 'ud' for the wx..
and  I to manually set the -g flag in each and ever project file ;_;

You could have used the global variable "cb_release_type" and add there "-g" in the "base"
(Settings->Global Variable->Current Variable->cb_release_type->base = -g)

so I could debug/report... but trying to run errors out with
dll is debug but exe is not debug...

try to fresh rebuild everything (i had the error also a lot times, but i don't remember what i have done  :-\ )

and I modified the update.bat to comment out the strip commands...
good idea  ;)

You can also look at full build log and check if the right build where used...

and that was trying to import the MS VS workspace (wx_dll.dsw).....
never try this, if you are going with the gcc...
better use the makefile way...

will there be any issues using this one, wxmsw28ud_gcc_custom.dll
and do I have to rename it to wxmsw28u_gcc_cb.dll?
if the settings for wxWidgets are right, i never had to do anything like that...


greetings
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 09, 2015, 02:24:42 am
You could have used the global variable "cb_release_type" and add there "-g" in the "base"
(Settings->Global Variable->Current Variable->cb_release_type->base = -g)

when you mean base you mean the user-defined-fields right?
Quote
User-defined Fields:
txt-box1: [base = -g]

or do you mean this:
base="F:\Dev-src\CodeBlocks_src -g"





______________________________________________________
Actually I copied the bat file then edited it.   loi  ;D

on that note how about renaming all the .bat's to .cmd  ;D  .cmd looks so much better
.bat is kinda like DOS era and such...

I have attached a copy of the update_debug.bat can you guys please get it committed?
:: Commented out to allow symbols to remain so debugging can be done.
:: if more is needed for debugging to work correctly , Devs please edit as need.


also, please add to the ignore list as they were not on it:

plugins/contrib/FortranProject/FortranProject_cbsvn.depend
plugins/contrib/FortranProject/FortranProject_cbsvn.layout


I attached an archive containing 3 .cmd files
makeWX_dll__Clean_ALL.cmd
makeWX_dll__Debug.cmd
makeWX_dll__Release.cmd

which are setup to use the gcc make files ^_^
Title: Re: The 06 December 2014 build (10050) is out.
Post by: ollydbg on January 09, 2015, 04:50:54 am
@Melchior, normally C::B is built against release version of wx library, but you can build C::B against debug version of wx library, see:
Developer documentation - CodeBlocks (http://wiki.codeblocks.org/index.php?title=Developer_documentation#Debugging_C::B)
Quote
You can debug C::B under C::B (with the debugger plugin), also, you can link C::B to the debug version of wxWidgets library, so you can see whether a bug is located in C::B source code or wxWidgets' source code, see here: patch to build C::B against wx debug library

About the "cb_release_type", this can be opened by click on the
Menu->Settings->Global Variables
And in the opened Global Variable Editor dialog, edit or add one variable named "cb_release_type", and set its  base filed(Under Built-in field panel) as "-g". (note no quotes).
Title: Re: The 06 December 2014 build (10050) is out.
Post by: jens on January 09, 2015, 06:21:50 am
I have attached a copy of the update_debug.bat can you guys please get it committed?
This will for sure not be committed, because it does not make sense.

The build-process (and update[.bat]-script) create two folders: devel and output.
The first one is (as the name clearly states) for developping and includes debugging symbols, the second one includes the stripped (release-)version.

I don't see any cause to change this.
Renaming the *.bat-files to *.cmd is possible, but has no real benefit (at least not at this moment), but might break existing (more or less aoutomated) build-processes, that rely on the existing names.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 09, 2015, 07:46:41 am
I attached a png image where I combined the image of all three Global Variables needed by
Code-blocks....
- Boost
- cb_release_type
- wx

yah I get the "quote" thing... CodeBlocks treats the whole box as a string so " " is unnecessary and
only used here to show a bit of text as a string...
"F:\Dev-src\CodeBlocks_src\src -g"

is what I am using now after your suggestion to add to base and mot a user-defined variable....

I also attached the rpt file I found, thx for letting me know about it =D...


debugging plugin? I didn't see one on the plugin drop down, you must mean the main debug drop down menu..

For most debugging I create a simple cmd file like this one which I created to run codeblocks.exe through gdb...

Debugging (gdb)_CodeBlocks.cmd
Quote
@ECHO on
:: Core Dump Checking through the GNU Debugger (GDB)
::
:: Symbol Servers
::             - http://msdl.microsoft.com/download/symbols
::
:: --directory=" "   // Specifies location of Source code,
::                   // multiply Directories can be listed one per cmd flag.
::
:: --symbols=" "     // Debug Symbol file(s).
:: --exec=" "        // exe to be debugged (does not contain debug symbols).
:: --se=" "          // exe to be debugged (contains debug symbols ^_^).

gdb -readnow -se="codeblocks.exe"
pause



for the .bat to .cmd suggestion, fair enough.


I have attached a copy of the update_debug.bat can you guys please get it committed?
This will for sure not be committed, because it does not make sense.

The build-process (and update[.bat]-script) create two folders: devel and output.
The first one is (as the name clearly states) for developping and includes debugging symbols, the second one includes the stripped (release-)version.

I don't see any cause to change this.
Renaming the *.bat-files to *.cmd is possible, but has no real benefit (at least not at this moment), but might break existing (more or less automated) build-processes, that rely on the existing names.


I believe you misunderstand me....
there exists now in the repo three update.bat files, and all three are release grade:
- update.bat              <-- wx v2.8
- update30.bat          <-- wx v3.0
- update30_64.bat    <-- wx v3.0 but it appears to be 64bit..

all three files already part of the Codeblocks svn repository have strip at the end of them...
Quote
echo Stripping debug info from output tree
strip output30_64\*.exe
strip output30_64\*.dll
strip %CB_OUTPUT_RESDIR%\plugins\*.dll

so I made a copy of the "update.bat" file and renamed it  "update_debug.bat"
where I commented out the strip commands so debugging info remains intact

my customized copy of "update.bat" is not part of the repository and I was asking for it to be added

That and maybe a bit of renaming work...  =D
As these two files imply they are for wxWidgets v3.0
- update30.bat
- update30_64.bat
would it not make sense to rename
update.bat  and update_debug.bat
to
- update28.bat
- update28_debug.bat

?  optional suggestion of course...







[attachment deleted by admin]
Title: Re: The 06 December 2014 build (10050) is out.
Post by: jens on January 09, 2015, 09:03:21 am
I have attached a copy of the update_debug.bat can you guys please get it committed?
This will for sure not be committed, because it does not make sense.

The build-process (and update[.bat]-script) create two folders: devel and output.
The first one is (as the name clearly states) for developing and includes debugging symbols, the second one includes the stripped (release-)version.

I don't see any cause to change this.
Renaming the *.bat-files to *.cmd is possible, but has no real benefit (at least not at this moment), but might break existing (more or less automated) build-processes, that rely on the existing names.


I believe you misunderstand me....
I think it's not me who misunderstands something.
It's your choice how to debug C::B, but I prefer to use C::B to do it and never had unsolvable problems.
Using gdb via  commandline is possible and makes sense sometimes, but most of the times a gui is much easier to use.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: eMan.Lived on January 10, 2015, 02:15:53 am
The height of the Todo list docked to the top or bottom is not remembered after hiding and is reset to the some minimum in the subsequent show.

BTW, there is some possibility to make the Todo list as a tab in the Logs & others?
Title: Re: The 06 December 2014 build (10050) is out.
Post by: ollydbg on January 10, 2015, 04:31:26 am
BTW, there is some possibility to make the Todo list as a tab in the Logs & others?
Yes, you can check on the option: Menu->Settings->Environment->TO DO->Include the todo list in the message panel, and restart C::B.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: eMan.Lived on January 10, 2015, 05:52:32 am
Yes, you can ...
Thanks! Don't know how I missed it. :)
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 10, 2015, 08:45:11 am
wx_sufix = u
is the default set in each project file...
but DO TO THE FACT that I need to compile a debug version of Codeblocks.... so I can get to the bottom of this bug/crash I discovered...
it is needed to either manually edit every single project file  which will cause them to be out of sync with the repo...
or define a global variable....

some help please...
Title: Re: The 06 December 2014 build (10050) is out.
Post by: stahta01 on January 10, 2015, 09:13:07 am
wx_sufix = u
is the default set in each project file...
but DO TO THE FACT that I need to compile a debug version of Codeblocks.... so I can get to the bottom of this bug/crash I discovered...
it is needed to either manually edit every single project file  which will cause them to be out of sync with the repo...
or define a global variable....

some help please...

Use the new contrib plugin a few months old named something like project manipulator.

Tim S.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: jens on January 10, 2015, 09:16:21 am
wx_sufix = u
is the default set in each project file...
but DO TO THE FACT that I need to compile a debug version of Codeblocks.... so I can get to the bottom of this bug/crash I discovered...
it is needed to either manually edit every single project file  which will cause them to be out of sync with the repo...
or define a global variable....

some help please...
You should not need debug-versions of wxWidgets unless you want to debug wxWidgets itself.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 10, 2015, 10:57:08 am
Jens...   it is only makes sense to ensure the complete program and its dependencies EACH have their symbols... 
that way no matter where the bug may be... it can be found without having to compile again and again...

Compiling wxWidgets as debug was easy...
makeWX_dll__gcc__Debug.cmd
Quote
mingw32-make -f makefile.gcc BUILD=debug UNICODE=1 MONOLITHIC=1 SHARED=1 DEBUG_FLAG=1 DEBUG_INFO=1
pause
Compiling Code::Blocks as debug has been a headache,
the project files  DO NOT have a [debug-all] target if you guys could please add one some day would be great ;^_^;
and would make it easier to get a debug build complied

i got around this by editing the
Project build options --> Custom variables -->
changing  [WX_SUFFIX = u]  to [WX_SUFFIX = ud] for each and every file


 thx stahta01's suggestion to use

Plugin --> Project option manipulator

to change [WX_SUFFIX = u]  to [WX_SUFFIX = ud] on all open project files looks like it will work on contrib where there are so many project files on that workspace....

but this method would of course edit all the project files as i mentioned above, making them out of sync to the 
svn-repository....


I am done for one night...
Title: Re: The 06 December 2014 build (10050) is out.
Post by: eMan.Lived on January 11, 2015, 11:51:32 pm
C::B does not remember the active project in the workspace between sessions.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: oBFusCATed on January 12, 2015, 01:47:05 am
Yes, it does...
If you're closing codeblocks and not the workspace, then probably it is crashing and it is not saving the bla.workspace.layout file.

Posting the exacts steps to reproduce the problem might be helpful.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: ollydbg on January 12, 2015, 02:03:23 am
i got around this by editing the
Project build options --> Custom variables -->
changing  [WX_SUFFIX = u]  to [WX_SUFFIX = ud] for each and every file
Yes, the workspace don't have compiler settings, so you need to change the cbp files. Besides the WX_SUFFIX change, you may also need an extra -D__WXDEBUG__ for every cbp, see: annoying crash when debugging CC's auto-suggestion (http://forums.codeblocks.org/index.php/topic,17316.msg130972.html#msg130972). For git(I use git-svn), this is not an issue, because you can have many branches, and synchronize with our SVN head.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: eMan.Lived on January 12, 2015, 02:11:18 am
Yes, it does...
If you're closing codeblocks and not the workspace, then probably it is crashing and it is not saving the bla.workspace.layout file.

Posting the exacts steps to reproduce the problem might be helpful.

First, I have delete default.workspace.layout and default.workspace.

Start C::B and close it. File default.workspace.layout was created.

Start C::B again and open the project A and then the project B. At this point the project B is active.

Close C::B and answer Yes for "Workspace 'Default workspace' is modified. Do you want to save it?" prompt. File default.workspace was created.

Start C::B. At this point the project A is active not the project B.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: oBFusCATed on January 12, 2015, 09:09:21 am
So when you open the default.workspace next time it contains just project A?
Title: Re: The 06 December 2014 build (10050) is out.
Post by: eMan.Lived on January 12, 2015, 03:06:04 pm
Project B is also present.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: scarphin on January 13, 2015, 03:46:16 pm
I realized 'clear' button in 'project build options -> search directories -> compiler|linker|resource compiler' doesn't work if nothing is selected. Can anyone else reproduce this?

Win7 x64
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 14, 2015, 12:33:07 am
i got around this by editing the
Project build options --> Custom variables -->
changing  [WX_SUFFIX = u]  to [WX_SUFFIX = ud] for each and every file
Yes, the workspace don't have compiler settings, so you need to change the cbp files. Besides the WX_SUFFIX change, you may also need an extra -D__WXDEBUG__ for every cbp, see: annoying crash when debugging CC's auto-suggestion (http://forums.codeblocks.org/index.php/topic,17316.msg130972.html#msg130972). For git(I use git-svn), this is not an issue, because you can have many branches, and synchronize with our SVN head.


yah that looks like what I was probably missing... thx Olly
-D__WXDEBUG__
but this I should be able to add that to the CodeBlocks Global variable base  along with -g..

so this is what it will look like for me ("" are used only to indicate string)
"F:\Dev-src\CodeBlocks_src -g -D__WXDEBUG__"


_______________________
EDIT



I cleaned out the old rpt file and  and tried  loading  "Notepad2.vcproj"
using the custom File Type Associations I had created
(I will get to trying to compile that Debug build later...)
Code: [Select]
-------------------

Error occurred on Tuesday, January 13, 2015 at 20:43:53.

C:\Dev-CodeBlocks\codeblocks.exe caused an Access Violation at location 6d053d40 in module
C:\Dev-CodeBlocks\wxmsw28u_gcc_cb.dll
Reading from location 00000000.

Registers:
eax=0000000d  ebx=084e7fd4  ecx=00000000  edx=00000001  esi=00000001  edi=0000000d
eip=6d053d40   esp=007bf2c8  ebp=00000000  iopl=0         nv up ei pl nz na pe nc
cs=0023              ss=002b            ds=002b            es=002b 
fs=0053              gs=002b            efl=00010202

Call stack:


DrWatson Log excerpt:
Code: [Select]
        Exception number: c0000005 (access violation)

the Fault -> area stripped w/ no usable data!

Loi... 
C:\Dev-CodeBlocks\codeblocks.exe   caused an Access Violation
at location 6d053d40
in module
C:\Dev-CodeBlocks\wxmsw28u_gcc_cb.dll     <<-- PERHAPS THAT IS WHY I NEEDED to BUILD WxWidgets  as Debug!!  ;) 8)
Title: Re: The 06 December 2014 build (10050) is out.
Post by: ollydbg on January 14, 2015, 03:47:05 am
...
so this is what it will look like for me ("" are used only to indicate string)
"F:\Dev-src\CodeBlocks_src -g -D__WXDEBUG__"
...
Good catch, the "-D__WXDEBUG__" can be put in the global compiler variable.
What is the string "F:\Dev-src\CodeBlocks_src" used for? I think "-g -D__WXDEBUG__" should be enough.

Quote
_______________________
EDIT



I cleaned out the old rpt file and  and tried  loading  "Notepad2.vcproj"
using the custom File Type Associations I had created
(I will get to trying to compile that Debug build later...)
Code: [Select]
-------------------

Error occurred on Tuesday, January 13, 2015 at 20:43:53.

C:\Dev-CodeBlocks\codeblocks.exe caused an Access Violation at location 6d053d40 in module
C:\Dev-CodeBlocks\wxmsw28u_gcc_cb.dll
Reading from location 00000000.

Registers:
eax=0000000d  ebx=084e7fd4  ecx=00000000  edx=00000001  esi=00000001  edi=0000000d
eip=6d053d40   esp=007bf2c8  ebp=00000000  iopl=0         nv up ei pl nz na pe nc
cs=0023              ss=002b            ds=002b            es=002b 
fs=0053              gs=002b            efl=00010202

Call stack:


DrWatson Log excerpt:
Code: [Select]
        Exception number: c0000005 (access violation)

the Fault -> area stripped w/ no usable data!

Loi... 
C:\Dev-CodeBlocks\codeblocks.exe   caused an Access Violation
at location 6d053d40
in module
C:\Dev-CodeBlocks\wxmsw28u_gcc_cb.dll     <<-- PERHAPS THAT IS WHY I NEEDED to BUILD WxWidgets  as Debug!!  ;) 8)
I think you can simply start debugging C::B under C::B, and you can get a full call stack by GDB. Generally, the bug is in C::B source code.
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 14, 2015, 07:01:45 am
When opening Code::Blocks Project files or workspace files... 
CodeBlocks notifies me that there are THREE global variables that are part of  CB's src

THAT MUST BE DEFINED and cannot be left [void].....
"The base member is mandatory!"

the are as follows:
Code: [Select]
boost:
base:"F:\Dev-src\boost_1_57_0"


cb_release_type:
base: "F:\Dev-src\CodeBlocks_src -g -D__WXDEBUG__ "  <<-- The directory is the least thing I can put here... so it isn't null...
Lib : "F:\Dev-src\CodeBlocks_src\src\devel"          <<-- not fully sure what was needed so I added this one,
                                                                                                   CB doesn't complain....

wx:
Base   : "F:\Dev-src\wxMSW-2.8.12"                <<-- If more then the base is needed or not I am not sure...
Include: "F:\Dev-src\wxMSW-2.8.12\include"
Lib    : "F:\Dev-src\wxMSW-2.8.12\lib"
obj    : "F:\Dev-src\wxMSW-2.8.12\build\msw\gcc_mswuddll"
bin    : "F:\Dev-src\wxMSW-2.8.12\lib\gcc_dll"



"cb_release_type"
since this references a release build... shouldn't there be a "cb_debug_type"?
in which all debug global variables could be defined?

AND....  adding debug all target to take care of  the internal variables like
WX_SUFFIX = ud

File locations will vary, so it makes sense that  they would need to be defined this way as a global variable...
 ^_^ =D

instead of forcing everyone to jump through hoops to get release/debug setup why not added

targets: all_release, all_debug

and instead adding " -g -D__WXDEBUG__ " to the global variable base... they should be added in here as part a a debug target:
Code: [Select]
$(#CB_RELEASE_TYPE)
-pipe
-mthreads
-fmessage-length=0
-fexceptions
-Winvalid-pch
-g
-D__WXDEBUG__


I think you can simply start debugging C::B under C::B, and you can get a full call stack by GDB. Generally, the bug is in C::B source code.
... maybe once I am finished compiling it.. right?




__________________
EDIT4:


-g
-D__WXDEBUG__

with these added to the global variable cb_release_type's base..  that only leaves...
WX_SUFFIX = ud
and finding a way to get it overwrite the cb project files default value *without* modifying the cbp files




for that other mention of using git, git doesn't run on XP anymore... it will not install...



____________________
EDIT5:

attachment
Title: Re: The 06 December 2014 build (10050) is out.
Post by: Melchior on January 14, 2015, 11:04:55 am
After a quite a bit of effort an tweaks to the project files and such
I got it finish compiling but its still crashing...  >:( >:(

some of the projects stored the "WX_SUFFIX = u" at the target level and did not get overwritten when I use the
Project Options Manipulator plugin to overwrite all the  u with ud
so I had to manually do it each time the compiler stopped to complain...

in contrib plugin  NassiShneiderman the way the project file was written needs help...
it targets  >:( long story short I had to do this for both base and include

Global Variable: boost
base   : "F:\Dev-src\boost_1_57_0\"
include: "F:\Dev-src\boost_1_57_0\"

Search.Dir.Compiler
$(#wx.include)           <<-- when  i set up wx I filled in all/most global variable, so this was safe  :P
$(#boost.include)      <<-- Really?!  ::)
$(#boost)                  <<-- is what it really should be because they declare the full path so only base is needed right?!
Code: [Select]
#include <boost/spirit/include/classic.hpp>
#include <boost/spirit/include/classic_core.hpp>
#include <boost/spirit/include/classic_symbols.hpp>
#include <boost/spirit/include/classic_confix.hpp>



___________________
EDIT1:

I found adplus in the Debbuging tools for windows I had installed a while back.... so I gave it a try
archive with logs attached,

dmp files are way to big..
140MB - FULLDUMP_FirstChance_epr_Process_Shut_Down_codeblocks.exe__04d4_2015-01-14_18-54-24-593_03a4.dmp
140MB - FULLDUMP_SecondChance_av_AccessViolation_codeblocks.exe__04d4_2015-01-14_18-54-19-859_03a4.dmp
8.5MB  - MINIDUMP_FirstChance_av_AccessViolation_codeblocks.exe__04d4_2015-01-14_18-54-11-812_03a4.dmp
Title: Re: The 06 December 2014 build (10050) is out.
Post by: ollydbg on January 18, 2015, 08:17:00 am
@Melchior

Quote
"cb_release_type"
since this references a release build... shouldn't there be a "cb_debug_type"?
in which all debug global variables could be defined?
"release_type" does not mean this is a "release build", the value of "cb_release_type" can be either "release version" or "debug version". For the "debug version", you need "-g", and for "release version", you may need "-O2"

Quote
cb_release_type:
base: "F:\Dev-src\CodeBlocks_src -g -D__WXDEBUG__ "  <<-- The directory is the least thing I can put here... so it isn't null...
Lib : "F:\Dev-src\CodeBlocks_src\src\devel"          <<-- not fully sure what was needed so I added this one,
                                                                                                   CB doesn't complain....
I think you don't need to set the "lib" field, only "base" field is enough. It is the same to the wx global compiler variable.

Quote
...
instead adding " -g -D__WXDEBUG__ " to the global variable base... they should be added in here as part a a debug target:
...
Yes, the "-D__WXDEBUG__" can be put there if you want to build C::B against debug version of wx library.

Quote
for that other mention of using git, git doesn't run on XP anymore... it will not install...
Use msysgit, it works fine in my Windows XP.

Quote
some of the projects stored the "WX_SUFFIX = u" at the target level and did not get overwritten when I use the
Project Options Manipulator plugin to overwrite all the  u with ud
so I had to manually do it each time the compiler stopped to complain...
I never used project Options Manipulator plugin, cbp files are just XML files, so you can just open those files in any editor, and search and replace those text from "WX_SUFFIX = u" to "WX_SUFFIX = ud".

BTW: I suggest you to use GDB to get the useful crash report and call stack. You don't need to build C::B against debug version of wx, I think building C::B against release of wx is enough to catch the crash. I don't use other debugging tools, so I don't understand you posted logs from other tools.

Title: Re: The 06 December 2014 build (10050) is out.
Post by: oBFusCATed on January 24, 2015, 04:47:55 pm
I realized 'clear' button in 'project build options -> search directories -> compiler|linker|resource compiler' doesn't work if nothing is selected. Can anyone else reproduce this?
Yes, I'm able to reproduce it and I have a fix for it in my local repo...
Title: Re: The 06 December 2014 build (10050) is out.
Post by: scarphin on January 25, 2015, 12:33:21 am
Nice to hear that.