Lets say I have a class that initiates two threads Thread_A and Thread_B, each doing some calculations and ocassionally using a subroutine of my the class. (don't worry about data sharing, lets say it's a log line or imagine the subroutine is a method in a Java library) I want to know if there is a way of conditioning a breakpoint inside this subroutine to the subroutine having been called from say thread_A, but not B, or say a certain breakpoint having been hit prior to this breakpoint.
Obviously I can always go tho the frames tab in the debug window and see the caller thread, but it is tedious. It might be the case that thread_A accesses the subroutine much less often than thread_B. I don't want to have to see all the breakpoints which are initiated by Thread_B.
The way I currently do it, is setting up global flag variables and manipulating them just before calling the routine. I then have my breakpoint's condition depened on the flag variable. However that is probably not very thread-safe and not very clean.
What is the correct way of doing this? Out of curisoity, is there any other IDE for any other language that does this?
is the code that spwaned the threads your's ?
if so you could set unique names on the threads and use those names to
distinguish your threads when using breakpoint conditions.
e.g.
//spwaning the thread
Thread threadA=...
threadA.setName("thread-A");
// IntelliJ
Condition : Thread.currentThread().getName().equals("thread-A")
Related
Whenever adding a breakpoint to the line of a method declaration (in Intellij IDEA or Android Studio), a popup appears:
Method breakpoints may dramatically slow down debugging
Why would it dramatically slow down debugging, is my question? What is different about putting the breakpoint on the first line of the function?
Thanks!
I looked around a little, and saw this post in the Intellij Documetation:
Method Breakpoint
Method breakpoints act in response to the program entering or exiting a particular method. They let you target your debugging sessions by method you wish to investigate, rather than by line number. Method breakpoints let you follow the program flow at the method level as well as check entry and exit conditions. Note that using method breakpoints can slow down the application you are debugging.
I guess it stops the program right before it enters the method, so that you can evaluate the parameters and such before entering the method.
The reason it dramatically slows down is (This is what I can gather, because that is all I could find on method breakpoints in Intellij's documentation) that it has to:
let you follow the program flow at the method level as well as check entry and exit conditions
and I suppose that would take a lot longer than just halting the program's execution
My understanding is that the code must be run interpretively (instead of using JIT to pre-compile?) when the breakpoint is set on method entry.
If you set the breakpoint on the first line of the method instead, I suspect a line number index into the code can be used to simply swap a break opcode for the original opcode, so the app runs full speed. (which still seems pretty slow to me when debugging ;)
There is a simple explanation from the IntelliJ Team: "Method breakpoints will slow down debugger a lot because of the JVM design, they are expensive to evaluate"
https://intellij-support.jetbrains.com/hc/en-us/articles/206544799-Java-slow-performance-or-hangups-when-starting-debugger-and-stepping
This is my situation:
I am studying a large codebase, running on Java1.7, not very easy to move around, lots of interfaces, deep inheritance trees, lots of threads etc.
I put a breakpoint in some place, but this object is running in a Thread that was spawned somewhere. I need to find that place.
there are too many .run() and .start() hits to look for individually (and to narrow down by the class is difficult too as there are many classes/inheritance (and I don't know the codebase yet)).
So my questions is, is there a way, having a Thread stopped in a breakpoint (intelliJ, but I can use eclipse too) to find out where it was started??
thanks
Maybe you can put breakpoint into Thread.start().
To avoid mutltiple invocation of breakpoint, maybe it make sense to place breakpoint with conditional logic, for example checking global boolean flag. For example, you suspect, that your code invokes right before some event, when event happens, put global flag to true.
No.
I don't think there's a way out of this without some brute force effort.
I would trace back to the Runnable that was started (through the stack trace), then get that class' inheritance and interface hierarchy, then look for run() and start() methods on all those classes. Unless someone has just gone nuts with inheritance, it shouldn't take that long.
Breaking on the code in your object tells you which thread it is and its call stack can tell you which Runnable you should be looking for. I'm assuming you've already gotten this far and that it's not enough to find all the references to this Thread/Runnable. In that case you can write a wrapper class for java.lang.Thread that does an instanceof/type check in the run() and setting your breakpoint there
I think first you have to get the Runnable that is run. That's simple as it's always the first line of your stack trace. (Of course you need the concrete class and not the one that defines the run method.) Once you have the class it should be easy to find the instantiation. Then it should simple to follow to the point where the thread is started. Did I miss something?
By way of some library, I find myself calling this function twice concurrently on a single instance (using the implementation returned by Executors.newSingleThreadScheduledExecutor). The Runnable passed to the second call seems not to execute, neither immediately nor on the next scheduled slot, and no exception is raised. If I serialize the two calls (did this very crudely and unintentionally by putting a breakpoint before the second caller's scheduling call), then the second runnable is executed with no issue.
I'm new to this interface, but it doesn't seem like these scheduling functions are designed to be reentrant. But I can't find anything in the various documentation describing what should happen here.
Well, small test case doesn't reproduce the problem, so I have no reason to believe the function isn't reentrant. What actually fixed the problem was to remove all this from request time to server start. There were some other signs, like the breakpoint temporary fix I mentioned in the OP, that point to some awful timing issue, somewhere in my stack.
How can I find out who created a Thread in Java?
Imagine the following: You use ~30 third party JARs in a complex plugin environment. You start it up, run lots of code, do some calculations and finally call shutdown().
This life-cycle usually works fine, except that on every run some (non-daemonic) threads remain dangling. This would be no problem if every shutdown was the last shutdown, I could simply run System.exit() in that case. However, this cycle may run several times and it's producing more garbage every pass.
So, what should I do? I see the threads in Eclipse's Debug View. I see their stack traces, but they don't contain any hint about their origin. No creator's stack trace, no distinguishable class name, nothing.
Does anyone have an idea how to address this problem?
Okay, I was able to solve (sort of) the problem on my own: I put a breakpoint into
Thread.start()
and manually stepped through each invocation. This way I found out pretty quickly that Class.forName() initialized lot of static code which in return created these mysterious threads.
While I was able to solve my problem I still think the more general task still remains unaddressed.
I religiously name my threads (using Thread(Runnable, String), say), otherwise they end up with a generic and somewhat useless name. Dumping the threads will highlight what's running and (thus) what's created them. This doesn't solve 3rd party thread creation, I appreciate.
EDIT: The JavaSpecialist newsletter addressed this issue recently (Feb 2015) by using a security manager. See here for more details
MORE: A couple of details for using the JavaSpecialist technique: The SecurityManager API includes "checkAccess(newThreadBeingCreated)" that is called on the thread creator's thread. The new thread already has its "name" initialized. So in that method, you have access to both the thread creator's thread, and the new one, and can log / print etc. When I tried this the code being monitored started throwing access protection exceptions; I fixed that by calling it under a AccessController.doPriviledged(new PrivilegedAction() { ... } where the run() method called the code being monitored.
When debuging your Eclipse application, you can stop all thread by clicking org.eclipse.equinox.launcher.Main field in the debug view.
Then from there, for each thread you can see the stack trace and goes up to the thred run method.
Sometimes this can help and sometimes not.
As Brian said, it a good practice to name threads because it's the only way to easily identify "who created them"
Unfortunately it doesn't. Within Eclipse I see all the blocking threads, but their stack traces only reflect their internal state and (apparently) disclose no information about the location of their creation. Also from a look inside the object (using the Variables view) I was unable to elicit any further hints.
For local debugging purposes, one can attach a debugger to a Java application as early as possible.
Set a non-suspending breakpoint at the end of java.lang.Thread#init(java.lang.ThreadGroup, java.lang.Runnable, java.lang.String, long, java.security.AccessControlContext, boolean) that will Evaluate and log the following:
"**" + getName() + "**\n" + Arrays.toString(Thread.currentThread().getStackTrace())
This will out the thread name and how the thread is created (stacktrace) that one can just scan through.
I'm using jdi interfaces to create a debugger and when I use MethodEntryRequests to enable method entry tracing the debugged program slows down by factor of tens. I have set filter for main thread and suspend policy to SUSPEND_EVENT_THREAD. Classfilter is limited and if I print any received events it doesn't show more than couple of dozen of those so it shouldn't receive too much of them. I'm debugging locally and having followind kind of command-line with the debugged java program:
-Xdebug -Xrunjdwp:transport=dt_socket,suspend=y,server=y,address=1337
The short answer is that execution runs through the interpreter when method entries are set. I don't think there is anyway around this...
This used to be the case for all code running in debug mode but it was enhanced in 1.4... now HotSpot works for 'full-speed' debugging except in the case of method entries and exits, watchpoints and when single stepping or in methods that contain breakpoints.
2 reasons:
it has to add checks on every method entry
(there is no option to tweak just some methods)
method inlining becomes impossible
(so small methods runs 10-100x times slower)
same goes to profilers and .net apps
I would assume that the debugger needs to wake up for every method call to see if it matches the one(s) that were selected to break. Because it has to check every method call for a potential match before it can execute it is considerably slower than if it does not have to do all these checks.