Author Topic: Problem with Debugger when upgrading MinGW  (Read 37966 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
---------------------------------------------------
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: 5913
  • 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: 13413
    • 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
-------------- 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
> 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: 7590
    • 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 64 bit.
--
When in doubt, read the CB WiKi FAQ. http://wiki.codeblocks.org

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • 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
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: 5913
  • 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: 5913
  • 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: 5913
  • 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
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 »