Code::Blocks

User forums => Nightly builds => Topic started by: killerbot on January 06, 2009, 09:21:32 pm

Title: The 06 January 2009 build (5382) is out.
Post by: killerbot on January 06, 2009, 09:21:32 pm
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

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

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

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

The 06 January 2009 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20090106_rev5382_win32.7z
  - Linux :
   none

Resolved Fixed:


Regressions/Confirmed/Annoying/Common bugs:


Title: Re: The 06 January 2009 build (5382) is out.
Post by: Xaviou on January 06, 2009, 11:39:13 pm
Ubuntu 7.04 to 8.10 Amd64 tar.gz archive (containing '.deb' installers builds with wx288) can be found here (http://www.esnips.com/web/CodeBlocks) or here (http://www.archive-host.com/compteur.php?url=http://s3.archive-host.com/membres/up/1024301307/CodeBlocks/CB_20090105_802_rev5382_Ubuntu704-810_wx288_amd64tar.gz) (direct link).
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on January 07, 2009, 12:14:06 am
I just uploaded the nightlies for debian to my server (http://apt.jenslody.de).
Title: Re: The 06 January 2009 build (5382) is out.
Post by: madscientist on January 07, 2009, 01:10:02 am
There's a bug with dragging highlighted text.
The text cannot be dropped anywhere unless the mouse is moved far away from the initial selection first.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 07, 2009, 03:18:54 am
There's a bug with dragging highlighted text.
The text cannot be dropped anywhere unless the mouse is moved far away from the initial selection first.
I can't reproduce this problem in my system.

To OP:
Thanks for sharing!
The Drag toolbar crash problem seems fixed. so, I upgrade the wxmsw28u_gcc_cb_wx288 to wxmsw28u_gcc_cb_wx289, it works fine. still exists, so I should use wx288 instead.

Thank you! I will continue testing.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 07, 2009, 04:05:49 pm
I think there is a bug when debugging. (I'm using windows XP and Mingw from TDragon.

My program was linked to the debug library of opencv. which are located in:

F:\test1\lib\***
the source file is located in
F:\opencv\src\cxcore\***

It seems that I can't set break points  in the source file. GDB complaints that :
Code: [Select]
> break "F:/opencv/src/cxcore/cxarray.cpp:104"
No source file named F:/opencv/src/cxcore/cxarray.cpp.
Breakpoint 3 ("F:/opencv/src/cxcore/cxarray.cpp:104) pending.
>>>>>>cb_gdb:

But my source file is exactly named "F:/opencv/src/cxcore/cxarray.cpp", my program will call some function in the cxarray.cpp.

Also,  another problem is I can't "step into" the source code. ( This functionality is available in the last svn release).

The problem seems happens in this SVN version. The last version works well as I can remember.

I search the forum and found some related discussion.
I download the zip from the thread:
http://forums.codeblocks.org/index.php/topic,4896.msg38390.html#msg38390
And still it can't set break point in the DLL source file.

Some one can explain it?
Thanks.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: rhf on January 07, 2009, 04:55:17 pm
ollydbg,
Just a thought, but TDM's release of GCC 4.3.2 TDM-2 dated 1008-12-09 includes a fix that solved a similar debug problem that I was having. This was for break points in a header file so it may not apply, but you might consider it if you are using an earlier release.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 07, 2009, 05:38:32 pm
ollydbg,
Just a thought, but TDM's release of GCC 4.3.2 TDM-2 dated 1008-12-09 includes a fix that solved a similar debug problem that I was having. This was for break points in a header file so it may not apply, but you might consider it if you are using an earlier release.
HI, Thanks for your hint. Actually, I already use the TDM's 4.3.2 TDM-2 2008-12-09 as you mentioned.
Maybe, it is related to the "setting break point in a header file" issue, maybe not, I'm not sure. :(

The problem seems comes from "How does the compiler and GDB handle with the path of source file".
I test the zip file from :
http://forums.codeblocks.org/index.php/topic,4896.msg38390.html#msg38390

There are two build targets. One is a exe file. The other is a DLL file.
The exe file will load the DLL file when it runs. Both of these targets were build with Debug enabled. So, I think that in the "TestDLL.dll", there are some part to reference it's source file path.

I put the project in "C:\DebugTest"

main.cpp was located in "C:\DebugTest\TestApp"
dllmain.cpp was located in "C:\DebugTest\TestDLL"

But I can't set break point in the "dllmain.cpp".

GDB reported:
Code: [Select]
>>>>>>cb_gdb:
> break "C:/DebugTest/TestDLL/dllmain.cpp:16"
No source file named C:/DebugTest/TestDLL/dllmain.cpp in loaded symbols.
Breakpoint 2 ("C:/DebugTest/TestDLL/dllmain.cpp:16) pending.

It is very confused that sometimes the compiler can use the "relative source file path", and sometimes, they use full path. So does the GDB. (I'm not sure how does the linker handle the path related issue).

So, I'm totally lost in this problem :(, can someone give a clarification? Thanks.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: rhf on January 07, 2009, 06:15:37 pm
sometimes the compiler can use the "relative source file path", and sometimes, they use full path. So does the GDB.

Interesting. I have had the same problem debugging using relative paths.  I now generally use absolute paths in my Search directories, and debugging seems to work much better. This sure looks like a bug, but I haven't been able to create a simple test case to demonstrate it
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on January 07, 2009, 06:24:57 pm
GDB reported:
Code: [Select]
>>>>>>cb_gdb:
> break "C:/DebugTest/TestDLL/dllmain.cpp:16"
No source file named C:/DebugTest/TestDLL/dllmain.cpp in loaded symbols.
Breakpoint 2 ("C:/DebugTest/TestDLL/dllmain.cpp:16) pending.

The gdb-message is normal for shared libraries that are not yet loaded.
The breakpoint is pending means that it's address can not (yet)  be resolved.
It will be reevaluated after the lib is loaded.

It has nothing to do with the step-into issue.

If the dll and the exe are compiled with C::B make sure you have not (accidently) unchecked "Settings -> Compiler and debugger... -> Global compiler settings -> Other settings (rightmost tab) -> Advanced options... -> Others -> Use full path for source files (GDB workaround):".
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 07, 2009, 06:36:58 pm
Thanks jens.
I have this option enable by default.
see the attachment image.

I also enable the full compiler output, when compiling, the output are here:
Code: [Select]
-------------- Build: TestDLL in cb_debug_test ---------------

[ 50.0%] mingw32-g++.exe -Wall -g     -ID:\SourceCode\Libraries\wxWidgets2.8\src\msw  -c C:\DebugTest\TestDLL\dllmain.cpp -o .objs\TestDLL\dllmain.o
[100.0%] mingw32-g++.exe -shared  -Wl,--out-implib=bin\libTestDLL.a -Wl,--dll  .objs\TestDLL\dllmain.o   -o bin\TestDLL.dll 
Creating library file: bin\libTestDLL.a
Output size is 22.46 KB

-------------- Build: TestApp in cb_debug_test ---------------

[ 50.0%] mingw32-g++.exe -Wall -g     -I. -ID:\SourceCode\Libraries\wxWidgets2.8\src\msw  -c C:\DebugTest\TestApp\main.cpp -o .objs\TestApp\main.o
C:\DebugTest\TestApp\main.cpp: In function 'void LoadDllPlugin()':
C:\DebugTest\TestApp\main.cpp:103: warning: unused variable 'status'
[100.0%] mingw32-g++.exe  -o bin\TestApp.exe .objs\TestApp\main.o     -mwindows
Output size is 32.17 KB
Process terminated with status 0 (0 minutes, 2 seconds)
0 errors, 1 warnings


When debugging the exe file, I still can't set break point in anywhere in the "dllmain.cpp".
If you have enough time, you could help to test the zip file in that thread. Thanks.
http://forums.codeblocks.org/index.php?action=dlattach;topic=4896.0;attach=1707


correct!  setting break points in the code below works!

Code: [Select]
// a sample exported function
void __declspec(dllexport) MyFunction(const LPCSTR sometext)
{
    /** SET BREAK POINT HERE VVVVVVVVVVV **/
    MessageBoxA(0, sometext, "DLL Message", MB_OK | MB_ICONINFORMATION);
    /** SET BREAK POINT HERE ^^^^^^^^^^^^ **/
}


The breakpoints can't be set in the function of DllMain.



[attachment deleted by admin]
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on January 07, 2009, 07:36:46 pm
The breakpoints can't be set in the function of DllMain.

I can set breakpoints in any of the three functions dllmain.cpp and in MyFunction without problems.
And gdb stops there of course.

g++ is 4.2.1-dw2:
Code: [Select]
C:\Dokumente und Einstellungen\jens>g++ -v
Using built-in specs.
Target: mingw32
Configured with: ../gcc-4.2.1-2-src/configure --with-gcc --enable-libgomp --host=mingw32 --build=mingw32 --target=mingw32 --prog
ram-suffix=-dw2 --with-arch=i486 --with-tune=generic --disable-werror --prefix=/mingw --with-local-prefix=/mingw --enable-thread
s --disable-nls --enable-languages=c,c++,fortran,objc,obj-c++,ada --disable-win32-registry --disable-sjlj-exceptions --enable-li
bstdcxx-debug --enable-cxx-flags=-fno-function-sections -fno-data-sections --enable-version-specific-runtime-libs --disable-boot
strap
Thread model: win32
gcc version 4.2.1-dw2 (mingw32-2)

gdb is 6.7.50 on my XP partition:
Code: [Select]
GNU gdb 6.7.50.20071127
Copyright (C) 2007 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".

Iwill test it with gdb 6.8 on w2k too, this evening.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: MortenMacFly on January 07, 2009, 08:44:56 pm
I can set breakpoints in any of the three functions dllmain.cpp and in MyFunction without problems.
And gdb stops there of course.
For me it still does not work. But I am using the GCC 3.4.5 compiler suite ang GDB 6.6 (otherwise I cannot debug into wx code). It seems an issue with the compiler/debugger version obviously... Oh dear... Should I really finally upgrade my dev frameworks?!
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 08, 2009, 03:39:42 am
It is very interesting, when I renamed the project folder name from "C:\DebugTest" to "C:\DebugTest1".
Then I open the cbp file and debug without rebuild the project. Then the gdb complaint that: (I'm using the TDM-mingw version)

Code: [Select]
Command-line: D:\Program Files\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/TestApp.exe
Working dir : C:\DebugTest1\
> set prompt >>>>>>cb_gdb:
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-pc-mingw32".
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Function "__cxa_throw" not defined in loaded symbols.
>>>>>>cb_gdb:
> show directories
Source directories searched: $cdir;$cwd
>>>>>>cb_gdb:
> directory C:/DebugTest1/
>>>>>>cb_gdb:
> break "C:/DebugTest1/TestApp/main.cpp:26"
No source file named C:/DebugTest1/TestApp/main.cpp in loaded symbols.
Breakpoint 1 ("C:/DebugTest1/TestApp/main.cpp:26) pending.
>>>>>>cb_gdb:

You can see when gdb started, it use the command line:
Code: [Select]
Command-line: D:\Program Files\CodeBlocks\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/TestApp.exe

which has a parameter "-fullname", so I can't set break points in anywhere of the source file. Because the debug information in both exe and DLL file were reference to " C:\DebugTest\***".
As a workaround, I should rebuild the Target.




Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 08, 2009, 02:33:35 pm
Code: [Select]
--- src/plugins/compilergcc/compilerMINGWgenerator.cpp  (revision 5387)
+++ src/plugins/compilergcc/compilerMINGWgenerator.cpp  (working copy)
@@ -36,7 +36,10 @@
     wxString result = CompilerCommandGenerator::SetupIncludeDirs(compiler, target);
     m_VerStr = compiler->GetVersionString();
     wxString pch_prepend;
-    bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+//    bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+    // MinGW TDM 4.3.2-2: http://www.tdragon.net/recentgcc/
+    // compiler->GetVersionString() return is empty string
+    bool IsGcc4 = true;

     // for PCH to work, the very first include dir *must* be the object output dir
     // *only* if PCH is generated in the object output dir
Title: Re: The 06 January 2009 build (5382) is out.
Post by: dje on January 08, 2009, 02:37:27 pm
Code: [Select]
--- src/plugins/compilergcc/compilerMINGWgenerator.cpp  (revision 5387)
+++ src/plugins/compilergcc/compilerMINGWgenerator.cpp  (working copy)
@@ -36,7 +36,10 @@
     wxString result = CompilerCommandGenerator::SetupIncludeDirs(compiler, target);
     m_VerStr = compiler->GetVersionString();
     wxString pch_prepend;
-    bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+//    bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+    // MinGW TDM 4.3.2-2: http://www.tdragon.net/recentgcc/
+    // compiler->GetVersionString() return is empty string
+    bool IsGcc4 = true;

     // for PCH to work, the very first include dir *must* be the object output dir
     // *only* if PCH is generated in the object output dir
Do you think every MinGW user uses TDragon version ?

Dje
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on January 08, 2009, 02:55:54 pm
@Loaden:
please post the output of TDragons MinGW-gcc if called with "--version" on commandline.

EDIT:

No need to post it.
I found the problem and will commit a fix after some testing (most likely this evening).
Title: Re: The 06 January 2009 build (5382) is out.
Post by: thamurath on January 08, 2009, 04:17:36 pm
Hi,

I have a debian etch, i have updated to 5382 revision this morning using jens repositories and i have a little problem: the mouse wheel does not work on editor window, its works however in all other windows so i think it could be related with new scintilla version. Has anybody experienced the same problem?

Thanks in advance.

P.S.: I am from spain so sorry about my english.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Biplab on January 08, 2009, 05:53:57 pm
Code: [Select]
--- src/plugins/compilergcc/compilerMINGWgenerator.cpp  (revision 5387)
+++ src/plugins/compilergcc/compilerMINGWgenerator.cpp  (working copy)
@@ -36,7 +36,10 @@
     wxString result = CompilerCommandGenerator::SetupIncludeDirs(compiler, target);
     m_VerStr = compiler->GetVersionString();
     wxString pch_prepend;
-    bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+//    bool IsGcc4 = m_VerStr.Left(1).IsSameAs(_T("4"));
+    // MinGW TDM 4.3.2-2: http://www.tdragon.net/recentgcc/
+    // compiler->GetVersionString() return is empty string
+    bool IsGcc4 = true;

     // for PCH to work, the very first include dir *must* be the object output dir
     // *only* if PCH is generated in the object output dir

This patch is not necessary. Run the following script at Script Console -

Code: [Select]
ShowInfo(GetCompilerFactory().GetCompilerVersionString(_T("gcc")))
It should show you GCC version no. See following screenshot (showing result in my pc).

(http://img175.imageshack.us/img175/2937/gccverrz9.th.png) (http://img175.imageshack.us/my.php?image=gccverrz9.png)
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 08, 2009, 06:18:19 pm
I can't get the version use script.
and my config:
Code: [Select]
set PATH=%CD%\bin;%PATH%
set CPATH=%CD%\include;%CD%\lib\mingw\mingw32\4.3.2\include;%CD%\lib\mingw\mingw32\4.3.2\include\c++
set LIBRARY_PATH=%CD%\lib;%CD%\lib\mingw\mingw32\4.3.2

[attachment deleted by admin]
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on January 08, 2009, 09:44:12 pm
I can't get the version use script.
and my config:
Code: [Select]
set PATH=%CD%\bin;%PATH%
set CPATH=%CD%\include;%CD%\lib\mingw\mingw32\4.3.2\include;%CD%\lib\mingw\mingw32\4.3.2\include\c++
set LIBRARY_PATH=%CD%\lib;%CD%\lib\mingw\mingw32\4.3.2

If possible, you can try svn r5390 and see if the issue is fixed for you.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 09, 2009, 01:15:22 am
Do you think every MinGW user uses TDragon version ?
Dje
oh. this modify want report this question only.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 09, 2009, 01:18:38 am
If possible, you can try svn r5390 and see if the issue is fixed for you.
thans! I confirm this question exist also.
I can't give MinGW TDM-2's version with r5390.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on January 09, 2009, 07:24:24 am
If possible, you can try svn r5390 and see if the issue is fixed for you.
thans! I confirm this question exist also.
I can't give MinGW TDM-2's version with r5390.
please post the output of the gcc (C- not C++-executable) you have configured in toolchain executables tab, if called with "--version" on commandline.
Please call it with absolute path as configured in the settings:
Code: [Select]
<Compiler's installation directory>\bin\<C compiler> --version
Make sure you have not accidently added "bin" to the "Compiler's installation directory" in the settings !!
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 09, 2009, 08:58:38 am
@jens
I test again. I'm using using svn5382, TDM GCC 4.3.2 GDB 6.8.3.
I set break points in each "case" of DllMain, but it can't work.
Only the break points in "MyFunction" works.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on January 09, 2009, 09:28:55 am
@jens
I test again. I'm using using svn5382, TDM GCC 4.3.2 GDB 6.8.3.
I set break points in each "case" of DllMain, but it can't work.
Only the break points in "MyFunction" works.
Works here, too, but first after adding the declaration to "dllmain.h" and adding dummy code inside the case statements. The dummy code is not necessary to set breakpoint, but the pointer (the yellow triangle) is always on the return statement and you can not see which case statement is used.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 09, 2009, 09:50:52 am
Thanks, it works, setting breaking points in dummy code also works.
so, in the header file:
Code: [Select]
#ifdef __cplusplus
extern "C"
    {
#endif
    void MyFunction(const LPCSTR sometext);
    BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved);
#ifdef __cplusplus
    }
#endif
#endif
After add the dummy code in each case of DllMain.
Code: [Select]
BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved)
{
    static int a = 0;
    switch (fdwReason)
    {
        case DLL_PROCESS_ATTACH:
            // attach to process
            // return FALSE to fail DLL load
            a++;
            break;

        case DLL_PROCESS_DETACH:
            // detach from process
            a++;
            break;

        case DLL_THREAD_ATTACH:
            // attach to thread
            a++;
            break;

        case DLL_THREAD_DETACH:
            // detach from thread
            a++;
            break;
    }
    return TRUE; // succesful
}

I can set break points in the line of "a++", and it works. Thanks.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: gd_on on January 09, 2009, 11:09:03 am
Two small problems concerning translations :

within src/plugins/contrib/wxSmith/wxwidgets/defitems/wxsstatusbar.cpp
Lines 146 and 184 should probably use _("Variable width") instead of _T("Variable width")

within src/src/environmentsettingsdlg.cpp
Line 106, should use : SetLabel(_("Dynamic Data Exchange (needs application restart to take effect)"))

gd_on
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 09, 2009, 01:01:08 pm
please post the output of the gcc (C- not C++-executable) you have configured in toolchain executables tab, if called with "--version" on commandline.
Please call it with absolute path as configured in the settings:
Code: [Select]
<Compiler's installation directory>\bin\<C compiler> --version
Make sure you have not accidently added "bin" to the "Compiler's installation directory" in the settings !!
Please get my Code::Blocks IDE from here: http://www.qpsoft.com/downloads/qpcb.exe
and test it.

[attachment deleted by admin]
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 09, 2009, 02:15:37 pm
@Loaden
In my system (windows XP, Official nightly build svn5382, TDM GCC 4.3.2 GDB 6.8.3. )
It returned the right number "4.3.2", just like Biplab's screenshot.

Your screen shot show  that your use "gcc.exe" instead of "mingw32-gcc.exe", but by default, these values was "mingw32-gcc.exe".

I'm not sure what's the difference between "mingw32-***.exe" and "***.exe"? Thanks.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 09, 2009, 02:55:25 pm
Hi, jens! I think i found the question. the 'Compiler's installation directory' can't support '$(CODEBLOCKS)', when i set this value to 'D:\ycdeng\qpcb\codeblocks\src\devel\bin', it's OK!
I hope you can fix it: not support $(CODEBLOCKS).
thanks!!

[attachment deleted by admin]
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on January 09, 2009, 02:57:15 pm
Hi, jens! I think i found the question. the 'Compiler's installation directory' can't support '$(CODEBLOCKS)', when i set this value to 'D:\ycdeng\qpcb\codeblocks\src\devel\bin', it's OK!
I hope you can fix it: not support $(CODEBLOCKS).
thanks!!

That's what I wanted to write just in the same moment.
Where and how do you set $(CODEBLOCKS) ?
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 09, 2009, 03:13:24 pm
Hi, jens! I think i found the question. the 'Compiler's installation directory' can't support '$(CODEBLOCKS)', when i set this value to 'D:\ycdeng\qpcb\codeblocks\src\devel\bin', it's OK!
I hope you can fix it: not support $(CODEBLOCKS).
thanks!!

That's what I wanted to write just in the same moment.
Where and how do you set $(CODEBLOCKS) ?
(http://forums.codeblocks.org/index.php?action=dlattach;topic=9873.0;attach=2979;image)

because the mingw install path is CB install path.
(http://forums.codeblocks.org/index.php?action=dlattach;topic=9873.0;attach=2983;image)
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on January 09, 2009, 03:15:40 pm
I saw the compiler path in toolchain executables, but I didn't know (until now) that the variable is set automatically to C::B's executable directory when it starts.
Shame on me. :oops:

But I think that can be fixed, too.

Later this afternoon, or in the evening.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 09, 2009, 03:18:14 pm
But I think that can be fixed, too.
Later this afternoon, or in the evening.
Thanks you very much!
Title: Re: The 06 January 2009 build (5382) is out.
Post by: d0c on January 09, 2009, 05:39:31 pm
It seems that you forgot to update the maximum lexer constant in editorcolourset.cpp, making it impossible to use the proper lexer for the D programming language.
Patch for this and lexer_d.xml attached.

EDIT: Sorry, I missed that smart indent depends on the selected lexer. Patch updated

[attachment deleted by admin]
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 10, 2009, 12:53:19 pm
Hi, someone finds a bug in the Toolbar position.
See this thread
http://forums.codeblocks.org/index.php/topic,9890.msg69000.html#msg69000
I have verified that this bug exists in SVN5382.
Thanks.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: JMP on January 10, 2009, 08:26:11 pm
Hi,

I have found that when dragging selected text beyond the actual extent of the editor area, there is not any auto-scroll, so one must drop the dragged selected text only on the visible area of the editor.

I remember, in some previous version of C::B, that auto-scroll worked as expected. Maybe it is because of the new scintilla version?

Regards
Title: Re: The 06 January 2009 build (5382) is out.
Post by: olelukoie on January 10, 2009, 09:07:35 pm
Hi,

I've got a problem compiling C::B as an rpm-package for current development version of Mandriva Linux 2009.1 distribution. I guess the problem is that when building rpm packages this distribution forces the use of GCC option -Werror=format-security and it produces several error messages like this:
Code: [Select]
wiz.cpp: In member function 'void Wiz::CopyFiles(cbProject*, const wxString&, const wxString&)':
wiz.cpp:757: error: format not a string literal and no format arguments
make[4]: *** [wiz.lo] Error 1
make[4]: Leaving directory `/home/olelukoie/rpmbuild/BUILD/codeblocks/src/plugins/scriptedwizard'

Is it possible to fix and make C::B compilable with this option? (As I said there are several other messages of the same error type).
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 11, 2009, 03:25:18 am
Hi,

I have found that when dragging selected text beyond the actual extent of the editor area, there is not any auto-scroll, so one must drop the dragged selected text only on the visible area of the editor.

I remember, in some previous version of C::B, that auto-scroll worked as expected. Maybe it is because of the new scintilla version?

Regards
Verified. I can only drag the text to anywhere in the current view. auto-scroll can't work when dragging. But I don't think it's due to the new scintilla version. I can reproduce the bug in SVN5322.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: JMP on January 14, 2009, 08:45:50 am
Hi,

I also found that code completion toolbar (function location section) does not recognise functions defined in stored opened files(tabs). Only files opened during the current sesion are properly parsed and their functions located.
To reproduce this error, open first a project with multiple files, then open some files in the editor. Check that the code completion toolbar is locating all the functions in the files properly. Then "save everything" and exit C::B. Reopen C::B and select the last project. All opened files of the previous sesion are in the editor, but the code completion toolbar does not show any function.
Open some file of the project that was not already open. Code completion toolbar can locate the functions of this file, but not of the others.

By closing all tabs and opening again the files, code completion toolbar shows the functions properly.

Best regards
JMP
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on January 14, 2009, 11:21:27 am
But I think that can be fixed, too.
Later this afternoon, or in the evening.
Thanks you very much!

Should now also work with environment and global (C::B) variables.

svn r5399
Title: Re: The 06 January 2009 build (5382) is out.
Post by: shurecki on January 15, 2009, 03:41:38 am
if you use slashs in the project name, like 'my/project/name' code blocks will create the folder name/my/project/name and creates the project there

and if you project's name ends with a slash it is stranger, it creates a '.cbp' foder and a '.cbp' project file

is this a bug?
Title: Re: The 06 January 2009 build (5382) is out.
Post by: dje on January 15, 2009, 09:46:31 am
Well,

project name is used for file names.
At least on windows, there is a list of forbidden chars in filenames such as:\/:*?"<>|
So if you think it is a bug, let's write to M$ :)

Dje
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Grom on January 15, 2009, 11:01:25 pm
What about new components in wxSmith? Would be grate to have all of then inside. With full paletter it might become a real development toolkit. Also would be grate to have a menue, status bar and toolbar on the devlopment window.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: shurecki on January 16, 2009, 01:40:17 am
Well,

project name is used for file names.
At least on windows, there is a list of forbidden chars in filenames such as:\/:*?"<>|
So if you think it is a bug, let's write to M$ :)

Dje

it happens on linux to
I think one solution could be just replace the slash, or whatever forbidden char, by some other char, like dash
Title: Re: The 06 January 2009 build (5382) is out.
Post by: mmkider on January 16, 2009, 04:45:27 am
Crash Report 
Code: [Select]
-------------------

Error occured on Friday, January 16, 2009 at 11:24:16.

D:\CB_Pack\codeblocks\codeblocks.exe caused an Access Violation at location 619f37e7 in module D:\CB_Pack\codeblocks\codeblocks.dll Writing to location 7c9106ab.

Registers:
eax=7c9106ab ebx=079eff00 ecx=00000000 edx=7c910732 esi=0000001f edi=060186f8
eip=619f37e7 esp=079efdd0 ebp=079efdd0 iopl=0         nv up ei pl nz ac pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010212

Call stack:
619F37E7  D:\CB_Pack\codeblocks\codeblocks.dll:619F37E7  _Z11DumpLiteralR11SQObjectPtr
617FF8EC  D:\CB_Pack\codeblocks\codeblocks.dll:617FF8EC  _ZN12cbThreadPool11GetNextTaskEv
618010B4  D:\CB_Pack\codeblocks\codeblocks.dll:618010B4  _ZN12cbThreadPool14cbWorkerThread5EntryEv
100A2FFD  D:\CB_Pack\codeblocks\wxbase28u_gcc_cb.dll:100A2FFD  _Z22wxMutexGuiLeaveOrEnterv
100A3476  D:\CB_Pack\codeblocks\wxbase28u_gcc_cb.dll:100A3476  _ZN8wxThreadD1Ev
77C3A3B0  C:\WINDOWS\system32\msvcrt.dll:77C3A3B0  _endthreadex
7C80B50B  C:\WINDOWS\system32\kernel32.dll:7C80B50B  GetModuleFileNameA
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 16, 2009, 10:24:17 am
Should now also work with environment and global (C::B) variables.
svn r5399
It's OK!, thanks!
Title: Re: The 06 January 2009 build (5382) is out.
Post by: stahta01 on January 16, 2009, 07:52:31 pm
Patch needed for Windows NON-PCH building of C::B main project.

Tim S

Code: [Select]
Index: src/sdk/macrosmanager.cpp
===================================================================
--- src/sdk/macrosmanager.cpp (revision 5406)
+++ src/sdk/macrosmanager.cpp (working copy)
@@ -12,6 +12,7 @@
 #ifndef CB_PRECOMP
     #include <wx/menu.h>
 
+    #include "cbworkspace.h"
     #include "projectmanager.h"
     #include "editormanager.h"
     #include "logmanager.h"
Index: src/plugins/compilergcc/compilerMINGW.cpp
===================================================================
--- src/plugins/compilergcc/compilerMINGW.cpp (revision 5406)
+++ src/plugins/compilergcc/compilerMINGW.cpp (working copy)
@@ -18,6 +18,7 @@
 #include <wx/filename.h>
 #include <wx/filefn.h>
 #include "manager.h"
+#include "macrosmanager.h"
 #include "logmanager.h"
 #include "compilerMINGWgenerator.h"
 
Title: Re: The 06 January 2009 build (5382) is out.
Post by: killerbot on January 17, 2009, 09:37:40 am
done
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 17, 2009, 02:16:48 pm
There are two bugs I found. (windows)

First bug:
Using gdb with "setting->debugger setting->Evaluate expression under cursor" enabled.

Then If I select a piece of code by drag mouse, then GDB complainted that "what is XXXXXXXXXXX....." and crashed. (which can be seem from the debugger log output window). I think the reason is that these select statements are too complex for GDB to evaluate. :(

Second bug:
thread search window.
See the screen shot below, The "keyword" control will be truncated if I reduce the length of this window. It is not convenient for a user with small screen resolution.
(http://forums.codeblocks.org/index.php?action=dlattach;topic=9873.0;attach=3036)







[attachment deleted by admin]
Title: Re: The 06 January 2009 build (5382) is out.
Post by: dje on January 17, 2009, 04:17:59 pm
Hi Ollydbg

Concerning ThreadSearch limitation, I already saw it but I didn't find any good solution to solve it.
If that's annoying for you, you can hide the controls panel and use the the ThreadSearch toolbar that is very small.
The check box to uncheck in settings dialog is "Show search widgets in ThreadSearch Messages panel".

Dje


Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on January 18, 2009, 01:08:59 am
Thank you for the hint.
That's a workaround.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: afb on January 18, 2009, 10:55:26 am
- Mac OS X:
  http://prdownload.berlios.de/codeblocks/CB_20090106_rev5382_mac289.zip

Just the baseline, so no fixes to project templates wrt linking or anything...
The Universal Binary is built for Tiger, but should work on Leopard as well.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 25, 2009, 11:47:34 am
svn build rev 5416 (2009-01-22T08:26:41.171594Z) gcc 4.3.2 Windows/unicode

Can't edit this config, when i double click it, it's show nothing:

[attachment deleted by admin]
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Loaden on January 29, 2009, 03:24:38 pm
Please let's CodeCompletion support sort:
Code: [Select]
Index: plugins/codecompletion/codecompletion.cpp

===================================================================

--- plugins/codecompletion/codecompletion.cpp (revision 5422)

+++ plugins/codecompletion/codecompletion.cpp (working copy)

@@ -935,6 +935,8 @@

         return -5;
     }
 
+    arr.Sort();
+
     // select tokens
     MultiSelectDlg dlg(Manager::Get()->GetAppWindow(), arr, true);
     if (dlg.ShowModal() == wxID_OK)
Title: Re: The 06 January 2009 build (5382) is out.
Post by: MortenMacFly on January 29, 2009, 10:06:06 pm
Please let's CodeCompletion support sort:
Don't you worry... we are already testing a patch that will enable way more than "just" sorting... ;-)
Title: Re: The 06 January 2009 build (5382) is out.
Post by: hying on February 01, 2009, 03:47:21 am
a bug
code:
template <typename X>
int Bugtest(X _x)
{
    return sizeof(_x);          //set breakpoint here
}
int main()
{
    int t_ix = 1;
    cout << Bugtest(t_ix) << endl;
    char t_cx = '0';
    cout << Bugtest(t_cx) << endl;
    return 0;
}
on first break, open zhe disassembly window, can find the asm code like:
00417758   push   ebp
00417759   mov    ebp,esp
0041775B   mov    eax,0x4
00417760   leave
00417761   ret
current eip is 41775b

continue,
on second break, the current eip is 417750, but the disassembly window show the asm code is same as the first,
can't find the current asm code.

my english is pool, sorry
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on February 01, 2009, 12:36:42 pm
It seems that there's something wrong in the editor. I have reported in the thread. Some files can't be opened.
http://forums.codeblocks.org/index.php/topic,9986.0.html
Thank you very much.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on February 01, 2009, 12:48:01 pm
a bug
code:
template <typename X>
int Bugtest(X _x)
{
    return sizeof(_x);          //set breakpoint here
}
int main()
{
    int t_ix = 1;
    cout << Bugtest(t_ix) << endl;
    char t_cx = '0';
    cout << Bugtest(t_cx) << endl;
    return 0;
}
on first break, open zhe disassembly window, can find the asm code like:
00417758   push   ebp
00417759   mov    ebp,esp
0041775B   mov    eax,0x4
00417760   leave
00417761   ret
current eip is 41775b

continue,
on second break, the current eip is 417750, but the disassembly window show the asm code is same as the first,
can't find the current asm code.

my english is pool, sorry
I tested it, but there's no problem.

In first break, the disassembly code is like below:
Code: [Select]
00417758 push   ebp
00417759 mov    ebp,esp
0041775B mov    eax,0x4
00417760 leave
00417761 ret

In second break, the disassembly code is like below:
Code: [Select]
00417744 push   ebp
00417745 mov    ebp,esp
00417747 sub    esp,0x4
0041774A mov    eax,DWORD PTR [ebp+0x8]
0041774D mov    BYTE PTR [ebp-0x4],al
00417750 mov    eax,0x1
00417755 leave
00417756 ret

So, it works fine in my computer.  I'm using TDM-mingw.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on February 01, 2009, 04:06:10 pm
Bug report:
windows XP.
Each time I double click on an entry in the "Symbols tree", It will always go the "variables node". See the screen cast here:

http://sites.google.com/site/studycodeblocks/Home/bug1.swf

I think it shouldn't be changed.
Thanks.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: killerbot on February 01, 2009, 07:41:04 pm
planning on creating a new nightly tomorrow.

@developers : any commits you want in, now is the time ;-)
Title: Re: The 06 January 2009 build (5382) is out.
Post by: MortenMacFly on February 01, 2009, 08:12:28 pm
http://sites.google.com/site/studycodeblocks/Home/bug1.swf
Can't view... all I see is an empty page with the word "CodeBlocks"...?!
Mind posting a simple step-by-step instruction how to reproduce?
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on February 02, 2009, 02:44:45 am
http://sites.google.com/site/studycodeblocks/Home/bug1.swf
Can't view... all I see is an empty page with the word "CodeBlocks"...?!
Mind posting a simple step-by-step instruction how to reproduce?
I can view this flash video in both IE and Firefox under windows XP.
If you can't view that video, you can see two pictures.

When I double click on an "function entry" in "symbols panel" (First image).
(http://forums.codeblocks.org/index.php?action=dlattach;topic=9873.0;attach=3097)
the structure tree will automatically go to "variables" (Second image). Furthermore, If this window receive a "WM_PAINT" message to repaint itself, it will change to "variables".
(http://forums.codeblocks.org/index.php?action=dlattach;topic=9873.0;attach=3099)

Sorry for my poor English expression. :D







[attachment deleted by admin]
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Saswat2603 on February 02, 2009, 03:59:57 am
http://sites.google.com/site/studycodeblocks/Home/bug1.swf
Can't view... all I see is an empty page with the word "CodeBlocks"...?!
Mind posting a simple step-by-step instruction how to reproduce?

In firefox, when you click the provided link, it automatically redirects to :
http://sites.google.com/site/studycodeblocks/Home/bug1.swf?attredirects=0

In your browser address bar, remove the "?attredirects=0" suffix and then you can view the swf file.

Alternatively, visit the following link for the same :
http://2670631209710576974-a-1802744773732722657-s-sites.googlegroups.com/site/studycodeblocks/Home/bug1.swf?attredirects=0&auth=ANoY7cqP_pyou6_Xmc1Gyuq4ZTCqKTf4PsqREQSb1HKEtnpIJyIT5zz7-AuwT94W09z9MbRcd1TFkkmoHzlwiAH1UYDocw0cHZhoPml_qUhCVdeuxzDCmmT29cY-QxUCZSkdiOi3CXNFiHd0DL6iDpOUglI5yrlP_2i96scBzQw7KmtaIMoizlwKGWm4qe6sOvcPoqlH63XwT5abwOIQ0nKsAh5Xic_f0g%3D%3D

PLEASE DO NOT TRY TO CLICK THE ABOVE LINK. JUST COPY IT AND PASTE IT IN YOUR ADDRESS BAR.

I don't know why clicking does not work ! May be browsers trim the url !!
Title: Re: The 06 January 2009 build (5382) is out.
Post by: hying on February 02, 2009, 04:07:05 am
to ollydbg

in a VM xp, i install C::B 8.02, build that code, find the disassembly bug.
i install 5382 patch, rebuild that code, debug it, find the bug exist,
i download  [tdm-mingw-1.812.0-f1.exe] (23.8 MB), and install in C:\Program Files\CodeBlocks\MinGW, the bug still exist.
i don't know what is difference your C::B.

Debugger name and version: GNU gdb 6.8

[attachment deleted by admin]
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on February 02, 2009, 04:40:54 am
to ollydbg

in a VM xp, i install C::B 8.02, build that code, find the disassembly bug.
i install 5382 patch, rebuild that code, debug it, find the bug exist,
i download  [tdm-mingw-1.812.0-f1.exe] (23.8 MB), and install in C:\Program Files\CodeBlocks\MinGW, the bug still exist.
i don't know what is difference your C::B.

Debugger name and version: GNU gdb 6.8

what does VM xp mean?
It works Ok in my system. see the two images below:
I use the same environment as you stated.


[attachment deleted by admin]
Title: Re: The 06 January 2009 build (5382) is out.
Post by: hying on February 02, 2009, 04:44:33 am
xp install in VMware Workstation.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: MortenMacFly on February 02, 2009, 09:32:14 am
http://2670631209710576974-a-1802744773732722657-s-sites.googlegroups.com/site/studycodeblocks/Home/bug1.swf?attredirects=0&auth=ANoY7cqP_pyou6_Xmc1Gyuq4ZTCqKTf4PsqREQSb1HKEtnpIJyIT5zz7-AuwT94W09z9MbRcd1TFkkmoHzlwiAH1UYDocw0cHZhoPml_qUhCVdeuxzDCmmT29cY-QxUCZSkdiOi3CXNFiHd0DL6iDpOUglI5yrlP_2i96scBzQw7KmtaIMoizlwKGWm4qe6sOvcPoqlH63XwT5abwOIQ0nKsAh5Xic_f0g%3D%3D
I will for sure not click / open a cryptic link like that.
Please: Write a step-by-step instruction if you want help.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Saswat2603 on February 02, 2009, 01:34:49 pm
@ MortenMacFly

http://2670631209710576974-a-1802744773732722657-s-sites.googlegroups.com/site/studycodeblocks/Home/bug1.swf?attredirects=0&auth=ANoY7cqP_pyou6_Xmc1Gyuq4ZTCqKTf4PsqREQSb1HKEtnpIJyIT5zz7-AuwT94W09z9MbRcd1TFkkmoHzlwiAH1UYDocw0cHZhoPml_qUhCVdeuxzDCmmT29cY-QxUCZSkdiOi3CXNFiHd0DL6iDpOUglI5yrlP_2i96scBzQw7KmtaIMoizlwKGWm4qe6sOvcPoqlH63XwT5abwOIQ0nKsAh5Xic_f0g%3D%3D
I will for sure not click / open a cryptic link like that.
Please: Write a step-by-step instruction if you want help.

It's nothing CRYPTIC !!! It's the same link as ollydbg mentioned about the SWF file ::
Bug report:
windows XP.
Each time I double click on an entry in the "Symbols tree", It will always go the "variables node". See the screen cast here:

http://sites.google.com/site/studycodeblocks/Home/bug1.swf

I think it shouldn't be changed.
Thanks.

The cryptic URL is the actual location of the file ( i guess ! ).
Because, when you goto http://sites.google.com/site/studycodeblocks/Home/bug1.swf, you actually get redirected to http://sites.google.com/site/studycodeblocks/Home/bug1.swf?attredirects=0 and you see the blank code-blocks page.
When you remove the suffix "?attredirects=0" in the addressbar and <enter>, you visit the cryptic URL and the SWF file then starts playing !!

If you hate the cryptic URL, try removing the "?attredirects=0" after visiting the page and you can see the file.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: reptils on February 02, 2009, 03:30:49 pm
Hi,
I'm not sure it is the good place to ask for a new feature, but I try here.
Is possible to have a vertical spited view (as it is implemented) but with two different files. With the rise of wide screen (24" and 30"), it is easy to have at least now two files to edit at the same time, and it would be helpful.
This feature exist in the Eclipse EDI.

regards.

EDIT: Sorry, I've just seen that this question have been posted in the Development forum.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on February 02, 2009, 03:38:48 pm
Hi,
I'm not sure it is the good place to ask for a new feature, but I try here.
Is possible to have a vertical spited view (as it is implemented) but with two different files. With the rise of wide screen (24" and 30"), it is easy to have at least now two files to edit at the same time, and it would be helpful.
This feature exist in the Eclipse EDI.

regards.

This feature will come (soon ?), we are still testing a patch that make it available.
But as any greater changes it has to be tested thoroughly and some minor issues have to be fixed, to make it work reliable.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: reptils on February 02, 2009, 03:47:08 pm
Thank you for your quick reply  :)
As I said in the "EDIT" part of my reply, I have seen in the "Development" forum, the topic associated to this feature. It is understandable it need to be tested.
I think this feature will be very very helpful, particularly for people who works with a large wide screen.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: Biplab on February 02, 2009, 05:20:26 pm
planning on creating a new nightly tomorrow.

@developers : any commits you want in, now is the time ;-)

Just added an important update. Hope this comes out in the next nightly.

I've added the following 2 options to make default encoding option clearer to user.

(http://img407.imageshack.us/img407/772/newencoptjz6.png)

Previous behaviour was broken as it used to fallback to System encoding on Windows and to UTF-8 on Linux/Mac. This behaviour was not consistent with the option.

I hope with this commit things will be much clear to choose. :)

Title: Re: The 06 January 2009 build (5382) is out.
Post by: killerbot on February 02, 2009, 06:57:31 pm
it will be in. just finished the build :-)
Title: Re: The 06 January 2009 build (5382) is out.
Post by: hying on February 03, 2009, 03:48:39 am
to ollydbg:
i look the debug log like below:
----------------------------------
.....
>>>>>>cb_gdb:
> bt 30
#0  Bugtest<int> (_x=1) at E:\program\bugtest\main.cpp:7
#1  0x004013ce in main () at E:\program\bugtest\main.cpp:13
>>>>>>cb_gdb:
> info frame
Stack level 0, frame at 0x22ff4c:
 eip = 0x41775b in int Bugtest<int>(int) (E:\program\bugtest\main.cpp:7); saved eip 0x4013ce
 called by frame at 0x22ff70
 source language c++.
 Arglist at 0x22ff44, args: _x=1
 Locals at 0x22ff44, Previous frame's sp is 0x22ff4c
 Saved registers:
  ebp at 0x22ff44, eip at 0x22ff48
>>>>>>cb_gdb:
> x/32xb 0x0
Cannot access memory at address 0x0
0x0:   >>>>>>cb_gdb:
> info threads
* 1 thread 2100.0xa98  Bugtest<int> (_x=1) at E:\program\bugtest\main.cpp:7
>>>>>>cb_gdb:
> disassemble
Dump of assembler code for function _Z7BugtestIiEiT_:
0x00417758 <int Bugtest<int>(int)+0>:   push   ebp
0x00417759 <int Bugtest<int>(int)+1>:   mov    ebp,esp
0x0041775b <int Bugtest<int>(int)+3>:   mov    eax,0x4
0x00417760 <int Bugtest<int>(int)+8>:   leave 
0x00417761 <int Bugtest<int>(int)+9>:   ret   
End of assembler dump.
>>>>>>cb_gdb:
> cont
Breakpoint 2, Bugtest<char> (_x=48 '0') at E:\program\bugtest\main.cpp:7
P:/bugtest/main.cpp:7:90:beg:0x417750
>>>>>>cb_gdb:
> info locals
No locals.
>>>>>>cb_gdb:
> info args
_x = 48 '0'
>>>>>>cb_gdb:
> info registers
eax            0x30   48
ecx            0x0   0
edx            0x0   0
ebx            0x7ffda000   2147328000
esp            0x22ff40   0x22ff40
ebp            0x22ff44   0x22ff44
esi            0x16   22
edi            0x20   32
eip            0x417750   0x417750 <int Bugtest<char>(char)+12>
eflags         0x202   [ IF ]
cs             0x1b   27
ss             0x23   35
ds             0x23   35
es             0x23   35
fs             0x3b   59
gs             0x0   0
>>>>>>cb_gdb:
> bt 30
#0  Bugtest<char> (_x=48 '0') at E:\program\bugtest\main.cpp:7
#1  0x00401401 in main () at E:\program\bugtest\main.cpp:15
>>>>>>cb_gdb:
> info frame
Stack level 0, frame at 0x22ff4c:
 eip = 0x417750 in int Bugtest<char>(char) (E:\program\bugtest\main.cpp:7); saved eip 0x401401
 called by frame at 0x22ff70
 source language c++.
 Arglist at 0x22ff44, args: _x=48 '0'
 Locals at 0x22ff44, Previous frame's sp is 0x22ff4c
 Saved registers:
  ebp at 0x22ff44, eip at 0x22ff48
>>>>>>cb_gdb:
> x/32xb 0x0
Cannot access memory at address 0x0
0x0:   >>>>>>cb_gdb:
> info threads
* 1 thread 2100.0xa98  Bugtest<char> (_x=48 '0') at E:\program\bugtest\main.cpp:7
>>>>>>cb_gdb:
----------------------------------------------------------------
at second breakpoint, no run zhe disassemble cmd,
if i send the cmd to GDB, can see the log:
> disassemble
Dump of assembler code for function _Z7BugtestIcEiT_:
0x00417744 <int Bugtest<char>(char)+0>:   push   ebp
0x00417745 <int Bugtest<char>(char)+1>:   mov    ebp,esp
0x00417747 <int Bugtest<char>(char)+3>:   sub    esp,0x4
0x0041774a <int Bugtest<char>(char)+6>:   mov    eax,DWORD PTR [ebp+0x8]
0x0041774d <int Bugtest<char>(char)+9>:   mov    BYTE PTR [ebp-0x4],al
0x00417750 <int Bugtest<char>(char)+12>:   mov    eax,0x1
0x00417755 <int Bugtest<char>(char)+17>:   leave 
0x00417756 <int Bugtest<char>(char)+18>:   ret   
End of assembler dump.
>>>>>>cb_gdb:
--------------------------------------------------
i don't know why the disassemble cmd not autorun
Title: Re: The 06 January 2009 build (5382) is out.
Post by: jens on February 03, 2009, 07:34:13 am
@hying

I can confirm this bug (dissassemble command seems to be not send to debug).

It only happens, if I reach the breakpoint the first time and then step over it with "continue" ("STRG+F7" or "F8"), that means if the actual and the former breakpoint are at the same line in source-code. If I step over the breakpoint ("F7") and leave the source-code line, the next hit sends the dissassemble command.

Can you please file a bug-report at berlios, so it can't be lost ?
Title: Re: The 06 January 2009 build (5382) is out.
Post by: hying on February 03, 2009, 08:22:16 am
thank jens
my english is very pool, and i am a beginner, i don't know how to send the bug-report to berlios, sorry.
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on February 06, 2009, 01:50:36 pm
thank jens
my english is very pool, and i am a beginner, i don't know how to send the bug-report to berlios, sorry.

I submit this bug report. see here:
https://developer.berlios.de/bugs/?func=detailbug&bug_id=15209&group_id=5358
Title: Re: The 06 January 2009 build (5382) is out.
Post by: ollydbg on February 06, 2009, 02:33:17 pm
I also filed a bug (https://developer.berlios.de/bugs/?func=detailbug&bug_id=15210&group_id=5358) reporting the incorrect change of "symbols" panel we discussed before in this post (http://forums.codeblocks.org/index.php/topic,9873.msg69760.html#msg69760)