Author Topic: Debugger  (Read 8833 times)

Offline Hans-Linux

  • Multiple posting newcomer
  • *
  • Posts: 10
Debugger
« on: February 02, 2012, 02:22:31 pm »
I downloaded and installed "Codeblocks-10.05mingw-setup.exe" on a Windows 7 virtual machine. (Code::Blocks Release 10.5 rev. 6283) from
http://sourceforge.net/projects/codeblocks/files/Binaries/10.05/Windows/codeblocks-10.05mingw-setup.exe

The debugger stops at set breakpoints but does not show the little caret and does not switch source files when single stepping through the source code with 'F7' and 'Shift F7'. This is very annoying.

I unsuccessfully tried to install the latest nightly build. 

I am using Code::Blocks for some time on 32 and 64 bit Linux virtual machines.

Is this a configuration problem or a bug? 

Hans

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6077
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger
« Reply #1 on: February 02, 2012, 02:53:41 pm »
The debugger stops at set breakpoints but does not show the little caret and does not switch source files when single stepping through the source code with 'F7' and 'Shift F7'. This is very annoying.
1, try a more recent codeblock nightly build version in our forum: Nightly builds to see whether it works OK. I also suggest you to use a more recent mingw package, such as: tdm gcc: TDM - GCC

2, Or, you can tell us how to reproduce this issue, we need code snippet and step by step instructions to reproduce your issue.
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: 13406
    • Travis build status
Re: Debugger
« Reply #2 on: February 02, 2012, 02:56:06 pm »
2, Or, you can tell us how to reproduce this issue, we need code snippet and step by step instructions to reproduce your issue.
In fact we need this only if this bug is happening with the latest debugger's branch nightly. Otherwise it is a known problem with 10.05 or trunk.
(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 Hans-Linux

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Debugger
« Reply #3 on: February 02, 2012, 03:30:29 pm »
I tried installing  the last nightly build and tdm gcc. There where other issues involving the Linux project I want to build. This project builds and runs error free on 32 & 64 bit Linux and builds fine with "Codeblocks-10.05mingw-setup.exe".  Just needs some Windows specific fixes relating to drive letter, linked files and large files.    

This is the test code:

main.c:
#include <stdio.h>
#include <stdlib.h>

int sub(void);

int main(int argc, char** argv)
{
int ret;

    ret = 99; /*Set beak point here,
                    then single step with 'F7' & 'Shift F7')*/
    printf("I am in main.c!\n");
    ret = sub();
    printf("I am back in main.c!\n");
    return 0;
}
------------------------
sub.c:
#include <stdio.h>
#include <stdlib.h>

int sub(void);

int sub(void)
{
int ret = 1;

   printf("I am in sub.c!\n");
   ret = 0;
   return ret;
}

After installing and updating to the latest MinGW version I get this Debug Output:

PATH=.;Y:\MinGW\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\
Command-line: Y:\MinGW\bin\gdb.exe -nx -fullname  -quiet -args bin/Debug/Test.exe
Working dir : Y:\Test\
> set prompt >>>>>>cb_gdb:
Reading symbols from y:\test\bin\debug\Test.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 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 "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>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 new-console on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Function "__cxa_throw" not defined.
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source Y:\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory Y:/Test/
>>>>>>cb_gdb:
> break "Y:/Test/sub.c:10"
Breakpoint 2 at 0x4013c4: file Y:\Test\sub.c, line 10.
>>>>>>cb_gdb:
> break "Y:/Test/main.c:10"
Breakpoint 3 at 0x401415: file Y:\Test\main.c, line 10.
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 312.0x71c]
Line number 10 out of range; Y:\Test\main.c has 1 lines.
Breakpoint 3, main (argc=1, argv=0x601088) at Y:\Test\main.c:10
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> next
Line number 12 out of range; Y:\Test\main.c has 1 lines.
>>>>>>cb_gdb:
> whatis argv
type = char **
>>>>>>cb_gdb:
> output argv
(char **) 0x601088>>>>>>cb_gdb:
> output argv
(char **) 0x601088>>>>>>cb_gdb:
> next
Line number 13 out of range; Y:\Test\main.c has 1 lines.
>>>>>>cb_gdb:
> step
Line number 8 out of range; Y:\Test\sub.c has 1 lines.
sub () at Y:\Test\sub.c:8
>>>>>>cb_gdb:
> next
Line number 10 out of range; Y:\Test\sub.c has 1 lines.
Breakpoint 2, sub () at Y:\Test\sub.c:10
>>>>>>cb_gdb:
> next
Line number 11 out of range; Y:\Test\sub.c has 1 lines.
>>>>>>cb_gdb:
> next
Line number 12 out of range; Y:\Test\sub.c has 1 lines.
>>>>>>cb_gdb:
> next
Line number 13 out of range; Y:\Test\sub.c has 1 lines.
>>>>>>cb_gdb:
> next
Line number 14 out of range; Y:\Test\main.c has 1 lines.
main (argc=1, argv=0x601088) at Y:\Test\main.c:14
>>>>>>cb_gdb:
> next
Line number 15 out of range; Y:\Test\main.c has 1 lines.
>>>>>>cb_gdb:
> next
Line number 16 out of range; Y:\Test\main.c has 1 lines.
>>>>>>cb_gdb:
> next
250   ../mingw/crt1.c: No such file or directory.
__mingw_CRTStartup () at ../mingw/crt1.c:250
   in ../mingw/crt1.c
>>>>>>cb_gdb:

It appears that the source file line numbers are somewhere screwed up.

Hans
« Last Edit: February 03, 2012, 01:48:22 am by Hans-Linux »

Offline Hans-Linux

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Debugger, SOLVED
« Reply #4 on: February 03, 2012, 03:18:07 pm »
Problem solved:

Code::Blocks for Windows source files must have a CR/LF line ending.

Settings -> Editor -> End of line options -> tick 'Ensure consistent EOL's' and set 'End-of-line mode' to CR/LF.

When using source files from a Linux or Mac project with CR or LF line ending, modify each source file before re-compiling.

Hans

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 6077
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Debugger, SOLVED
« Reply #5 on: February 03, 2012, 03:29:48 pm »
Problem solved:

Code::Blocks for Windows source files must have a CR/LF line ending.

Settings -> Editor -> End of line options -> tick 'Ensure consistent EOL's' and set 'End-of-line mode' to CR/LF.

When using source files from a Linux or Mac project with CR or LF line ending, modify each source file before re-compiling.

Hans
That's not true, I test your code in either CR LF(Windows style) or LF(Linux style), and both cases the debugger works fine. (winXp, MinGW4.6.x, mingw_gdb cvs version)
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 Hans-Linux

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: Debugger
« Reply #6 on: February 05, 2012, 04:03:30 pm »
The problem may be caused because of my setup.

I use Code::Blocks on 32 and 64 bit Open Suse 11.3,  and Windows 7 and Windows 2000 on Oracle virtual machines.  The source files are created and stored on the Linux 64 bit system in a shared directory with UTF-8 encoding and LF line ending.

The windows systems use Windows-1252 encoding and CR/LF line ending. The files are not converted from UTF-8 and LF to Windows-1252 and CR/LF when loaded. They are converted when modified and saved.

I have not noticed any problem on the Linux systems after source files have been modified and converted on the Windows systems to Windows-1252 and CR/LF.

I previously used MS Visual Studio 10 without this problem. They bring up a window asking whether the files should be converted. Maybe Code::Blocks can in the future implement something like this.

Hans
« Last Edit: February 05, 2012, 04:05:04 pm by Hans-Linux »