Author Topic: The 06 December 2014 build (10050) is out.  (Read 24517 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5178
The 06 December 2014 build (10050) is out.
« 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.

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:



    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #1 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
    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)
    « Last Edit: December 31, 2014, 09:12:53 am by Melchior »
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 12000
      • Travis build status
    Re: The 06 December 2014 build (10050) is out.
    « Reply #2 on: December 31, 2014, 10:33:11 am »
    You need to rebuild codeblocks with symbols to get meaningful backtraces.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #3 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?!
    « Last Edit: December 31, 2014, 11:58:12 am by Melchior »
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 12000
      • Travis build status
    Re: The 06 December 2014 build (10050) is out.
    « Reply #4 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.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #5 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
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline killerbot

    • Administrator
    • Lives here!
    • *****
    • Posts: 5178
    Re: The 06 December 2014 build (10050) is out.
    « Reply #6 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.

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #7 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... ;^_^;
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #8 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?!

    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline BlueHazzard

    • Developer
    • Lives here!
    • *****
    • Posts: 2491
    Re: The 06 December 2014 build (10050) is out.
    « Reply #9 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.

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #10 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?
    « Last Edit: January 06, 2015, 03:46:08 pm by Melchior »
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #11 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
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline BlueHazzard

    • Developer
    • Lives here!
    • *****
    • Posts: 2491
    Re: The 06 December 2014 build (10050) is out.
    « Reply #12 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

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #13 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 ^_^
    « Last Edit: January 09, 2015, 02:29:49 am by Melchior »
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5226
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 06 December 2014 build (10050) is out.
    « Reply #14 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
    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).
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 06 December 2014 build (10050) is out.
    « Reply #15 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.

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #16 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]
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 06 December 2014 build (10050) is out.
    « Reply #17 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.

    Offline eMan.Lived

    • Multiple posting newcomer
    • *
    • Posts: 21
    Re: The 06 December 2014 build (10050) is out.
    « Reply #18 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?
    [AAAA|+}

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5226
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 06 December 2014 build (10050) is out.
    « Reply #19 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.
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline eMan.Lived

    • Multiple posting newcomer
    • *
    • Posts: 21
    Re: The 06 December 2014 build (10050) is out.
    « Reply #20 on: January 10, 2015, 05:52:32 am »
    Yes, you can ...
    Thanks! Don't know how I missed it. :)
    [AAAA|+}

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #21 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...
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline stahta01

    • Lives here!
    • ****
    • Posts: 6633
      • My Best Post
    Re: The 06 December 2014 build (10050) is out.
    « Reply #22 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.
    C Programmer working to learn more about C++ and Git.
    On Windows 7 64 bit and Windows 10 32 bit.
    On Debian Stretch, compiling CB Trunk against wxWidgets 3.0.
    --
    When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

    Offline jens

    • Administrator
    • Lives here!
    • *****
    • Posts: 7265
      • Jens' unofficial debian-repository for the Code::Blocks - IDE
    Re: The 06 December 2014 build (10050) is out.
    « Reply #23 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.

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #24 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...
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline eMan.Lived

    • Multiple posting newcomer
    • *
    • Posts: 21
    Re: The 06 December 2014 build (10050) is out.
    « Reply #25 on: January 11, 2015, 11:51:32 pm »
    C::B does not remember the active project in the workspace between sessions.
    [AAAA|+}

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 12000
      • Travis build status
    Re: The 06 December 2014 build (10050) is out.
    « Reply #26 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.
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5226
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 06 December 2014 build (10050) is out.
    « Reply #27 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. For git(I use git-svn), this is not an issue, because you can have many branches, and synchronize with our SVN head.
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline eMan.Lived

    • Multiple posting newcomer
    • *
    • Posts: 21
    Re: The 06 December 2014 build (10050) is out.
    « Reply #28 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.
    [AAAA|+}

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 12000
      • Travis build status
    Re: The 06 December 2014 build (10050) is out.
    « Reply #29 on: January 12, 2015, 09:09:21 am »
    So when you open the default.workspace next time it contains just project A?
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline eMan.Lived

    • Multiple posting newcomer
    • *
    • Posts: 21
    Re: The 06 December 2014 build (10050) is out.
    « Reply #30 on: January 12, 2015, 03:06:04 pm »
    Project B is also present.
    [AAAA|+}

    Offline scarphin

    • Lives here!
    • ****
    • Posts: 644
    Re: The 06 December 2014 build (10050) is out.
    « Reply #31 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

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #32 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. 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)
    « Last Edit: January 14, 2015, 03:04:35 am by Melchior »
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5226
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 06 December 2014 build (10050) is out.
    « Reply #33 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.
    If some piece of memory should be reused, turn them to variables (or const variables).
    If some piece of operations should be reused, turn them to functions.
    If they happened together, then turn them to classes.

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #34 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
    « Last Edit: January 14, 2015, 07:40:38 am by Melchior »
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline Melchior

    • Multiple posting newcomer
    • *
    • Posts: 63
    • Sage of Life, Reason, and Time
    Re: The 06 December 2014 build (10050) is out.
    « Reply #35 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
    « Last Edit: January 15, 2015, 01:04:30 am by Melchior »
    (PC Specs)
    CPU: AMD FX-9590 4.7GHz 8-core  RAM: 32GB
    Motherboard: Asus SABERTOOTH 990FX R2.0
    GPU: nVidia GTX 1070 Ti 8GB  --  GFX Drivers: Nvidia v431.60
    OS: Windows 7 Ultimate 64-bit SP1 (x64)

    Offline ollydbg

    • Developer
    • Lives here!
    • *****
    • Posts: 5226
    • OpenCV and Robotics
      • Chinese OpenCV forum moderator
    Re: The 06 December 2014 build (10050) is out.
    « Reply #36 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.

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

    Offline oBFusCATed

    • Developer
    • Lives here!
    • *****
    • Posts: 12000
      • Travis build status
    Re: The 06 December 2014 build (10050) is out.
    « Reply #37 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...
    (most of the time I ignore long posts)
    [strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

    Offline scarphin

    • Lives here!
    • ****
    • Posts: 644
    Re: The 06 December 2014 build (10050) is out.
    « Reply #38 on: January 25, 2015, 12:33:21 am »
    Nice to hear that.