Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
tomjnx:
How to crash the debugger plugin / C::B:
Open a project, set a breakpoint, start debugging
Edit the breakpoint, add a condition with a symbol that does not exist
Now a message box pops up asking you whether you want to convert the breakpoint into an unconditional one
Kill gdb
Click on either the yes or no button of the popup dialog
Watch the fireworks.
What happens is the following:
Gdb outputs a string saying it doesn't like the condition
OnGDBOutput is called
ParseOutput is called
the cbMessageBox is opened deeply down the call stack of ParseOutput
Now cbMessageBox apparently starts to handle events
gdb terminating causes an event that causes OnGDBTerminated to be called
OnGDBTerminated deallocates the debugger driver (even though code of the debugger driver still runs)
I haven't had an easy + somewhat clean idea on how to fix this... In the end I removed HasDriver, but added LockDriver and UnlockDriver. LockDriver still returns a value indicating whether there is a driver, but if there is, also increments a use counter. Terminate then does not deallocate the driver, but only sets a flag. UnlockDriver then decrements the use counter, and if it reaches zero, checks the terminate flag and does the deallocation if the flag is set. All calls to m_State.GetDriver() need to be surrounded with LockDriver() and UnlockDriver(). Also, there needs to be some buffering to prevent ParseOutput to be reentered...
Is it worth fixing? Dunno. It was definitely unexpected when I hacked the code...
oBFusCATed:
--- Quote from: tomjnx on January 30, 2012, 04:43:49 pm ---Is it worth fixing? Dunno. It was definitely unexpected when I hacked the code...
--- End quote ---
No, I've switched all my energy to gdb/mi plugin. The current plugin is lost battle. It works, but it will never be stable and fast.
killerbot:
since last weeks changes (debugger plugin // cc plugin) : failing to build :
[even did make clean up to .configure]
--- Code: ---make[4]: *** No rule to make target `ccdebuginfo.cpp', needed by `ccdebuginfo.lo'.
--- End code ---
Jenna:
--- Quote from: killerbot on January 30, 2012, 07:20:14 pm ---since last weeks changes (debugger plugin // cc plugin) : failing to build :
[even did make clean up to .configure]
--- Code: ---make[4]: *** No rule to make target `ccdebuginfo.cpp', needed by `ccdebuginfo.lo'.
--- End code ---
--- End quote ---
I just installed the debugger-branch from my repo, build today (r7736) without pproblems.
Did you run ./bootstrap ?
As far as I know, there are changes in one or more Makefile.am's.
If that's the case the Makefile.in's have to be recreated by (re-)running ./bootstrap .
If that does not work a make distclean before ./bootstrap might help .
oBFusCATed:
killerbot:
I knew, you'll report this problem :)
"make distclean" is needed in this case. I don't know why.
I suggest to start building in a separate directory and before every build to run rm -rf mybuild_folder.
See this post for details how to do it: http://forums.codeblocks.org/index.php/topic,15840.msg106624.html#msg106624
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version