EDT violations certainly can cause behavior like this, provided these components interact with Swing components in some way (say they are attached as listeners on components). Of course, you could turn the tables on them and ask them if they have assertions on these methods and that if you enable assertions will the code clearly show where the EDT rule is violated.
Edit (in response to comment):
The basic rule of thumb with the EDT is that whenever you start a new thread do not touch any Swing component (or anything that touches a Swing component, such as a Model) without wrapping that code in a Runnable and calling SwingUtilities.invokeLater(Runnable). It takes dicipline and some extra design effort, but it is definitely necessary in any serious application.
If you have a serious amount invested in syncronous behavior (such as poping up a dialog and waiting for an answer) you can call SwingUtilities.invokeAndWait(Runnable), but you should try to avoid the need for that as much as possible. Also, make sure you call that method while not on the EDT, it doesn't work otherwise.
One way to start getting such code under control is to use asserts like this:
assert (EventQueue.isDispatchThread())
whereever you have code that touches the GUI and run with asserts enabled. That way you will see exact code paths that are touching Swing components incorrectly.