Opened 2 years ago

Closed 2 years ago

#13710 closed bug (fixed)

Debugger's ListView has problems with recursive functions

Reported by: KapiX Owned by: anevilyak
Priority: normal Milestone: Unscheduled
Component: Applications/Debugger Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All


If there is a recursive function on the stack, then clicking on them will move to code for the first on top. Example:

  • ...
  • RemoveView(1)
  • RemoveView(2)
  • ...

Clicking on 2 for the first time will move to the code for 1. Clicking second time works.

Can be tested by removing ->View() from [1] and [2], then running [3] script. Application will crash on exit and call stack should have two RemoveView functions.




Change History (6)

comment:1 by anevilyak, 2 years ago

Will try to dig into it this weekend. In case it makes a difference, which compiler were you using for the app?

comment:2 by KapiX, 2 years ago

hrev51382 x86_64 GCC 5.4.0 (2016_06_04)

comment:3 by anevilyak, 2 years ago

I've tried several different things, and thus far I've been unable to reproduce this problem, neither with your specific example, nor with a simplified testcase of a generic recursive function. To be clear, I've tried it with your tabview branch with the specified changes, and the makefile configured with debug enabled, and optimizations disabled (and enabled, without any difference). I've also tried it with and without a debug libbe included in the app's path, as well as starting the interpreter from the debugger directly vs letting the app run free until crash and attaching the debugger from the crash dialog. In none of the above circumstances am I able to cause the mentioned listview behavior to occur.

Since you've been working on the tab view recently, is there any chance you have any other local changes to libbe that might be interfering in some way?

comment:4 by KapiX, 2 years ago

No, the code in question is not related to tab view at all, actually.

Anyway, I've tried it, and removing ->View() from line 3465 and adding -g to GPP_OPT allowed me to reproduce this. What I'm seeing:

YabInterface::RemoveView(BView*) + 0x1c
YabInterface::RemoveView(BView*) + 0x93

When you click on 0x93 first it goes to if(child = myView->childAt(0)). OK, fine. 0x1c - code doesn't change, the same line. 0x93 again - RemoveSelf(t); huh?

If I click on 0x1c first, then it behaves correctly (0x93 takes me to RemoveSelf(t);).

comment:5 by anevilyak, 2 years ago

Ahh, that helps clarify things. I was parsing your problem description as the wrong row in the listview being highlighted. Will dig more tomorrow.

comment:6 by anevilyak, 2 years ago

Resolution: fixed
Status: newclosed

Should be fixed in hrev51423.

Note: See TracTickets for help on using tickets.