Fully featured low overhead profiler for Java EE and Java SE platforms.
Ultimate profiling and monitoring solution for Gradle, Maven, Ant, JUnit and TestNG.
Easy to use performance and memory profiler for .NET framework.

Detecting Race Conditions

Moderators: Vladimir Kondratyev, Anton Katilin

Detecting Race Conditions

Postby fernandeyourkit » Mon Apr 06, 2015 1:50 pm

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!
fernandeyourkit
 
Posts: 5
Joined: Mon Apr 06, 2015 1:43 pm

Re: Detecting Race Conditions

Postby Anton Katilin » Mon Apr 06, 2015 3:47 pm

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
Anton Katilin
 
Posts: 5574
Joined: Wed Aug 11, 2004 8:37 am

Re: Detecting Race Conditions

Postby fernandeyourkit » Mon Apr 06, 2015 8:46 pm

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!
fernandeyourkit
 
Posts: 5
Joined: Mon Apr 06, 2015 1:43 pm

Re: Detecting Race Conditions

Postby Anton Katilin » Tue Apr 07, 2015 3:45 pm

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
Anton Katilin
 
Posts: 5574
Joined: Wed Aug 11, 2004 8:37 am

Re: Detecting Race Conditions

Postby fernandeyourkit » Tue Apr 07, 2015 5:22 pm

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:
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  }


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:
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...

field_read:
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...

field_read
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...


I hope this helps.

Thanks!
fernandeyourkit
 
Posts: 5
Joined: Mon Apr 06, 2015 1:43 pm

Re: Detecting Race Conditions

Postby Anton Katilin » Wed Apr 08, 2015 11:03 am

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
Anton Katilin
 
Posts: 5574
Joined: Wed Aug 11, 2004 8:37 am

Re: Detecting Race Conditions

Postby fernandeyourkit » Wed Apr 08, 2015 9:51 pm

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:
  • Race Conditions
  • Deadlocks
  • Resource Leaks

There is very little overhead. I am not sure what they do.

Thanks!
fernandeyourkit
 
Posts: 5
Joined: Mon Apr 06, 2015 1:43 pm

Re: Detecting Race Conditions

Postby fernandeyourkit » Fri Apr 10, 2015 6:21 pm

Hi,

Is the latest information useful, or do you need more details?

Thanks!
fernandeyourkit
 
Posts: 5
Joined: Mon Apr 06, 2015 1:43 pm

Re: Detecting Race Conditions

Postby Anton Katilin » Mon Apr 13, 2015 8:23 am

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
Anton Katilin
 
Posts: 5574
Joined: Wed Aug 11, 2004 8:37 am


Return to Java Profiler

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 5 guests

cron