Detecting Race Conditions
-
- Posts: 5
- Joined: Mon Apr 06, 2015 1:43 pm
Detecting Race Conditions
Hi,
I was looking at the documentation and there is no direct reference to detecting or reporting Race Conditions in the Java Profiler.
Are these issues listed under a different tab or label?
Is there a specific workflow to follow to identify Race Conditions with this tool?
Thanks!
I was looking at the documentation and there is no direct reference to detecting or reporting Race Conditions in the Java Profiler.
Are these issues listed under a different tab or label?
Is there a specific workflow to follow to identify Race Conditions with this tool?
Thanks!
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Re: Detecting Race Conditions
You may try using the Deadlock detector:
https://www.yourkit.com/docs/java/help/deadlocks.jsp
Please also consider the Threads view:
https://www.yourkit.com/docs/java/help/threads.jsp
https://www.yourkit.com/docs/java/help/deadlocks.jsp
Please also consider the Threads view:
https://www.yourkit.com/docs/java/help/threads.jsp
-
- Posts: 5
- Joined: Mon Apr 06, 2015 1:43 pm
Re: Detecting Race Conditions
Hi,
Thanks for the prompt reply. Those are part of the documentation pages that I looked at.
Threads: https://www.yourkit.com/docs/java/help/threads.jsp
Deadlocks: https://www.yourkit.com/docs/java/help/deadlocks.jsp
Monitor Profiling: https://www.yourkit.com/docs/java/help/ ... filing.jsp
I just don't find any direct reference to detecting potential Race Conditions.
A race condition occurs when two threads operate on same object without proper synchronization causing operations to interleave on each other. This is basically the opposite from a deadlock.
I am trying to see if there is any report in the tool that would identify concurrent access to objects without proper locking, or unprotected concurrent read/write access to a locked object.
Thanks!
Thanks for the prompt reply. Those are part of the documentation pages that I looked at.
Threads: https://www.yourkit.com/docs/java/help/threads.jsp
Deadlocks: https://www.yourkit.com/docs/java/help/deadlocks.jsp
Monitor Profiling: https://www.yourkit.com/docs/java/help/ ... filing.jsp
I just don't find any direct reference to detecting potential Race Conditions.
A race condition occurs when two threads operate on same object without proper synchronization causing operations to interleave on each other. This is basically the opposite from a deadlock.
I am trying to see if there is any report in the tool that would identify concurrent access to objects without proper locking, or unprotected concurrent read/write access to a locked object.
Thanks!
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Re: Detecting Race Conditions
Hi,
Thank you for the clarification. Indeed, my suggestions were more about deadlock and synchronization rather than race conditions. Sorry for not being accurate.
I do not think there is a fully automated way to detect such situations (race conditions) in a generic case, i.e. to detect any unprotected access to each memory address (a field, an array element) in an application.
What are the objects in question? Are they from a known class or do they implement particular usage pattern? Could you please provide more detail, perhaps we'll be able to offer a custom solution for this.
We could use bytecode instrumentation to monitor object field access, but I'm afraid that without limiting the monitored object set the profiling overhead would be unacceptably high.
Best regards,
Anton
Thank you for the clarification. Indeed, my suggestions were more about deadlock and synchronization rather than race conditions. Sorry for not being accurate.
I do not think there is a fully automated way to detect such situations (race conditions) in a generic case, i.e. to detect any unprotected access to each memory address (a field, an array element) in an application.
What are the objects in question? Are they from a known class or do they implement particular usage pattern? Could you please provide more detail, perhaps we'll be able to offer a custom solution for this.
We could use bytecode instrumentation to monitor object field access, but I'm afraid that without limiting the monitored object set the profiling overhead would be unacceptably high.
Best regards,
Anton
-
- Posts: 5
- Joined: Mon Apr 06, 2015 1:43 pm
Re: Detecting Race Conditions
Hi,
Our group is coming from using Coverity Dynamic Analysis. That's the main reason for the original query. I can give you an example of the kind of reporting that tool provides and you can find out if it is possible within YourKit.
The potential issue is reported as:
Type: Data race condition
Category: Concurrent data access violations
An simple example with a race condition looks like:
Somehow, the Coverity Dynamic Analysis tool seems to be able to keep track of "field_read" and "field_write" operations from every thread and determine if they had a lock or not.
Clicking on the "field_read" or "field_write" line is the source code browser, shows the full stack trace. For instance,
field_write:
field_read:
field_read
I hope this helps.
Thanks!
Our group is coming from using Coverity Dynamic Analysis. That's the main reason for the original query. I can give you an example of the kind of reporting that tool provides and you can find out if it is possible within YourKit.
The potential issue is reported as:
Type: Data race condition
Category: Concurrent data access violations
An simple example with a race condition looks like:
Code: Select all
351 public JFrame getMainFrame() {
field_read: Thread "pool-1-thread-1" reads field "mainFrame" of class "com.company.common.framework.MyAppMain" while holding no locks.
field_read: Thread "AWT-EventQueue-0" reads field "mainFrame" of class "com.company.common.framework.MyAppMain" while holding lock 0x4976515e:com.company.common.browser.listselect.ExamModel.
352 return mainFrame;
353 }
354 public void setMainFrame( JFrame frame ) {
CID 44362 (#19-1 of 25): Data race condition (RACE_CONDITION)
field_write: Thread "AWT-EventQueue-0" writes field "mainFrame" of class "com.company.common.framework.MyAppMain" while holding no locks.
355 mainFrame = frame;
356 }
Clicking on the "field_read" or "field_write" line is the source code browser, shows the full stack trace. For instance,
field_write:
Code: Select all
com.company.common.framework.MyAppMain.setMainFrame
com.company.common.browser.service.MyServiceUtil.setFrameForContext
com.company.common.Installer$2.run
org.netbeans.core.windows.WindowManagerImpl$Exclusive$1.run
java.awt.event.InvocationEvent.dispatch
java.awt.EventQueue.dispatchEventImpl
java.awt.EventQueue.access$200
java.awt.EventQueue$3.run
java.awt.EventQueue$3.run
java.security.AccessController.doPrivileged
java.security.ProtectionDomain$1.doIntersectionPrivilege
java.awt.EventQueue.dispatchEvent
org.netbeans.core.TimableEventQueue.dispatchEvent
java.awt.EventDispatchThread.pumpOneEventForFilters
java.awt.EventDispatchThread.pumpEventsForFilter
java.awt.EventDispatchThread.pumpEventsForHierarchy
java.awt.EventDispatchThread.pumpEvents
java.awt.EventDispatchThread.pumpEvents
java.awt.EventDispatchThread.run
more...
Code: Select all
com.company.common.framework.MyAppMain.getMainFrame
com.company.common.browser.listselect.AsyncTableModel$2.preprocess
com.company.common.browser.listselect.QueryRunner.run
java.util.concurrent.Executors$RunnableAdapter.call
java.util.concurrent.FutureTask.run
java.util.concurrent.Executors$RunnableAdapter.call
java.util.concurrent.FutureTask.run
java.util.concurrent.ThreadPoolExecutor.runWorker
java.util.concurrent.ThreadPoolExecutor$Worker.run
java.lang.Thread.run
more...
Code: Select all
com.company.common.framework.MyAppMain.getMainFrame
com.company.common.browser.listselect.AsyncTableModel.clearContents
com.company.common.browser.service.examlist.ExamListProvider.handleSourceChange
com.company.common.browser.service.examlist.ExamListProvider.processLookupEvent
com.company.common.browser.service.examlist.ExamListProvider.resultChanged
org.openide.util.lookup.AbstractLookup$NotifyListeners.run
org.openide.util.lookup.AbstractLookup.notifyIn
org.openide.util.lookup.AbstractLookup.addPairImpl
org.openide.util.lookup.AbstractLookup.addPair
org.openide.util.lookup.AbstractLookup$Content.addPair
org.openide.util.lookup.InstanceContent.add
com.company.common.browser.service.nbp.CentralLookup.add
com.company.common.browser.service.events.EventBus.publish
com.company.common.browser.service.sourcelist.SourceListProvider.setSelectedSource
com.company.common.browser.sourcelist.controller.SourceListController.setSelectedSource
com.company.common.browser.sourcelist.action.SourceChangeAction.actionPerformed
javax.swing.JComboBox.fireActionEvent
javax.swing.JComboBox.setSelectedItem
com.company.common.browser.sourcelist.controller.SourceListController.setupSourceList
com.company.common.browser.sourcelist.SourceListTopComponent.componentOpened
com.company.common.browser.examlistcomposer.controller.ExamListComposerController.setupExamListComposer
com.company.common.browser.examlistcomposer.ExamListComposerTopComponent.componentOpened
org.openide.windows.WindowManager.componentOpenNotify
org.netbeans.core.windows.WindowManagerImpl.notifyTopComponentOpened
org.netbeans.core.windows.Central.addModeOpenedTopComponent
org.netbeans.core.windows.ModeImpl.addOpenedTopComponent
org.netbeans.core.windows.PersistenceHandler.initModeFromConfig
org.netbeans.core.windows.PersistenceHandler.load
org.netbeans.core.windows.WindowSystemImpl.load
org.netbeans.core.GuiRunLevel$InitWinSys.run
java.awt.event.InvocationEvent.dispatch
java.awt.EventQueue.dispatchEventImpl
java.awt.EventQueue.access$200
java.awt.EventQueue$3.run
java.awt.EventQueue$3.run
java.security.AccessController.doPrivileged
java.security.ProtectionDomain$1.doIntersectionPrivilege
java.awt.EventQueue.dispatchEvent
org.netbeans.core.TimableEventQueue.dispatchEvent
java.awt.EventDispatchThread.pumpOneEventForFilters
java.awt.EventDispatchThread.pumpEventsForFilter
java.awt.EventDispatchThread.pumpEventsForHierarchy
java.awt.EventDispatchThread.pumpEvents
java.awt.EventDispatchThread.pumpEvents
java.awt.EventDispatchThread.run
more...
Thanks!
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Re: Detecting Race Conditions
Hi,
Thank you for providing the detail.
Do I get it right that you refer to the functionality described in http://www.coverity.com/library/pdf/Cov ... alysis.pdf ?
We don't offer exactly this kind of analysis at this moment, but can consider its addition in a future version.
Is it true that you don't need to configure the classes to monitor for possible race conditions, but they are detected in entire code of your application? Or do you have to use any filters to limit the monitored class scope? And how big is the overhead of such monitoring of your application under Coverity?
Best regards,
Anton
Thank you for providing the detail.
Do I get it right that you refer to the functionality described in http://www.coverity.com/library/pdf/Cov ... alysis.pdf ?
We don't offer exactly this kind of analysis at this moment, but can consider its addition in a future version.
Is it true that you don't need to configure the classes to monitor for possible race conditions, but they are detected in entire code of your application? Or do you have to use any filters to limit the monitored class scope? And how big is the overhead of such monitoring of your application under Coverity?
Best regards,
Anton
-
- Posts: 5
- Joined: Mon Apr 06, 2015 1:43 pm
Re: Detecting Race Conditions
Hi,
Yes, I am referring to the functionality described in the link you provided. There is also this link http://www.coverity.com/library/pdf/Cov ... alysis.pdf with a different view of the same information.
There no configuration required to specifically detect race conditions. You start the Dynamic Analysis "broker" and start the application to profile with a Dynamic Analysis Java agent.
The Java agent performs the profiling and communicates with the Coverity broker to capture any issue in the concurrency defect categories they support:
Thanks!
Yes, I am referring to the functionality described in the link you provided. There is also this link http://www.coverity.com/library/pdf/Cov ... alysis.pdf with a different view of the same information.
There no configuration required to specifically detect race conditions. You start the Dynamic Analysis "broker" and start the application to profile with a Dynamic Analysis Java agent.
The Java agent performs the profiling and communicates with the Coverity broker to capture any issue in the concurrency defect categories they support:
- Race Conditions
- Deadlocks
- Resource Leaks
Thanks!
-
- Posts: 5
- Joined: Mon Apr 06, 2015 1:43 pm
Re: Detecting Race Conditions
Hi,
Is the latest information useful, or do you need more details?
Thanks!
Is the latest information useful, or do you need more details?
Thanks!
-
- Posts: 6172
- Joined: Wed Aug 11, 2004 8:37 am
Re: Detecting Race Conditions
Hi,
I think the information we've got is enough for now, thanks again for providing it. It is indeed useful.
We're considering adding such new functionality, but I cannot promise any availability dates yet. Anyway, this new stuff will (if will) go to the version after the recently released version 2015. As usual, you may test new features as early as possibly by using the Early Access Program builds. Please stay tuned
Best regards,
Anton
I think the information we've got is enough for now, thanks again for providing it. It is indeed useful.
We're considering adding such new functionality, but I cannot promise any availability dates yet. Anyway, this new stuff will (if will) go to the version after the recently released version 2015. As usual, you may test new features as early as possibly by using the Early Access Program builds. Please stay tuned
Best regards,
Anton