This is the old problem which follows us for years...:-( When the BP hit occurs debugger shows the incorrect (first) frame stack in the "Frame Stack" window and obviously can't single step and display local variables. I need to manually set the correct frame (usually the only one I have in the list), as for example: #1 at ?? #2 at ?? #3 at MyFunctionName: #4 at ?? (?? is because I do not have debug versions of shared libraries). In my sessions this happens ALMOST always. I do not know how to narrow the case as can not catch the logic. The only one thing - this never happens in the main thread. Niko Sams once treated this issue and it became then better, but it was never solved finally. Reproducible: Sometimes
Can you try to get the same backtrace with gdb? Isn't it because of the lack of debug symbols?
No, I was not able to see this in plane gdb. Yes, I suppose, that this is connected somehow to the lack of debug info in libc/glibc & Co. I have this application in PC Linux (the problem is while in embedded Linux) and there is no such an issue there.
The issue is marked as WAITINGFORINFO for some reason. If I can provide additional info - I will be glad to help. Meanwhile, the only detail I can add is, that if the BP is not in the currently opened source file, the correct frame is not chosen in almost all cases.
please attach an example project that we can build locally and tell us where to set a breakpoint to reproduce the issue.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
Sorry, I can't understand how can I provide even the minimal project - as I said the issue is only with the embedded Linux debugging. So, if I even can minimize the project (which is not a simple job in itself) you will not be able to run it without my embedded target. Is there something else I can do to help to debug this? I am ready to everything...:-)
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!
I am really willing to help as possible. I will be happy to work close with a developer to solve the issue. In all versions of kdevelop the problem exists and is very very unpleasant - it is difficult to remember before any action on any BR occurrence first to go to "Frame Stack" and choose the correct thread. Sometimes, when you work hard to reproduce a problem, simulate the environment and finally arrive at the BP and make a step - BOOM, you are out of the code...:-((( So, please, connect me to the correct developer - I will do everything he/she will require! Just to solve this.
Hmm, I guess the problem is, unless somebody has an idea how to reproduce the issue on their local machine, it's not really possible to work on it :/
May be there is some way to collect debug information in some other way, except reproducing physically? I am willing to try, I want to solve this in any possible way. Just direct/conduct/guide me.