-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
1.3.1
-
generic
-
generic
This happens only in J2SE 1.3.x code.
I found a bug fix for "src/solaris/classes/sun/awt/motif/X11Selection.java".
Anyone entering the convertData method is going to hang. We ran into
this under when trying to do a "ctrl C" to copy text from a JTextArea
component. This only happened for us under the eXcursion window manager.
It doesn't enter this code when using CDE or Openlook (I tried it out on our
Sun machine). It appears that the code has been changed for 1.4 so it may
not be an issue for 1.4.
Basically, the method attempts to start a second thread to gather data and
places the current thread in a wait state until the other thread wakes it
up.
The problem is that someone forgot to start the other thread so it waits
indefinitely. I've pasted the method below with the 2 line fix. Look for
"PROPOSED FIX" to see the fix.
private byte[] convertData(int format) {
synchronized (lock) {
dataAvailable = false;
data = null;
currentFormat = format;
Runnable getData = new Runnable () {
public void run() {
synchronized (lock) {
try {
Map formatMap = MDataTransferer.getInstance().
getFormatsForFlavors
(contents.getTransferDataFlavors(),
flavorMap);
DataFlavor flavor = (DataFlavor)
formatMap.get(new Integer(currentFormat));
// Flavor can be null if some
application
// requested data in unsupported
format.
if (flavor != null) {
data =
MDataTransferer.getInstance().translateTransferable(contents, flavor,
currentFormat);
}
} catch (Exception e) {
e.printStackTrace();
data = null;
}
dataAvailable = true;
lock.notify();
}
}
};
/*
* PRPOSED FIX. This is a Sun bug. The
* lock.wait that follows assumes that a thread is gathering
* the data needed. Someone forgot to start the thread.
*/
Thread t1 = new Thread(getData);
t1.start();
SunToolkit.executeOnEventHandlerThread(dummyObj, getData);
while (!dataAvailable) {
try {
lock.wait();
} catch (InterruptedException ie) {
// do nothing
}
}
}
return data;
}
###@###.### - 12/14/01 :
Feedback from ###@###.###
The same hang is documented under bug id 4558745.
It happens only if Java application acquires the selection ownership
repeatedly while another application requests the selection data.
Note that this hang was fixed in 1.4.
Instead of starting a new thread we are executing this runnable on the
existing Java event dispatch thread:
> SunToolkit.executeOnEventHandlerThread(dummyObj, getData);
The deadlock occurs when the event dispatch thread is waiting for
the thread that executes convertData().
I found a bug fix for "src/solaris/classes/sun/awt/motif/X11Selection.java".
Anyone entering the convertData method is going to hang. We ran into
this under when trying to do a "ctrl C" to copy text from a JTextArea
component. This only happened for us under the eXcursion window manager.
It doesn't enter this code when using CDE or Openlook (I tried it out on our
Sun machine). It appears that the code has been changed for 1.4 so it may
not be an issue for 1.4.
Basically, the method attempts to start a second thread to gather data and
places the current thread in a wait state until the other thread wakes it
up.
The problem is that someone forgot to start the other thread so it waits
indefinitely. I've pasted the method below with the 2 line fix. Look for
"PROPOSED FIX" to see the fix.
private byte[] convertData(int format) {
synchronized (lock) {
dataAvailable = false;
data = null;
currentFormat = format;
Runnable getData = new Runnable () {
public void run() {
synchronized (lock) {
try {
Map formatMap = MDataTransferer.getInstance().
getFormatsForFlavors
(contents.getTransferDataFlavors(),
flavorMap);
DataFlavor flavor = (DataFlavor)
formatMap.get(new Integer(currentFormat));
// Flavor can be null if some
application
// requested data in unsupported
format.
if (flavor != null) {
data =
MDataTransferer.getInstance().translateTransferable(contents, flavor,
currentFormat);
}
} catch (Exception e) {
e.printStackTrace();
data = null;
}
dataAvailable = true;
lock.notify();
}
}
};
/*
* PRPOSED FIX. This is a Sun bug. The
* lock.wait that follows assumes that a thread is gathering
* the data needed. Someone forgot to start the thread.
*/
Thread t1 = new Thread(getData);
t1.start();
SunToolkit.executeOnEventHandlerThread(dummyObj, getData);
while (!dataAvailable) {
try {
lock.wait();
} catch (InterruptedException ie) {
// do nothing
}
}
}
return data;
}
###@###.### - 12/14/01 :
Feedback from ###@###.###
The same hang is documented under bug id 4558745.
It happens only if Java application acquires the selection ownership
repeatedly while another application requests the selection data.
Note that this hang was fixed in 1.4.
Instead of starting a new thread we are executing this runnable on the
existing Java event dispatch thread:
> SunToolkit.executeOnEventHandlerThread(dummyObj, getData);
The deadlock occurs when the event dispatch thread is waiting for
the thread that executes convertData().
- relates to
-
JDK-4558745 Deadlock occurs while copying
-
- Closed
-