User forums > Using Code::Blocks
Problem with Debugger when upgrading MinGW
recobb:
--- Quote from: ollydbg on February 11, 2011, 02:15:46 am ---
--- End quote ---
--- Quote ---it seems the path:
C:\WINDOWS\SysWOW64\ was not in PATH environment variable.
--- End quote ---
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
--- End quote ---
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.
ollydbg:
--- Quote ---only the pre-packaged 6.8 gdb version seems to single step correctly.
--- End quote ---
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/
recobb:
--- Quote from: ollydbg on February 11, 2011, 06:07:18 am ---
--- Quote ---only the pre-packaged 6.8 gdb version seems to single step correctly.
--- End quote ---
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/
--- End quote ---
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?
ollydbg:
you can attach the files as attachment in the post.
recobb:
--- Quote from: ollydbg on February 12, 2011, 03:35:29 am ---you can attach the files as attachment in the post.
--- End quote ---
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
--- End code ---
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!
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version