Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
Frame issue with the debugger plugin
oBFusCATed:
--- Quote from: scarphin on April 07, 2015, 01:15:41 am ---Yes, many times but I quit after getting errors like:
--- Code: ---Backtrace stopped: previous frame inner to this frame (corrupt stack?)
--- End code ---
--- End quote ---
Is this error stopping you from debugging? Is this happening in a night build?
As far as I can see the important part of the backtrace is there.
--- Quote from: scarphin on April 07, 2015, 01:15:41 am ---And I'm still not sure where to check for the faulty code as I didn't get an answer to my question:
--- Quote from: scarphin on April 01, 2015, 12:10:51 am ---Can you please point me to the piece of code where the frame info is parsed, is it 'GDB_driver::ParseOutput'?
--- End quote ---
--- End quote ---
I've answered this one - just use the debugger to find where the bad value is coming from.
scarphin:
--- Quote from: oBFusCATed on April 07, 2015, 03:27:46 am ---
--- Quote from: scarphin on April 07, 2015, 01:15:41 am ---Yes, many times but I quit after getting errors like:
--- Code: ---Backtrace stopped: previous frame inner to this frame (corrupt stack?)
--- End code ---
--- End quote ---
Is this error stopping you from debugging? Is this happening in a night build?
As far as I can see the important part of the backtrace is there.
--- End quote ---
If you're asking whether this error is stopping or crashing the debugger, no but it disallows me to inspect the variables and for a matter of fact this happens when the output is:
--- Code: ---(gdb) >>>>>>cb_gdb:
--- End code ---
This error occurs on my self-compiled cb rev10149 both 32-bit and 64-bit. I think I've located the piece of code responsible for parsing the output of 'bt 30' command in 'gdbCmd_Backtrace::ParseOutput' but setting a breakpoint doesn't make the debugger stop there when it's executed. Maybe it's never executed!? Anyway I'm done with tracing that, it's too complicated for me and I'm lost.
--- Quote from: oBFusCATed on April 07, 2015, 03:27:46 am ---I've answered this one - just use the debugger to find where the bad value is coming from.
--- End quote ---
That is not an answer to my question but a very general advise to use a debugger to debug a bug.
oBFusCATed:
Of course it is general, but I have no time to debug it for you and then post backtraces and give suggestions. Also there is a chance that they will be invalid, because I've not debugged cb under windows for quite a long while, only under windows.
Are you using a night build to debug your self build cb?
If you're having problem with a night build then this is probably a bug and should be fixed.
Also if breakpoints are not hit then you can add printfs in order to make sure that the code is executed. I prefer to put deliberate crashing code -> int *a=NULL; *a=5; to verify some code is executed and my breakpoints are failing to hit.
Also if you hit the pause button and the debugger stop correctly, you can inspect the status of your breakpoints with the "info breakpoints" gdb command.
What you're looking in the output is "pending", no breakpoint should be pending, but should have a proper address, source file and line information.
If you have pending in the output you have some problem with the build and/or symbols.
scarphin:
I checked the latest nightly (rev10158) to see if something's going wrong with my build and not to my surprise the results were the same. Debug log is attached because of the 20000 char limitation.
'info breakpoints' just crushed gdb as you can see at the end of the build log. I tried crashing the debugger on purpose to see whether the code is being executed or not, and it did crash but the breakpoint was never hit without the crashing code inserted.
Btw, I never requested anyone to debug any code for me. I was just trying to trace a bug that occurs on a pure 64-bit cb build which seemed to be a necessity at the time. From what I see developers are quite confident that a 64-bit cb will never see the light of day. So I see no point in chasing that bug any further. Please ignore the whole thread to avoid any further inconvenience.
P.S. I deleted some of the frame responses manually to make the log length reasonable. The missing ones are pretty much the same as the last one.
oBFusCATed:
Hm, you've added a single breakpoint and the debugger stops at it.
Why are you saying that it fails to do so?
There is some mess after the info frame command. :(
Can you disable the function arguments and locals, so there is less noise in the output.
And also it is a bit safer without evaluating them.
Have you tried to debug cb.exe using command line debugger to verify that the gdb build you're using is working fine?
Also can you execute info breakpoints and bt 30 manually after the debugger stops on the first breakpoint.
p.s. I have nothing against win 64bit build, just I have no intention to work on it, because it is on the wrong OS.
p.p.s. I'm not sure if it is really good idea to pursuit cb 64bit+wx2.8.12. It will probably be easier to target wx3.0 directly.
p.p.p.s. Hm, but at work we are using minimal parts of wx2.6/2.8 in 64bit apps on windows with vc++/icc and there are no major problems.
p.p.p.p.s. My intention is to help, not be rude, sorry if I've offended you.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version