Counting breakpoint hits - eclipse

As this question is over 3 years old, I figured I'd bring it up again. Especially since the solution offered there isn't a real option for me.
I'm looking for a way to count passes over a particular breakpoint in the eclipse debugger without actually suspending the code. I need to do this because the issue I'm working on manifests itself only when thousands of messages are sent per second.
The solution offered above is not really feasible for me, as the code being debugged is in a remote location and I cannot really create the static class to track hits. Is there either a default feature or a plugin that will simply count breakpoint hits, or is it not possible in eclipse?

Actually in said question the only reason to use another class is to have a dedicated static variable that you can access from the breakpoint snippet. You can use any other static variable/method that is visble to the snippet.
For instance:
int a = System.getProperty("my-prop");
System.setProperty("my-prop", ++a);
That might be slow, so you could try with ThreadLocals or find youself a static var (or preferably a map to track many places) that you can hijack for this purpose.

Related

vscode: multiple extensions for one language

Is it specified somewhere what happens if I install multiple extensions that declare support for the same language? I can see that if the provided functionality doesn't overlap, then all is fine and I get everything. But if two extensions want to provide completion or hover info, for example, I'm not sure which one provides the answers or if they are merged (where applicable). Does anyone know?
I am not aware of any issues with multiple extension for the same thing, atm I am using a bunch for XML and while they tend to play nice together I've noticed that there are cases that if 1 crashes it might affect the others as well.
In my case a styling extensions was breaking from time to time and in turn my own extension was not getting called but it occurred relatively at random as some times this was not the case.
To me it appears that if - for example - there is an uncaught exception it happens

Eclipse-Plugin: Program Counter position

I am about to break here into pieces. I asked in the forum community, I asked the developer list and I already asked on stackoverflow.
Where is that code-line that just moves that program-counter annotation to that line that I want it to move?
Speaking of highlighting the line which is currently executed during debug.
I've checked out
org.eclipse.cdt.debug.core
org.eclipse.cdt.debug.ui
org.eclipse.cdt.dsf.gdb
org.eclipse.cdt.dsf.gdb.multicorevisualizer.ui
org.eclipse.cdt.dsf.gdb.ui
org.eclipse.cdt.tests.dsf.gdb
org.eclipse.cdt.ui
org.eclipse.cdt.visualizer.core
org.eclipse.cdt.visualizer.ui
but I coldn't find a line that just does this.
foo = new ObjectThatDoesWhatINeed();
foo.highlightLine(lineNumber);`
I'm freaking out here since I stuck there for a week now and this should not be such a huge thing since I suppose that Eclipse is designed to re-use functionalities, right?
How about adding a breakpointListener and then using AST to identify current cursor position?
From the extension point description (bold mark by me):
Allow clients to contribute listeners for Java breakpoint
notifications. For example, listeners are called when a breakpoint is
hit and about to suspend execution. The listener can vote to resume or
suspend the debug session. Listeners can be programmatically added to
and removed from specific Java breakpoints (specified by breakpoint
listener identifers), or be registered to listen for notifications for
all Java breakpoints.
The Extension Point is called:
org.eclipse.jdt.debug.breakpointListeners
That visualization is not specific to the CDT plugin, so you will surely find it in the generic org.eclipse.debug.ui instead.
Looking at the extensions defined in that plugins manifest.mf, there is an annotation type called org.eclipse.debug.ui.currentIP, which might be the one for the current instruction pointer. But this is just guessing.

How do I watch a variable in real-time when debugging on Eclipse?

I'm trying to watch a variable change in Eclipse's debug while my program run. But I can only find how to watch a variable when I have a breakpoint set, which pauses the program. I wanna watch the variable change in the eclipse window, while I'm using the program, without having the program pause each time the variable changes.
Is there any way to do that?
There is not a way to do this that I'm aware of. The closest I could imagine is to have a thread that captures the thing you want to monitor and periodically prints its value. You might have to synchronize access to that object at that point since multiple threads could be touching it.
For varX
Add System.out.println("varX = " + varX);
and see in console, or LogCat under tag = System.out
PS
You can see this answer in the link below, voted down! "Programmers" hate the simple solution, and for this reason the question remains unanswered.
Watching variables contents in Eclipse IDE

Adding code to class files just before building - Objective C

I am looking to develop a framework, for which I dont want get into details.
Suppose if I am having 100+ classes with 1000+ methods in my iPhone application.
In this scenario I want to add NSLog in each method(at start or end or both) of each class.
Manually adding NSLog is possible but is there any better solution?
Like building application in such a way that I can add this Log without me having to do manual work.
Thanks and Regards,
Denis,
Your answer was most useful throughout many forums.
Thanks a lot.
The reason I'm looking for something like this is, we have many client projects and many time it happens that we get some crashing or other issues while QA and UAT. ~80% of them are not reproducible or require some particular scenario. We were using .crash and dsym to track such issues. But it is not that useful in such scenario.
What I'm looking for is providing add hoc build which will log the steps which user has followed so that it will make easy to reproduce such issues.
Currently I am using precompiled headers and first method you have mentioned (searching for the first opening brace then replace it with macro).
I will look into DTrace and objc_msgSend as you mentioned. I will google out these meanwhile if you have any preferred tutorials it will be great.
Thanks and Regards,
:D
So you want to add a trace facility to your code?
Apple doesn't provide anything like this. You'll have to add your trace facility yourself. If your source code style is consistent, this might be relatively easy to do automatically, something like searching for the first opening brace following a line starting with a minus (or plus) sign...
Alternatively, you might want to use the public Objective-C runtime functions to enumerate all classes and all their methods, then method-swizzle each of them with another one that NSLog before jumping to the original.
Alternatively, you can take the open source implementation of objc_msgSend and insert a call to NSLog at the beginning. Note that obj_msgSend tail calls into the method, so that will prevent you from adding a call upon return. Be prepared to humongous output of course. You might want to condition your call to NSLog to the value of the selector parameter to objc_msgSend (such as a common prefix).
Finally, the best way to trace is probably to attach a DTrace probe to the entry to objc_msgSend. For the same tail-call reason mentioned above, you won't be able to attach a DTrace probe to its return though.
But the better question is why do you want to do that.

TODO/FIXME plugin for Eclipse

In my project there are large no. of FIXME / TODO which are to addressed at some point of time. Actually there about 480 which can be seen from 'TASKS' list but not organised.
I googled and found the Task Tag Decorator plugin.
But unfortunately this is not working.
Can anyone suggest a plugin for FIXME/TODO
apart from this.
I would also wanted to hear from all how these situations are usually managed
What you don't want to hear is that how these situations are usually managed is by not letting them grow so big. But I'm afraid that is the case.
The Pragmatic Programmers advise us Don't live with broken windows. The point being, that if we leave something broken instead of fixing it then other things will be left and before we know it we have 480 items on our TODO list. Plus, there is a danger that some part of our application will come to rely on the "broken" behaviour, so when we address the TODO item we also have fix that as well.
Not everybody can live up to the Pragmatic Programmers' high standards. An alternative approach is to have a list of stuff which needs to be worked on (sometimes known as the Kaizen list). People who are blocked on their assigned work can pick up one of those tasks.
As for your current situation....
I have a rule of thumb which states that nothing can be done in less than half-a-day: not once you include source control, documentation, discussing the change with Bob, etc. Of course, my rule of thumb doesn't apply to truly trivial tasks, but if these tasks were truly trivial they would have been fixed on the spot, not marked as TODO, right?
So you're looking down the barrel of 240 days of effort. If lots of those tasks can be combined into a single fix then you can reduce the per task overhead. But first you've got a chunk of work just to sift through the tasks, categorising and prioritising them. This is why thay call it "technical debt": the longer we leave it the more it costs to fix, and it has the compound interest rate of the average doorstep loanshark.
Unless you have a very understanding project manager/paying customer I think you will have to accept that you aren't going to be able to clear all these items. So you need a brief triaging exercise: assign each TODO into one of three categories:
Stuff that is intolerable and needs
to be fixed right now
Stuff that ought to be fixed as and
when there is an opportunity
Stuff that you're just going to have
to live with
Good luck!
Just wanted to chime in and say that I was able to get the Task Tags Decorator working in eclipse 3.5.0. Here's how.
Install from the update site : Task Tags Decorator Update Site
In preferences: General->Appearance->Label Decorators->Task Tag Decorators
Set up your decorators there.
Then go to: General->Appearance->Label Decorators and check the "Task Tag Decorator" box and Apply
I found this very frustrating to figure out and I hope it helps others. I really like the plugin and have found it helpful for me to visually keep track of TODOs. I think it also helps me keep the TODO list short since it's not out-of-sight-out-of-mind.
In what way do you want them to be organised? More specifically what doesn't the Task View do that you want to do?
For information you can do the following with the standard tasks view:
Click each column header in the task view to sort by that column ascending/descending.
Select the View Menu (downward triangle in top right of view) and
Group tasks by type
Show only a particular task type
Select Configure Contents... then :
Select a Scope to restrict the tasks shown to your desired scope (I find On selected element and its children particularly handy).
Filter tasks by description text (using contains or does not contain)
Filter based on Priority and/or Completed status and Task Type
There are also a few other options you may find useful if you dig through the View Menu.
You might want to look into Mylyn.
It might also be worth considering what it means to use one of these tags.
The trouble is that if you have almost five hundred of these things it doesn't seem likely that you are going to be able to delete them as 'stuff to do' at any point soon. Thus, the impact of using the tag and the process implied therein is diminished, and you end up with the problem you are citing, that the data set has become unmanageable.
The point is that the code is the truth, not the comments, whether they are marked up with task tags or not. You have to have something measurable by which you improve the code.
As an example, when I do code reviews I use these tags in a first pass before the code review pairing begins. The aim is that by the time the code review is complete the tags do not exist.