News:

The new Release 25.03 is out! You can download binaries for Windows and many major Linux distros here .

Main Menu

debug CodeBlocks

Started by killerbot, December 07, 2005, 08:27:09 PM

Previous topic - Next topic

killerbot

I am trying to debug CB, so I have build CB and done run update.
So in the output directory I am starting up CB (and allowed to be multi instanced). I open up the CB project (new build), and start the debugging sessions (choose src target),
but then i get complaints about the files where I put the breakpoints, it complains that they do not exist. And I get SIGSEGV.

Obviously I am doing something wrong, anyone cna help me out ??

Thanks,
Lieven

rickg22

after running update, you need to debug the codeblocks.exe in "devel", not "output". :)

killerbot

Thanks,

It is working now.
But to be honest, it is not such a pleasant journey, it crashes a lot, I think it's the debugger related code.
And I am not able to see what's the data behind the pointers !! So I am in a functio, which for example get pointer to classes as arguments or get's a pointer by calling some Get method, but I only see the address. :-(

Is there a way to see the real data the pointer is pointing to, since as I have it now, this is very hard debugging (nearly useless).

Cheers,
Lieven

rickg22

Yes, the gdb plugin is buggy. The last time i used it my watches jumped all around, and when editing them suddenly my keyboard would go crazy :(

mandrav

Quote from: killerbot on December 07, 2005, 10:24:36 PM
Is there a way to see the real data the pointer is pointing to, since as I have it now, this is very hard debugging (nearly useless).

Add your watch with a * prepended so that it is dereferenced, e.g. watch "*pMyClass" instead of "pMyClass".

Quote from: rickg22 on December 07, 2005, 10:34:09 PM
Yes, the gdb plugin is buggy. The last time i used it my watches jumped all around, and when editing them suddenly my keyboard would go crazy :(

:shock: :shock: :shock:

Are you talking about the plugin with the latest changes? Because I use it all the time and I 've never experienced such things  :shock:
Be patient!
This bug will be fixed soon...

rickg22

Yes, that one. :(

The behavior is very erratic, i would edit a watch and my keyboard began doing weird things. Usually it involves wxArray items like m_myarray[1].

mandrav

Quote from: rickg22 on December 07, 2005, 11:33:13 PM
Yes, that one. :(

The behavior is very erratic, i would edit a watch and my keyboard began doing weird things. Usually it involves wxArray items like m_myarray[1].

I 'm sorry, but I don't get it. What can the plugin possibly do to your keyboard?
Post a way to reproduce this because I can't even think of a way that this could happen...
Be patient!
This bug will be fixed soon...

rickg22

I think the shift mode got stuck or something... but i was pressing something and then the dialog suddenly closed in the middle. It only happened while debugging was active. Maybe there's some loose pointer around... who knows.

killerbot

I had tried stuff like *mypoiinter, but I got not excepted.
Just trying it again .....  now it works.

I will keep a close "watch" on this.

killerbot

but more strange stuff is happening.

I had placed my breakpoint on this line
    if (!pf->compile || pf->compilerVar.IsEmpty())
in  wxArrayString DirectCommands::CompileFile(ProjectBuildTarget* target, ProjectFile* pf, bool force)


So now I could watch *pf.

Then I removed my breakpoint, but nevertheless each time execution still halts at that point though I removed the breakpoint.

When I checked in Debig->Breakpoints, it is still in the list, though the red bullet is no longer in the left gutter (since I clicked it togo away) ... ???

Lieven

mandrav

Quote from: killerbot on December 08, 2005, 07:38:27 AM
Then I removed my breakpoint, but nevertheless each time execution still halts at that point though I removed the breakpoint.

When I checked in Debig->Breakpoints, it is still in the list, though the red bullet is no longer in the left gutter (since I clicked it togo away) ... ???

I didn't say it's bug-free yet ;)
What I don't understand is what Rick is saying. It makes no sense to me...
Be patient!
This bug will be fixed soon...

tiwag

i didn't observe erratic behaviour either - the breakpoints are captured very well here at my system (WinXP) even BP's which are located in later loaded dll's - this is a GREAT improvement compared to RC2 breakpoint management. I got only one time a crash on an old laptop which was low on memory (192MB) and is somewhat overstrained with running WinXP and debugging. But on my well equipped modern machines (AMD XP 2800 - 512...1024MB) it's running excellent !

rickg22

weird... i guess my case is unique then.