Author Topic: Problem with Debugger when upgrading MinGW  (Read 26063 times)

Offline recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Problem with Debugger when upgrading MinGW
« on: February 10, 2011, 01:46:19 am »
I decided to try one of the nightlies (svn 6931) instead of the 10.05/MinGW package I have been using.  I installed MinGW from http://sourceforge.net/projects/mingw/files/ using mingw-get-inst-20101030.exe, and put it in a C:\ root folder.  I also renamed the MinGW folder in the Codeblocks Program Files folder, and changed my path statement to reflect the new location.  I also updated the CB toolchain executable, which, with auto-detect, found the new location.

Next, I cleaned my project and rebuilt it.  I was able to start the debugger, and it showed the new version number.  I can even set breakpoints.  However, when it stops at some of the breakpoints (nothing fancy or inline), I cannot single step, as I get an error message about accessing a memory address:
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.2
Child process PID: 3348
....
At E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp:239
Error accessing memory address 0x7816cd30: Input/output error.


And I am not able to get any useful debugging after that.

So then I changed the name of the C:\mingw root folder, restored the original name of the Code Blocks\MinGW folder, changed the path statement back to the original, and updated the toolchain executable location again.  Once again, clean and rebuild.  At the same point that I could not debug with the 7.2 version of gdb I was able to with the older 6.8 version.  I also checked between the svn and 10.05 version, and there is no problem there - that is, the debugger works in both versions with the older version of MinGW, but not the newer version.

I do get an error message with the older version, but it does not seem to impact on functionality (i.e., breakpoints, stepping, watches, etc all seem to work OK):
Setting breakpoints
Debugger name and version: GNU gdb 6.8
Child process PID: 764
Error while mapping shared library sections:

I don't know how long that error has been there, I never paid much attention to the debugger log when everything seemed to be working.

I'm pretty much a newbie at all this - I could just go back to the canned package and use that, but I'd like to learn to play in the sand box with the bigger boys  :(

Here's some version info from the two versions:

Code: [Select]
---------------------------------------------------
C:\Program Files (x86)\CodeBlocks\MinGW\bin>gcc --version
gcc (TDM-2 mingw32) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


C:\Program Files (x86)\CodeBlocks\MinGW\bin>gdb --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".
-------------------------------------------
C:\MinGW\bin>gcc --version
gcc (GCC) 4.5.0
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


C:\MinGW\bin>gdb --version
GNU gdb (GDB) 7.2
Copyright (C) 2010 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/>.
-----------------------------------------------

Thanks for any help/pointers.

Richard
« Last Edit: February 11, 2011, 12:59:44 am by recobb »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #1 on: February 10, 2011, 04:43:21 am »
Quote
Error accessing memory address 0x7816cd30: Input/output error.
I meet this kind of warning even with latest gdb(build under msys+mingw myself).

But once I rebuild the project, these error was gone. :D

can you supply a test case??
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #2 on: February 10, 2011, 04:54:48 am »
More info - I tried the tdm version ( from http://tdm-gcc.tdragon.net/ ) and have the same single-stepping problem.
Debugger name and version: GNU gdb (GDB) 7.1
Child process PID: 4012
Error while mapping shared library sections:
At E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp:239
Error accessing memory address 0x7816cd30: Input/output error.
Error accessing memory address 0x78594458: Input/output error.


I found that I can put breakpoints every few lines, and it will run to the next breakpoint and stop, but the single-stepping gives me the errors.  When it stops at the breakpoints it seems that I can inspect watch variables.

To ollydbg, at this point it is difficult to provide a test case unless I send the entire project.  I haven't tried the newer debugger with any other projects yet.  I'll dig around and see if I can create the same problem in something simple - probably be tomorrow at this point, though.  Thanks...

Richard

Offline recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #3 on: February 10, 2011, 04:18:36 pm »
It's proving harder to come up with a demo case than I thought.  Single stepping in the debugger works fine for all my small projects, no matter which version of MinGW I'm using.  It's only in a larger, multiple-file project that I have problems, and then not at all points.  At some points, early in the program execution, single stepping will work, then start giving me the accessing memory errors at some later point.  The points at which it will, or will not work seem to be consistent within a program, whether I'm using the TDM version (gdb version 7.1) or the download from the MinGW site (gdb v 7.2).  With the 6.8 version packaged with CB 10.05 single stepping works at the same points.

I have used both Rebuild and Clean followed by Build to make sure all files are compiled by the same version.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11770
    • Travis build status
Re: Problem with Debugger when upgrading MinGW
« Reply #4 on: February 10, 2011, 11:03:26 pm »
Read this: http://wiki.codeblocks.org/index.php?title=FAQ#Q:_How_do_I_troubleshoot_an_compiler_problem.3F

And enable full logging. Then verify that c::b executes the correct commands (-g should be used everywhere).
(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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #5 on: February 11, 2011, 12:29:53 am »
Read this: http://wiki.codeblocks.org/index.php?title=FAQ#Q:_How_do_I_troubleshoot_an_compiler_problem.3F

And enable full logging. Then verify that c::b executes the correct commands (-g should be used everywhere).

Thanks for the reply.  I already had logging enabled:
Code: [Select]
-------------- Clean: Debug in wxRCPlot DataObject ---------------

Cleaned "wxRCPlot DataObject - Debug"

-------------- Build: Debug in wxRCPlot DataObject ---------------

mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\AboutDialog.cpp -o winobj\Debug\AboutDialog.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\AutoscaleAsk.cpp -o winobj\Debug\AutoscaleAsk.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\CursorWin.cpp -o winobj\Debug\CursorWin.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\DataDialog_2.cpp -o winobj\Debug\DataDialog_2.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\PolarDialog.cpp -o winobj\Debug\PolarDialog.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\RCScale.cpp -o winobj\Debug\RCScale.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\Resolution.cpp -o winobj\Debug\Resolution.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\Summary.cpp -o winobj\Debug\Summary.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\TitleAxis.cpp -o winobj\Debug\TitleAxis.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\WriteASCII.cpp -o winobj\Debug\WriteASCII.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp -o winobj\Debug\dataclass.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\wxrcgwin.cpp -o winobj\Debug\wxrcgwin.o
mingw32-g++.exe -Wall -pipe -mthreads  -D__GNUWIN32__ -D__WXMSW__ -DWXUSINGDLL -DwxUSE_UNICODE  -g  -Wall -g   -IC:\wxWidgets\include -IC:\wxWidgets\contrib\include -IC:\wxWidgets\lib\gcc_dll\mswu  -c E:\Analysis\wxproj\wxrcplot_data\wxrcplot.cpp -o winobj\Debug\wxrcplot.o
windres.exe -i E:\Analysis\wxproj\WXRCPL~2\wxrcplot.rc -J rc -o winobj\Debug\wxrcplot.res -O coff -IC:\wxWidgets\include -IC:\wxWidgets\lib\gcc_dll\mswu
mingw32-g++.exe -LC:\wxWidgets\lib\gcc_dll  -o bin\Debug\wxRCPlotD.exe winobj\Debug\AboutDialog.o winobj\Debug\AutoscaleAsk.o winobj\Debug\CursorWin.o winobj\Debug\DataDialog_2.o winobj\Debug\PolarDialog.o winobj\Debug\RCScale.o winobj\Debug\Resolution.o winobj\Debug\Summary.o winobj\Debug\TitleAxis.o winobj\Debug\WriteASCII.o winobj\Debug\dataclass.o winobj\Debug\wxrcgwin.o winobj\Debug\wxrcplot.o  winobj\Debug\wxrcplot.res  -mthreads -lm  -lwxmsw28u -lm -lm  -mwindows
Output size is 3.33 MB
Process terminated with status 0 (0 minutes, 20 seconds)
0 errors, 0 warnings (0 minutes, 20 seconds)
All files have the -g flag, which makes sense, because I can inspect a variable if I set a watch on it, and set breakpoints anywhere.  The problem is that I cannot single step.

Here is the debugger log output - I started the program and it ran to a breakpoint I had set.  Then I tried twice to single step (Next Line - F7), and both times I received the Acessing Memory Error:

Code: [Select]
> run
gdb: windows_init_thread_list
[New Thread 4204.0x7e8]
[New Thread 4204.0xa84]
[New Thread 4204.0x938]
[New Thread 4204.0xbb4]
[New Thread 4204.0x424]
Error while mapping shared library sections:
C:\WINDOWS\SysWOW64\ntdll32.dll: No such file or directory.
Breakpoint 3, DataClass::GetSetRanges (this=0x50b940, setnum=0, xmin=0x22f10c, xmax=0x22f104, ymin=0x22f0fc, ymax=0x22f0f4) at E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp:239
E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp:239:6645:beg:0x420800
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> info locals
No locals.
>>>>>>cb_gdb:
> info args
this = 0x50b940
setnum = 0
xmin = 0x22f10c
xmax = 0x22f104
ymin = 0x22f0fc
ymax = 0x22f0f4
>>>>>>cb_gdb:
> whatis maxminset
type = bool
>>>>>>cb_gdb:
> output maxminset
true>>>>>>cb_gdb:
> whatis *ymin
type = double
>>>>>>cb_gdb:
> output *ymin
5.92547884595646e+268>>>>>>cb_gdb:
> next
Warning:
Cannot insert breakpoint -132.
Error accessing memory address 0x7816cd30: Input/output error.
Cannot insert breakpoint -131.
Error accessing memory address 0x78594458: Input/output error.
0x00420805 in DataClass::GetSetRanges (this=0x50b940, setnum=0, xmin=0x22f10c, xmax=0x22f104, ymin=0x22f0fc, ymax=0x22f0f4) at E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp:239
E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp:239:6645:beg:0x420805
>>>>>>cb_gdb:
> info locals
No locals.
>>>>>>cb_gdb:
> info args
this = 0x50b940
setnum = 0
xmin = 0x22f10c
xmax = 0x22f104
ymin = 0x22f0fc
ymax = 0x22f0f4
>>>>>>cb_gdb:
> whatis maxminset
type = bool
>>>>>>cb_gdb:
> output maxminset
true>>>>>>cb_gdb:
> whatis *ymin
type = double
>>>>>>cb_gdb:
> output *ymin
5.92547884595646e+268>>>>>>cb_gdb:
> next
Warning:
Cannot insert breakpoint -137.
Error accessing memory address 0x7816cd30: Input/output error.
Cannot insert breakpoint -136.
Error accessing memory address 0x78594458: Input/output error.
>>>>>>cb_gdb:
> whatis rcMouseClip
type = wxRect
>>>>>>cb_gdb:
> output &rcMouseClip
(wxRect *) 0x50b410>>>>>>cb_gdb:
> output rcMouseClip
{
  x = 0,
  y = 0,
  width = 0,
  height = 0
}>>>>>>cb_gdb:

I can follow some of that, but not all.  Looking at the error:
C:\WINDOWS\SysWOW64\ntdll32.dll: No such file or directory

I verified that that file is not on my system (64-bit XP) - could that be the problem?  I have an ntdll.dll in my Windows/system32 folder, but no ntdll32.dll anywhere.

« Last Edit: February 11, 2011, 12:58:33 am by recobb »

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6534
    • My Best Post
Re: Problem with Debugger when upgrading MinGW
« Reply #6 on: February 11, 2011, 12:42:54 am »
I can follow some of that, but not all.  Looking at the error:
C:\WINDOWS\SysWOW64\ntdll32.dll: No such file or directory

From http://cygwin.com/ml/cygwin/2007-10/msg00179.html
Quote
Simply copying ntdll.dll to ntdll32.dll in SysWOW64 seems to make gdb "happy",
i.e., it no longer displays the message.  Gdb seems to incorrectly "determine"
that the name of the .dll should have "32" appended to it.  That may be
correct for other .dlls, but not this one.

Use at your own risk; the above is just goggle info. I have no idea if it is right; but, it makes sense.

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 oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11770
    • Travis build status
Re: Problem with Debugger when upgrading MinGW
« Reply #7 on: February 11, 2011, 12:50:06 am »
recobb:
Can you post the top of the debugger's log?
The lines with the version info?

p.s. please use code tags for long/any pastes... (if you have the time edit your post, so it utilizes them)
(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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #8 on: February 11, 2011, 01:09:58 am »
recobb:
Can you post the top of the debugger's log?
The lines with the version info?

p.s. please use code tags for long/any pastes... (if you have the time edit your post, so it utilizes them)

Sorry about the code tags - I'd been looking for something to use and missed that, ended up using teletype instead...

Here's the entire log from startup to the breakpoint and then two attempts to single step:

Code: [Select]
PATH=.;C:\wxWidgets\lib\gcc_dll;C:\MinGW32\bin;c:\program files (x86)\php\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\util;c:\program files (x86)\common files\acronis\snapapi\;c:\program files (x86)\quicktime\qtsystem\;C:\Program Files (x86)\MATLAB\R2006b\bin;C:\Program Files (x86)\MATLAB\R2006b\bin\win32;C:\Program Files (x86)\ActivIdentity\ActivClient\;C:\BC5\BIN;C:\Program Files (x86)\IDM Computer Solutions\UltraEdit\;C:\Program Files (x86)\IDM Computer Solutions\UltraCompare\
Command-line: C:\MinGW32\bin\gdb.exe -nx -fullname  -quiet -args bin/Debug/wxRCPlotD.exe
Working dir : E:\Analysis\wxproj\wxrcplot_data\
> set prompt >>>>>>cb_gdb:
Reading symbols from E:\Analysis\wxproj\wxrcplot_data/bin/Debug/wxRCPlotD.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.1
Copyright (C) 2010 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 disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source C:\CodeBlocksNightly\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory E:/Analysis/wxproj/wxrcplot_data/
>>>>>>cb_gdb:
> break "E:/Analysis/wxproj/wxrcplot_data/dataclass.cpp:239"
Breakpoint 2 at 0x420800: file E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp, line 239.
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 4976.0x820]
[New Thread 4976.0x1348]
[New Thread 4976.0x1148]
[New Thread 4976.0xfe4]
[New Thread 4976.0x13bc]
Error while mapping shared library sections:
C:\WINDOWS\SysWOW64\ntdll32.dll: No such file or directory.
Breakpoint 2, DataClass::GetSetRanges (this=0x50b940, setnum=0, xmin=0x22f10c, xmax=0x22f104, ymin=0x22f0fc, ymax=0x22f0f4) at E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp:239
E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp:239:6645:beg:0x420800
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> info locals
No locals.
>>>>>>cb_gdb:
> info args
this = 0x50b940
setnum = 0
xmin = 0x22f10c
xmax = 0x22f104
ymin = 0x22f0fc
ymax = 0x22f0f4
>>>>>>cb_gdb:
> next
Warning:
Cannot insert breakpoint -132.
Error accessing memory address 0x7816cd30: Input/output error.
Cannot insert breakpoint -131.
Error accessing memory address 0x78594458: Input/output error.
0x00420805 in DataClass::GetSetRanges (this=0x50b940, setnum=0, xmin=0x22f10c, xmax=0x22f104, ymin=0x22f0fc, ymax=0x22f0f4) at E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp:239
E:\Analysis\wxproj\wxrcplot_data\dataclass.cpp:239:6645:beg:0x420805
>>>>>>cb_gdb:
> info locals
No locals.
>>>>>>cb_gdb:
> info args
this = 0x50b940
setnum = 0
xmin = 0x22f10c
xmax = 0x22f104
ymin = 0x22f0fc
ymax = 0x22f0f4
>>>>>>cb_gdb:
> next
Warning:
Cannot insert breakpoint -137.
Error accessing memory address 0x7816cd30: Input/output error.
Cannot insert breakpoint -136.
Error accessing memory address 0x78594458: Input/output error.
>>>>>>cb_gdb:

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #9 on: February 11, 2011, 02:15:46 am »
Quote
PATH=.;C:\wxWidgets\lib\gcc_dll;C:\MinGW32\bin;c:\program files (x86)\php\;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\system32\wbem;c:\util;c:\program files (x86)\common files\acronis\snapapi\;c:\program files (x86)\quicktime\qtsystem\;C:\Program Files (x86)\MATLAB\R2006b\bin;C:\Program Files (x86)\MATLAB\R2006b\bin\win32;C:\Program Files (x86)\ActivIdentity\ActivClient\;C:\BC5\BIN;C:\Program Files (x86)\IDM Computer Solutions\UltraEdit\;C:\Program Files (x86)\IDM Computer Solutions\UltraCompare\

from the error:
Quote
Error while mapping shared library sections:
C:\WINDOWS\SysWOW64\ntdll32.dll: No such file or directory.

it seems the path:
C:\WINDOWS\SysWOW64\ was not in PATH environment variable.

And you could try a recent mingw gcc and gdb (gcc 4.5.3 snapshot, gdb 2011xxx), see here:
http://pcxprj.googlecode.com/files/MinGW_win32_gcc4.5.3static_snapshots.7z
To test it whether the bug was fixed. :D
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #10 on: February 11, 2011, 05:52:19 am »


Quote
it seems the path:
C:\WINDOWS\SysWOW64\ was not in PATH environment variable.

The error message included the full path to where it was looking for it, so it already knew where to find the file, it's just not there.  I
used stahta01's suggestion to make a copy of ntdll.dll and rename it to what it was looking for, and that eliminated that error message.

Quote
And you could try a recent mingw gcc and gdb (gcc 4.5.3 snapshot, gdb 2011xxx), see here:
http://pcxprj.googlecode.com/files/MinGW_win32_gcc4.5.3static_snapshots.7z
To test it whether the bug was fixed. :D

Sigh.  It would appear not.  That's 3 different versions (the one from the link above is GNU gdb (GDB) 7.2.50.20110115) single stepping will not work on - only the pre-packaged 6.8 gdb version seems to single step correctly.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #11 on: February 11, 2011, 06:07:18 am »
Quote
only the pre-packaged 6.8 gdb version seems to single step correctly.
Currently I don't have any project which can reproduce it.
I suggest that you can post to GDB maillist or fire a bug report in
http://sourceware.org/bugzilla/
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #12 on: February 12, 2011, 02:49:35 am »
Quote
only the pre-packaged 6.8 gdb version seems to single step correctly.
Currently I don't have any project which can reproduce it.
I suggest that you can post to GDB maillist or fire a bug report in
http://sourceware.org/bugzilla/
It just seems to get stranger and stranger.  I cut down the program to just some basics that would recreate the problem.  Then I copied all the files to another folder to make sure I identified which files I needed for a complete package.  I compiled it and ran it in the debugger, and it worked fine(!)  So then I did a diff of all the files, and they were the same.  I deleted the bin and obj folders and contents, and also the depends files - no matter, the debugger would have the problem in one folder and not the other.

Then I realized one difference - as part of the program execution to get to the breakpoint where the problem occurs I have to use a file dialog to open a data file.  In the 'packaged' folder I had included the data file, so I opened the data file in the same folder as the project.  In the other case I had to first navigate to a different folder to find the data file.  Even though it reads the file correctly in either case, when I have to first navigate to a different folder I get the single step debug error.  But when it opens in the same folder I don't get it.  I've since been able to have the debugger work correctly in either project, or not, depending on where I read the data file relative to the project.

At least 70-80% of the time... Every time I think I have a repeatable pattern, something confounds it again.

I can't guarantee the problem will repeat on a different setup, but it's the best I can do for now.  Are you interested, and, if so, how would I transmit the files?


Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #13 on: February 12, 2011, 03:35:29 am »
you can attach the files as attachment in the post.
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #14 on: February 12, 2011, 02:20:56 pm »
you can attach the files as attachment in the post.

All the project files are in the zip file, in case they have any bearing on the problem.  The two program files are:

dcmain.cpp
dataclass.cpp

A0018.prn is a sample data file.  If it is in the same folder as the program files, the error will not occur.  I have not tried moving it to a sub-folder, but when moved to a parent folder (or parent\sub) I have been able to produce the error.

To produce the error:
Set a breakpoint at line 227 in dataclass.cpp
 ( if(!DS[setnum].minmaxset[0]) return false; is the line)

Start the debugger, go to File|Open New ASCII and open A0018.prn
The debugger should stop at the breakpoint.  Use the single-step command.  If A0018.prn is in the same folder as the project, no error occurs.  If in a different folder, it does occur.

This is from my latest test, using the snapshot at http://pcxprj.googlecode.com/files/MinGW_win32_gcc4.5.3static_snapshots.7z

Code: [Select]
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.2.50.20110115
Child process PID: 3560
At E:\Analysis\wxproj\debugerror\dataclass.cpp:227
Error accessing memory address 0x7816cd30: Input/output error.
Error accessing memory address 0x78594458: Input/output error.
At E:\Analysis\wxproj\debugerror\dataclass.cpp:227

I was also able to produce the error using the TDM version from here: http://tdm-gcc.tdragon.net/development and the latest from the MinGW site (version numbers are shown earlier in this thread).

This code is a chopped up/commented out mess - I took at axe to my project to try to find a minimal set of code to recreate the problem.  Hope it will do the same on your machine.

Thanks!
« Last Edit: February 12, 2011, 02:24:38 pm by recobb »

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #15 on: February 13, 2011, 12:57:25 pm »
I just test your project. (you path was hard-coded, that I need to change a lot)
I do not have memory access error(I'm using loaden's gcc 4.4.5 and gdb GNU gdb (GDB) 7.2.50.20110110-cvs)
loaden's gcc and gdb can be found:http://code.google.com/p/qp-gcc/
 :D

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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #16 on: February 13, 2011, 01:42:30 pm »
I just test your project. (you path was hard-coded, that I need to change a lot)

BTW:
is it possible to copy the build option between projects.(this can save a lot of time)
currently, it only allowed to copy build option between targets.
Any ideas.
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: 11770
    • Travis build status
Re: Problem with Debugger when upgrading MinGW
« Reply #17 on: February 13, 2011, 04:18:41 pm »
You can make a plugin that copies project options ...
(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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #18 on: February 13, 2011, 04:41:50 pm »
I just test your project. (you path was hard-coded, that I need to change a lot)
I do not have memory access error(I'm using loaden's gcc 4.4.5 and gdb GNU gdb (GDB) 7.2.50.20110110-cvs)
loaden's gcc and gdb can be found:http://code.google.com/p/qp-gcc/
 :D

Well, thanks for trying.  I just downloaded from the site above and tried that (slightly different version: GNU gdb (GDB) 7.2.50.20101012), and still same problem.  If I open the data file located in the project folder, single stepping works.  Open in a different folder, and it does not.  That makes 4 different 7.x versions that all have the same problem (for me).  Only the pre-packaged 6.8 version does not have the problem.


Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #19 on: February 14, 2011, 02:18:41 am »
If I open the data file located in the project folder, single stepping works.  Open in a different folder, and it does not. 
This was too strange, I will test it tonight.
BTW: I guess: does your anti-virus program cause this problem??? :D
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #20 on: February 14, 2011, 02:24:40 am »
If I open the data file located in the project folder, single stepping works.  Open in a different folder, and it does not. 
This was too strange, I will test it tonight.
BTW: I guess: does your anti-virus program cause this problem??? :D

I don't think so - I don't have the problem using the 6.8 version.  I'm using Commodo, for whatever that is worth.

I've been wondering if somehow, when using the file open dialog, some path is set to the new location and it loses some connection to the source files in the project folder.  But that doesn't really make sense either, as I can set breakpoints in the source file and those still work.  I could effectively single step by setting a breakpoint at every line, then resuming at each breakpoint - but that's not a happy way of doing things  :(

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #21 on: February 14, 2011, 02:28:05 am »
so, the problem(gdb complain memory access error) only happens when you open a file in a different folder(not the project folder)?
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #22 on: February 14, 2011, 02:33:12 am »
so, the problem(gdb complain memory access error) only happens when you open a file in a different folder(not the project folder)?

That's right - if I open the data file while it's in the project folder I don't have a problem.  It's only when I have to navigate to a different folder (using the file dialog) that the problem appears.

Offline recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #23 on: February 14, 2011, 03:18:58 pm »
so, the problem(gdb complain memory access error) only happens when you open a file in a different folder(not the project folder)?

That's right - if I open the data file while it's in the project folder I don't have a problem.  It's only when I have to navigate to a different folder (using the file dialog) that the problem appears.

Well, it gets stranger and stranger.  This morning I created a new project (with a different project name) in the same folder as the files for the test case.  I went through the wizard, created a blank wxwidgets project, then added the .cpp files from the other project once it was created.  The problem with single-stepping was not present.  OK, so it's something to do with the project settings I thought to myself.  So I went and rebuilt the project as included in the zip test case.  The problem had disappeared there too!  OK, so maybe there are some files that are being updated from one project that affect the other.  I did a 'clean' and verified that all object files and executables were removed (or I deleted them myself).  I also checked the dates of all the files in the main project folder.  The only files newer than the zip file I posted were for the newly created project (a .cbp and .depend), and a .layout file for the original project.  I opened the .layout file in an editor and could not see anything in there that would affect anything (it was only a couple of lines long).  I rebuilt again and tried the debugger - it's now working (this is the tdw version) as it should.

OK, so all I need to do is create a new project for my original (full) project, which I did.  The Single Step Problem is Still There...    :?

The Full Moon is only 4 days away, maybe that's it.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6534
    • My Best Post
Re: Problem with Debugger when upgrading MinGW
« Reply #24 on: February 14, 2011, 03:33:44 pm »
Note: The below assumes the OP is a Vista or Windows 7 user.
@recobb: You do realize that Vista and Windows 7 have different permissions per folder.
If either one of the below fixes the problem.
1. Run Code::Blocks as Admin does the problem go away.
2. Turn off UAC and if problem goes away it is a Windows Security issue.
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #25 on: February 14, 2011, 03:36:24 pm »
Note: The below assumes the OP is a Vista or Windows 7 user.
@recobb: You do realize that Vista and Windows 7 have different permissions per folder.
If either one of the below fixes the problem.
1. Run Code::Blocks as Admin does the problem go away.
2. Turn off UAC and if problem goes away it is a Windows Security issue.

Nope, XP, Pro x64, version 2003, SP2

Offline jens

  • Administrator
  • Lives here!
  • *****
  • Posts: 7265
    • Jens' unofficial debian-repository for the Code::Blocks - IDE
Re: Problem with Debugger when upgrading MinGW
« Reply #26 on: February 14, 2011, 05:17:48 pm »
I don't think so - I don't have the problem using the 6.8 version.  I'm using Commodo, for whatever that is worth.
Did you try it with comodo disabled ?

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9493
Re: Problem with Debugger when upgrading MinGW
« Reply #27 on: February 14, 2011, 08:38:53 pm »
I don't think so - I don't have the problem using the 6.8 version.  I'm using Commodo, for whatever that is worth.
Did you try it with comodo disabled ?
Definitely worth a try. I am using Comodo myself. But for a developer this can be a pain in the a**. It took me literally month to set it up so that it does not interfere with my development process / style.

Remember that Comodo has different modules (AV, Firewall, Defense+ and the sandbox) - they ALL caused pain for me, so try to disable them step-by-step or set them into training mode to be alerted if something is blocked. Once found the components you can fine-tune them.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: http://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: http://wiki.codeblocks.org/index.php?title=FAQ

Offline recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #28 on: February 15, 2011, 12:54:23 am »
Quote
Quote

Did you try it with comodo disabled ?
Definitely worth a try. I am using Comodo myself. But for a developer this can be a pain in the a**. It took me literally month to set it up so that it does not interfere with my development process / style.

Remember that Comodo has different modules (AV, Firewall, Defense+ and the sandbox) - they ALL caused pain for me, so try to disable them step-by-step or set them into training mode to be alerted if something is blocked. Once found the components you can fine-tune them.

That didn't seem to change anything.  I killed Commodo from it's menu, then looked in Process Explorer to see if it left anything still running.  I found the cmdagent process still running (part of Commodo, and it hogs a lot of CPU), so I killed that.  I couldn't identify any other processes associated with Commodo.  The problem is still there.

But it was worth a check.  I've certainly had my problems with Commodo and gdb/gcc/CB in the past, and had to do some tweaks to be able to use things at all without a whole lot of error/warning messages popping up.  I forget what I did, but I haven't been seeing those messages lately.

Offline recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #29 on: February 15, 2011, 01:05:56 am »
More info - I said the problem went away with the project I had posted.  Not so.  But it appears to be more sensitive to file location than just being 'not in the project folder'.

When I reported that the problem was gone this morning, the file had been in the parent folder of the project folder, and that worked OK.  I also put the file in a sub-folder of the project folder (the bin folder), and that was OK.  But when I put the file in a folder parallel to the project folder, the problem appears.  That is, say the project is in folder ..\wxprojects\debugerror.  Then I have no problem if the data file is in ..\wxprojects\debugerror\bin or ..\wxprojects, but it does appear if it is in ..\wxprojects\otherfolder.

Please give that a try.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #30 on: February 15, 2011, 02:05:09 am »
I test your sample code again, and both file in project folder and other folder will cause memory access error, see the log below:
Quote
> run
gdb: windows_init_thread_list
[New Thread 3612.0xe20]
[New Thread 3612.0xe28]
[New Thread 3612.0xe2c]
[New Thread 3612.0xe30]
[New Thread 3612.0xe34]
BFD: C:\WINDOWS\system32\WMVCore.dll: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
[New Thread 3612.0xe38]
[New Thread 3612.0xe3c]
[New Thread 3612.0xe40]
[New Thread 3612.0xe44]
Breakpoint 2, DataClass::GetSetRanges (this=0x4224e0, setnum=0, xmin=0x23f7e4, xmax=0x23f7dc, ymin=0x23f7d4, ymax=0x23f7cc) at D:\gdb_error\dataclass.cpp:227
D:\gdb_error\dataclass.cpp:227:6357:beg:0x403bad
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> next
Warning:
Cannot insert breakpoint -411.
Error accessing memory address 0x7816cd30: Input/output error.
0x00403bb0 in DataClass::GetSetRanges (this=0x4224e0, setnum=0, xmin=0x23f7e4, xmax=0x23f7dc, ymin=0x23f7d4, ymax=0x23f7cc) at D:\gdb_error\dataclass.cpp:227
D:\gdb_error\dataclass.cpp:227:6357:beg:0x403bb0
>>>>>>cb_gdb:
> cont
[New Thread 3612.0x37c]
[New Thread 3612.0x3ac]
Breakpoint 2, DataClass::GetSetRanges (this=0x4224e0, setnum=0, xmin=0x23f7e4, xmax=0x23f7dc, ymin=0x23f7d4, ymax=0x23f7cc) at D:\gdb_error\dataclass.cpp:227
D:\gdb_error\dataclass.cpp:227:6357:beg:0x403bad
>>>>>>cb_gdb:
> next
Warning:
Cannot insert breakpoint -416.
Error accessing memory address 0x7816cd30: Input/output error.
0x00403bb0 in DataClass::GetSetRanges (this=0x4224e0, setnum=0, xmin=0x23f7e4, xmax=0x23f7dc, ymin=0x23f7d4, ymax=0x23f7cc) at D:\gdb_error\dataclass.cpp:227
D:\gdb_error\dataclass.cpp:227:6357:beg:0x403bb0
>>>>>>cb_gdb:
> next
Warning:
Cannot insert breakpoint -421.
Error accessing memory address 0x7816cd30: Input/output error.
>>>>>>cb_gdb:
Now, I'm using pcx's 4.5.3 package:
http://code.google.com/p/pcxprj/downloads/detail?name=MinGW_win32_gcc4.5.3static_snapshots.7z

using other packages:
tdm4.5.1 loaden4.4.5 pcx4.5.2, the first time I debug the program, I will see the memory access error, but the second time I debug, there is no such error.(I do not rebuild the target, I just press the debug button to start the debugger again)

I have totally disable my anti virus.
That was too strange.
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #31 on: February 15, 2011, 02:34:26 am »
I test your sample code again, and both file in project folder and other folder will cause memory access error, see the log below:

You don't know how happy that makes me, at this point, that someone else has been able to reproduce this damn error!  :D

Do you have any suggestions for next step(s)?



Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #32 on: February 15, 2011, 02:40:03 am »
Do you have any suggestions for next step(s)?
the "memory access" error happens randomly, so I don't know how to check it. Does it due to GCC or GDB????
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #33 on: February 15, 2011, 03:02:10 am »
Do you have any suggestions for next step(s)?
the "memory access" error happens randomly, so I don't know how to check it. Does it due to GCC or GDB????

So far, on my system, it has been dependent on the location of the data file (but, apparently not for you?).  I do not have the problem when the data file is in the project directory, but when it is located in (possibly specific) other folders.  Since it is the same code (already compiled with a given compiler) that has the problem in one location, but not another, I'm leaning towards thinking it is the debugger.

So far, the pattern on my system (3 different project files) is this:
-data file in parallel folder (up a level from the project file, then down a level into another folder) - the problem always occurs.
-data file in project folder -it usually works, although not always.  But immediately running it again can change the result from the previous run
-data file in parent folder - fairly random


Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #34 on: February 15, 2011, 03:05:54 am »
-data file in project folder -it usually works, although not always.  But immediately running it again can change the result from the previous run
I can definitely confirm this!!!
I guess the problem is in GDB. :D
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #35 on: February 15, 2011, 01:55:28 pm »
-data file in project folder -it usually works, although not always.  But immediately running it again can change the result from the previous run
I can definitely confirm this!!!
I guess the problem is in GDB. :D

It would seem that this problem is limited to the Windows version.  I just booted into Fedora 14 Linux (GNU gdb (GDB) Fedora (7.2-36.fc14) ) and could not recreate the problem with any of the test cases.  Every 7.x version on the Windows side that I have tried can produce the problem.


Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 11770
    • Travis build status
Re: Problem with Debugger when upgrading MinGW
« Reply #36 on: February 15, 2011, 02:52:53 pm »
GDB guys have mailing list and bug tracker, use it :)
(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: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #37 on: February 16, 2011, 02:23:00 am »
GDB guys have mailing list and bug tracker, use it :)
agreed.
BTW:
search the string "Error accessing memory address" on the gdb's source, you can quickly find in "breakpoint.c" around line 1773. but I have no idea about everything else.

Also, the related topics can be discussed in GDB mailist(not here). :D
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #38 on: February 16, 2011, 03:24:45 am »
GDB guys have mailing list and bug tracker, use it :)

OK.  Well, I guess I'll have to get an account there.  Is this the right link?: http://sourceware.org/bugzilla/

Thanks.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #39 on: February 16, 2011, 03:26:03 am »
GDB guys have mailing list and bug tracker, use it :)

OK.  Well, I guess I'll have to get an account there.  Is this the right link?: http://sourceware.org/bugzilla/

Thanks.
yes.
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 recobb

  • Multiple posting newcomer
  • *
  • Posts: 30
Re: Problem with Debugger when upgrading MinGW
« Reply #40 on: February 16, 2011, 04:42:51 pm »

major_tom3

  • Guest
Re: Problem with Debugger when upgrading MinGW
« Reply #41 on: April 03, 2013, 11:47:37 am »
I am experiencing the very same problems.  I see that the Bugzilla bug has not been worked on or even assigned to anyone in over two years.

Was a resolution ever found to this problem?  Can anyone update this thread?

Thanks in advance.

Offline stahta01

  • Lives here!
  • ****
  • Posts: 6534
    • My Best Post
Re: Problem with Debugger when upgrading MinGW
« Reply #42 on: April 03, 2013, 04:42:32 pm »
I am experiencing the very same problems.  I see that the Bugzilla bug has not been worked on or even assigned to anyone in over two years.

Was a resolution ever found to this problem?  Can anyone update this thread?

Thanks in advance.

from http://sourceware.org/bugzilla/show_bug.cgi?id=12493
Quote
A minimal reproducer that just uses gdb (no codeblocks in the picture) would go
a long way.  Please also try 7.5 and if possible the 7.6 release candidate
(bugs in this area have been fixed in 7.6).

I suggest doing what is suggest on the site linked.
Note: The Code::Blocks team does NOT fix bugs in gdb.
If you want it fixed; I suggest finding the gdb produced by the MinGW team instead of a third party like TDM etc.
Reproduce the problem using the command line interface of gdb.
Submit the way to reproduce the bug.

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 ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5219
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Problem with Debugger when upgrading MinGW
« Reply #43 on: April 05, 2013, 08:16:25 am »
I am experiencing the very same problems.  I see that the Bugzilla bug has not been worked on or even assigned to anyone in over two years.

Was a resolution ever found to this problem?  Can anyone update this thread?

Thanks in advance.
I don't have any problem on the recobb's test code.
If you have a test case, you can post it in GDB's Bugzilla, it is:http://sourceware.org/bugzilla/show_bug.cgi?id=12493


Quote
So far, the pattern on my system (3 different project files) is this:
-data file in parallel folder (up a level from the project file, then down a level into another folder) - the problem always occurs.
-data file in project folder -it usually works, although not always.  But immediately running it again can change the result from the previous run
-data file in parent folder - fairly random
Every test case works fine.

I'm using PCX's MinGW GCC 4.6.3, and GDB CVS build myself.
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.