Author Topic: Frame issue with the debugger plugin  (Read 39891 times)

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Frame issue with the debugger plugin
« Reply #15 on: April 07, 2015, 03:27:46 am »
Yes, many times but I quit after getting errors like:
Code
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
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.

And I'm still not sure where to check for the faulty code as I didn't get an answer to my question:
Can you please point me to the piece of code where the frame info is parsed, is it 'GDB_driver::ParseOutput'?
I've answered this one - just use the debugger to find where the bad value is coming from.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Frame issue with the debugger plugin
« Reply #16 on: April 07, 2015, 05:51:28 pm »
Yes, many times but I quit after getting errors like:
Code
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
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.
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:
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.

I've answered this one - just use the debugger to find where the bad value is coming from.
That is not an answer to my question but a very general advise to use a debugger to debug a bug.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Frame issue with the debugger plugin
« Reply #17 on: April 07, 2015, 09:01:24 pm »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Frame issue with the debugger plugin
« Reply #18 on: April 08, 2015, 12:10:07 am »
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.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Frame issue with the debugger plugin
« Reply #19 on: April 08, 2015, 01:12:51 am »
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.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Frame issue with the debugger plugin
« Reply #20 on: April 08, 2015, 12:40:36 pm »
Hm, you've added a single breakpoint and the debugger stops at it.
Why are you saying that it fails to do so?
Because it's the breakpoint:
Code
[debug]> break "D:/coding/projects/sw/codeblocks/trunk/src/plugins/debuggergdb/gdb_commands.h:1207"
[debug]Breakpoint 3 at 0x6daaa2d1: file D:/coding/projects/sw/codeblocks/trunk/src/plugins/debuggergdb/gdb_commands.h, line 1207.
at line 142 of the debug log that it doesn't stop.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Frame issue with the debugger plugin
« Reply #21 on: April 08, 2015, 08:53:39 pm »
It has stopped on the breakpoint and then you've hit the continue button. According to the log.
Have you hit the continue button?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Frame issue with the debugger plugin
« Reply #22 on: April 09, 2015, 01:13:42 am »
No, unfortunately.

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Frame issue with the debugger plugin
« Reply #23 on: April 09, 2015, 03:47:18 am »
There are 2 bugs regarding the original problem.
1- The reason for the invalid frame numbers are the 'ToULongLong' conversions in 'GdbCmd_Backtrace::MatchLine' function in 'gdb_commands.h'. There is a bug report here:
http://trac.wxwidgets.org/ticket/13282
2- 'm_number' is defined as 'int' in the 'cbStackFrame' class but it is converted to and from a 'size_t' type in the previously mentioned function. It should be defined as 'ssize_t' if it's required to be a signed type, 'size_t' otherwise. Also 'validFrameNumber' variable in function 'GdbCmd_Backtrace::ParseOutput' should match 'm_number's type.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Frame issue with the debugger plugin
« Reply #24 on: April 09, 2015, 09:05:03 am »
Thanks for the digging this up. I'll see what can be done to fix it.

Can you try to build the test project (see in the debuggergdb folder)?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Frame issue with the debugger plugin
« Reply #25 on: April 09, 2015, 10:52:28 am »
Test suite also has the failures for 64-bit:
Code
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:20:1: error: Failure in match0_number: Expected 0 but was 1
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:51:1: error: Failure in match1_number: Expected 8 but was 1
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:58:1: error: Failure in match1_address: Expected 2010416948 but was 5029592
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:90:1: error: Failure in match2_number: Expected 9 but was 8
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:97:1: error: Failure in match2_address: Expected 1770750 but was 2292016
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:128:1: error: Failure in match3_number: Expected 30 but was 135
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:135:1: error: Failure in match3_address: Expected 4209674 but was 5029592
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:166:1: error: Failure in match4_number: Expected 31 but was 1
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:173:1: error: Failure in match4_address: Expected 4224714 but was 5029592
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:204:1: error: Failure in match5_number: Expected 50 but was 0
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:211:1: error: Failure in match5_address: Expected 4263052 but was 3437753
D:\coding\projects\sw\codeblocks\trunk\src\plugins\debuggergdb\debuggergdb_test_backtrace.cpp:246:1: error: Failure in match6_number: Expected 0 but was 2291536
FAILURE: 12 out of 116 tests failed (12 failures).
Test time: 0.10 seconds.

No failures for 32-bit.

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Frame issue with the debugger plugin
« Reply #26 on: April 09, 2015, 02:37:49 pm »
As an example following approach works for 64-bit:
Code
size_t number, address;
number = strtoull(reBT1.GetMatch(line, 1).mb_str(), nullptr, 10);
address = strtoull(reBT1.GetMatch(line, 2).mb_str(), nullptr, 16);
I think it is also safe considering the regex pattern is ascii (to my understanding).

'strtoull' should be 'strtoll' for signed conversions. Is there a need for 'cbStackFrame::m_number' to be signed?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Frame issue with the debugger plugin
« Reply #27 on: April 10, 2015, 01:02:48 am »
I don't like the usage of size_t and ssize_t. If you think something should be a particular size then it is better to use int64_t or uint64_t.

About test suite - it is great that it fails, so testing will be a bit easier.
I don't think there is a reason to use 64bit number for the frame, but the address must be 64bit, probably it always has to be 64bit.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline scarphin

  • Lives here!
  • ****
  • Posts: 644
Re: Frame issue with the debugger plugin
« Reply #28 on: April 10, 2015, 03:29:00 am »
Attached patch fixes the 'ToULongLong' problem and the conversion problems between incompatible types. All debugger tests for both 32-bit and 64-bit pass with this patch. 'cdb' part needs testing though.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Frame issue with the debugger plugin
« Reply #29 on: September 27, 2015, 03:50:57 pm »
@Morten: Do you have any idea why you've added calls to ToULongLong instead of ToULong for the Windows 64bit builds in revision 9038?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]