Author Topic: Problems using C::B / GDB under WinXPSP2  (Read 8318 times)

Diego

  • Guest
Problems using C::B / GDB under WinXPSP2
« on: October 18, 2005, 11:36:23 pm »
Hi All!

I am a new C::B user. I've downloaded the latest version (1.0-RC1-1) for Win. And I am running it on a Sempron Mobile 1.6GHz, 256MB RAM with XP SP2 OS.
 
The IDE looks great!!!   :D

 But unfortunately I am having problems trying to debug a simple console application. The GDB seems to suddenly crash after passing some breakpoints.

I have no experience using GDB so I am enterely relying on the C::B interface.

Here is a portion of the GDB dump:

frame-source-end
source C:/DOCUME~1/Diego/MYDOCU~1/CSC545/SIMPLE~1/code/main.c:84:2325:beg:0x402369
frame-end
stopped
pre-prompt
prompt
> next
post-prompt
starting
frames-invalid
frames-invalid
frames-invalid
frames-invalid
frames-invalid
frames-invalid
.
.
.

The GDB (Debug) windows keeps showing 'frames-invalid' message until I manually finish the debugging.

I have been looking to other postings and nobody seems to have the same problem, so I suspect that maybe I am missing something, some configuration or so...

Any Idea about what can be happening?   BTW, GDB is Version 6.3

Thank you!!!!!!!!
Diego.

Offline mandrav

  • Project Leader
  • Administrator
  • Lives here!
  • *****
  • Posts: 4315
    • Code::Blocks IDE
Re: Problems using C::B / GDB under WinXPSP2
« Reply #1 on: October 18, 2005, 11:44:05 pm »
Haven't seen that before.
One thing you can do is try and create  minimal test-case and post it here with steps to reproduce the problem.
Or, you can downgrade gdb to a more stable version like 5.2 (although I never had any problems with gdb6.3, but that's just me)...
Be patient!
This bug will be fixed soon...

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Problems using C::B / GDB under WinXPSP2
« Reply #2 on: October 19, 2005, 12:28:21 am »
The frames-invalid is a normal message, i think. GDB 6 has this obnoxious habit of saying everything and cluttering the output. But otherwise than that, what do you mean with "crash"?

Diego

  • Guest
Re: Problems using C::B / GDB under WinXPSP2
« Reply #3 on: October 19, 2005, 12:54:38 am »
Hi,

What I mean by 'crash' is, for example: the program stops at a breakpoint, then I press F7 (Step over) then the Blue highlighting dissapears and the GDB (Debug) window

keeps showing 'frames-invalid' message over and over while the CPU usage is 100% until I manually stop the debbuging process (Debug->Stop Debbuger).

Thanks for your help,
Diego.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Problems using C::B / GDB under WinXPSP2
« Reply #4 on: October 19, 2005, 01:37:38 am »
Oh, it means your program probably ran into a loop and Code::Blocks is just reporting the gdb messages. Try "step into" instead and see what happens. But yeah, i think GDB 5.2 sends less messages.

Offline thomas

  • Administrator
  • Lives here!
  • *****
  • Posts: 3979
Re: Problems using C::B / GDB under WinXPSP2
« Reply #5 on: October 19, 2005, 01:45:41 pm »
Hmm... I have no experience with a debugger running on virtual memory, but could that possibly be a cause? In theory, VM management should be 100% transparent to an application, but is that true for a debugger, too?

256 MB is not really a lot for Windows XP SP2, the system almost eats up that much already. Code::Blocks has a working set of ~25MB too, and neither compiler nor debugger are what you would call lightweight processes. So maybe the debugger produces errors because of some strange VM issue when something is paged? Just an idea...

Do you have another machine with more RAM, and can you reproduce the problems there?
"We should forget about small efficiencies, say about 97% of the time: Premature quotation is the root of public humiliation."

Offline Urxae

  • Regular
  • ***
  • Posts: 376
Re: Problems using C::B / GDB under WinXPSP2
« Reply #6 on: October 19, 2005, 04:25:43 pm »
Hmm... I have no experience with a debugger running on virtual memory, but could that possibly be a cause? In theory, VM management should be 100% transparent to an application, but is that true for a debugger, too?

Should be totally transparent, unless timing is involved. Then things get wacky ;).
Well, except for the fact that memory requests tend to be denied less often, but that should usually hide bugs, not reveal them...

Diego

  • Guest
Re: Problems using C::B / GDB under WinXPSP2
« Reply #7 on: October 19, 2005, 08:04:25 pm »
Hi All!

Well, I've been trying most of what you said and other tricks but there was no success.

I' ve tried downgrading the GDB to v5.2 and the problems is still the same. I've tried step into instead of step over and again, no
success.

Just to give you more info, the line where I put the breakpoint contains a call to a function in other module, I tried putting
the breakpoint inside that function in that module, and again it crashes. It seems to be a problem when the breakpoint is in
some way related to other module than 'main'.

Regarding the RAM issue, that's right 256MB is not big deal, but I think we can rely on the MS VM implementation... can we?
Anyway I gave the project to a friend who's PC is more powerful than mine and the same "bug" appears.

The good thing, unless for C::B, is that some other IDEs based on GDB (like C-Free or Dev-C++) also fail to debug the program. The
difference is that with C::B we can get more info from the GDB (Debug) log window  :)

I will try to set up a basic case where this 'bug' appears and will send it to you, but first I have to finish my programming project  :? !!

Thank you!
Diego.

Offline rickg22

  • Lives here!
  • ****
  • Posts: 2283
Re: Problems using C::B / GDB under WinXPSP2
« Reply #8 on: October 19, 2005, 08:20:24 pm »
Diego: When you can't debug, you have to use the last resort: MessageBoxes, printf's, etc!

We've pinpointed nasty bugs in C::B using this primitive-but-effective method.

Diego

  • Guest
Re: Problems using C::B / GDB under WinXPSP2
« Reply #9 on: October 21, 2005, 09:32:51 pm »
Hi all again,

Well it seems now I can tell more about the problem.

I redesigned my hole project because it was a "little" time and memory consuming, the latter was, I think, terrible. :lol:

For now I don't have that nasty problem while debugging.

I guess that I was overloading in some way the debbuger by asking it to handle big structures that might have entered in conflict with the memory management.

Although in a perfect world this should be transparent I guess we can't be so demanding :shock:

Thank you all for your help!
Goodbye!