Problem with Debugger when upgrading MinGW

[ollydbg]

I test your sample code again, and both file in project folder and other folder will cause memory access error, see the log below:

> 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.

[recobb]

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! 

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

[ollydbg]

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?

[recobb]

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

[ollydbg]

-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.

[recobb]

-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.

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.

[oBFusCATed]

GDB guys have mailing list and bug tracker, use it

[ollydbg]

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).

[recobb]

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.

[ollydbg]

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.

[recobb]

gdb bug posted: http://sourceware.org/bugzilla/show_bug.cgi?id=12493

[major_tom3]

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.

[stahta01]

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

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.

[ollydbg]

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

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.