Well, it's a tough problem. The code asking for the clipboard contents
in EditorUI was added recently by Martin R. in order to fix issue
39678. I see no easy way how to make your requirement and fix for
issue 39678 to coexist. Starting and possibly killing a specialized
thread is IMHO a non-systematic solution and ideally we would like to
deal with the clipboard in AWT only in the editor as clipboard
handling tends to be  deadlock-prone e.g.
http://developer.java.sun.com/developer/bugParade/bugs/4502152.html  
So if possible I would like to not start a specialized thread to
examine the clipboard contents.

 As there are likely other places where the clipboard contents are
examined in order to keep the Paste action's enabled flag up-to-date
(e.g. in ExplorerActions.updatePasteAction()) I'm wondering whether
you did not hit the same problem in the past already?

I've seen the occasional hang in the past, but since I run netbeans
built from the trunk, not Q-builds, I don't worry about the occasional
hang.

But this started happening consistently - and of course, was very
irritating since there's a long setup time to get the debugee right to
the point you're interested in, hit a breakpoint and - freeze, no
chance to look at the bug you've finally narrowed down to.  So that's
why I spent the time to track down the issue to see what the problem is.

I think this bug is pretty bad. If the clipboard hang happens only on
Solaris, perhaps disable the fix for <other issue number here> on
Solaris only, or perhaps disable it only when the debugger is running,
or something like that.

Short of that, I think if we know that particular methods could hang,
we should never call them from the AWT thread since that can result in
data loss (lack of opportunity to save modified files, etc.). The
clipboard lookup method appears to be one such method.

We have verified that even if we disable our editor fix the IDE will
deadlock in the same way in the ExplorerActions so I have added Trung
to cc.
So at this point IMHO the only consistent and safe solution for the
longterm should be to stop asking the clipboard at all (in order to
determine the status of the Paste action) and enable the Paste action
at all times. The Paste action can fail and insert nothing but IMHO
that's acceptable from the user's point of view. We can possibly
search for better solution for promoD.
As this affects UI I'm asking the UI team to review that we can do
such change. I have added UI team to cc.

Paste action should be disabled if the clipboard is empty. So from the UI perspective it's 
not acceptable to have it always enabled.

So if we are to choose between two evils -- poorly responsive and
sometimes even freezing IDE on one hand and occasionally
inappropriately enabled Paste action on the other hand, from the QA
perspective, I choose the latter.

I agree with Honza and as we currently have no better solution for 3.6
we will rollback the fix of issue 39678 which will make the editor to
stop asking for the clipboard status. Dusane, please commit it. We
will then reassign to the core to check their part.

we can stop asking for clipboard status thus leave Paste always
enabled, but the user would run into a deadlock anyway if he tries
Ctrl+V in the IDE.  This would not be a proper fix

I also agree that it would be best to leave the Paste action always
enabled. (We already have enough performance problems asking the
system clipboard for its selection all the time.) If you try to paste
and there is nothing in the clipboard, it can beep.

Re. Trung's comment that you can still encounter the deadlock - only
if you had copied something from the debugged application, hit a
breakpoint, and tried to paste it. "Don't do that then." This seems a
pretty rare situation to me. Certainly not something you would run
into routinely like Tor's situation. Still a bug, but a much more
minor one IMHO.

Hanz, a different idea - is it possible for the debugger to force the
debugged process to always process clipboard handling events even if
the process is otherwise suspended? I guess this would be pretty
difficult in general since some required monitors might be owned by
other suspended threads, etc.

> Still a bug, but a much more minor one IMHO.

Trung: "still a bug, a P1 bug but happens less frequently"

Note at this stage it's not actually a bug in editor but in core.

Fix of issue 39678 rolled back in [maintrunk]

/cvs/editor/libsrc/org/netbeans/editor/EditorUI.java,v  <--  EditorUI.java
new revision: 1.61; previous revision: 1.60
done

/cvs/editor/libsrc/org/netbeans/editor/BaseKit.java,v  <--  BaseKit.java
new revision: 1.109; previous revision: 1.108
done

Mila, could you please review the fix. Thanks.

Visual diffs:
http://editor.netbeans.org/source/browse/editor/libsrc/org/netbeans/editor/EditorUI.java.diff?r1=1.60&r2=1.61
http://editor.netbeans.org/source/browse/editor/libsrc/org/netbeans/editor/BaseKit.java.diff?r1=1.108&r2=1.109

Approved.

Dusan, Mila, please explain the nature of Dusan's fix.

I suspect that the problem is completely elsewhere and we are trying
to fix the problem in a wrong place.

I've communicated w/ AWT engineers.  This is a design deficiency in
AWT.   The workaround should be done in our debugger.  Maros has
suggested a solution.  All the rest of the code  base should work with
NbClipboard/System Clipboard as usual.

Excerpt from my communication w/ AWT team:

---------------------
[...] wrote

> The problem is that there is timeout, indeed, but we don't allow to
> access it through any Java API. Ourselves, we set this timeout to
> a huge value (well, maxlong). This is needed because image transfer
> (which we do support) may take much more time than default 5 sec
> timeout.
>
> One of the solutions we could do in our code is to reduce the timeout,
> but still, it needs to be reasonably big (up to several minutes), which
> might still be not acceptable. Guess what you really need is some sort
> of API that would allow you to set timeout from inside Netbeans code.

Trung Duc Tran wrote:

>
> we are two weeks from our code freeze deadline and discovered this
> serious problem
>
> http://www.netbeans.org/issues/show_bug.cgi?id=40346
>
> I would call this a showstopper because of how easy it is to get the IDE
> into deadlock but it's amazing why no user noticed the problem so far.
>
> A short description of the problem:
>
> The user is using the IDE to debug a java app, let's call it Notepad.
> In Notepad which is running under the debugger, the user selects some
> text and puts it in the system clipboard.  Later on Notepad is suspended
> at a breakpoint.  The user switches back to the IDE which asks the
> system clipboard for its contents (to determine if the Paste action
> should be enabled, or just because the user hits Ctrl+V).  AWT passes
> the query to Notepad, the owner of the clipboard, which being suspended
> of course cannot answer.  We have a reliably reproducible deadlock.
>
> I would expect that Clipboard.getContents() would ether time out, or
> returns a Transferable immediately, but any calls to methods of that
> Transferable would time out.  Something in this spirit.  However I found
> no trace in AWT APIs which would allow me to do this.
>
> The only hack I can imagine at this moment is to spawn a thread and call
> into AWT Clipboard from there, have another thread or something to
> implement timeout ourselves.  If timeout expires, we would either call
> Thread.stop() or Thread.interrupt() on the clipboard caller thread.  But
> at that moment the clipboard caller is inside JNI code, Thread.stop() is
> officially unsafe and I have doubt that Clipboard.getContents() honors
> Thread.interrupt().  If it did then the method would throw
> InterruptedIOException.

just saw Dusan's HR request.  I disagree w/ the fix.  See my previous
comment

this problem in AWT should be worked around in debugger: whenever our
debugger is notified that the debuggee is suspended (it hits a
breakpoint for example) the debugger will clear the clipboards.

I'll attach Maros' patch  which demonstrates that the problem can be
fixed this way

Created attachment 13772 [details]
patch against debugger to work around the deadlock (by msandor)

the workaround is not side effect free.  Clipboard content is lost
when going from a debuggee back to the IDE after a breakpoint.  This
can be considered a P2 and I would say much less a problem than a
total deadlock

reassigning to debugger/msandor, also removed 36_HR_FIX keyword.

Maros, thanks

I prepared the patch on Trung's request but I'd rather not integrate 
it. The problem is, as Trung said, that everytime you hit a 
breakpoint (or do steps) in Netbeans debugger, the _system_ clipboard 
will be wiped out. I can imagine users wondering what the hell is 
Netbeans doing with their system-wide desktop clipboard even when 
debugging a remote j2ee server. Maybe we can come up with more 
elegant and solution? Or should we consider this a quick hack to be 
changed later?

Trungu, besides possible workarounding of the deadlock I still want
the original fix for issue 39678 to be removed (which is the current
state in the trunk) because of other reasons - mainly the possible
negative performance effect on the editor operation. With all the
elimination of unnecessary clipboard contents querying we would still
have to ask at least when focus arrives to the editor and assuming the
querying can take even more than a second with large clipboard content
it's IMHO undesirable.
 I believe that we should be able to find an acceptable solution for
promoD. In fact the only times when the clipboard status knowledge is
really needed is when the popup menu is invoked or when Ctrl-V is
pressed (so that we can beep or otherwise state that there is no
useful clipboard content for the editor). So we should be able to find
a solution that will ask lazily - at least in the editor case but
still retain the proper paste action status when "Edit" or popup menu
gets shown. However I would rather do it in promoD to ensure that
possible paste action enablement regressions that we could introduce
get fixed in time.

OK, I think this it is not a debugger issue, or at least not only 
debugger's. Anyway, a question for QE: Do you approve that we fix it 
Trung's way (deleting clipboard)? If so, I'll integrate the patch and 
we're done. If not, we should think about this more with involved 
people (debugger, core, editor).

How big will be the impact to the system clipboard.
User can have some important data in clipboard from other application
and you delete it?
Should be possible clear the clipboard only if the owner will be the
debugged application?

The impact is that we delete clipboard contents however important for 
a user it might be. We also cannot determine clipboard owner without 
causing the deadlock reported here. The best I can do from the 
debugger side is to put a hidden breakpoint in the 
Clipboard.setContent() method and if that hits then call some method 
in core. I'm open to simpler and more elegant solutions.

This is an AWT bug, filed by jglick and confirmed by JDK

http://developer.java.sun.com/developer/bugParade/bugs/4818143.html

What we are trying to do here is to find a workaround.  The workaround
I proposed is not perfect but at least eliminates one common case
(debuggee owns the clipboard).  There are other cases where we don't
have any workaround, see issue 40346 which I just close as WONTFIX.

Re Petr Felenda's comment above: one JDC user already came to the same
workaround I am proposing here (see the AWT bug URL)

   I think I found a workaround for this.
   I'm using KDE 3.1.x and I have Klipper started.
   Every time I want to use debugger (NB frooze when I wanted
   to use debugger) I clear the clipboard history with Klipper.
   Then it does work, but a bit slow.

Here we only tries to automate it for him

>>Here we only tries to automate it for him
I think there might be a danger in such automation, as the suggested
patch would eventually lead to a data loss that a user can not
control. Sounds like a P1 to me, so I'm not sure we will achieve
anything by that.

Why it is better than 'still a P1 bug but happens less frequently'
solution suggested by Jesse?

Re keeping Paste always enabled: this is easy for editor but very
complicated for the PasteAction provided by the platform.  I think we
can do it this late.  I'd rather ask for waiver and document it in the
release note than going into such a dangerous code change.  After all
this is not a new bug, it's been here for many years and releases

I've read through this thread, and can't entirely tell what the full issue is here.  If I follow 
everything correctly, I'd say "while debugging, why not just disallow access to the system 
clipboard (and just rely on a private-to-netbeans one)".  Nasty, but this avoids both 
clipboard deletion and hanging.  But, there's implications that this hang can occur at other 
times... can someone explain what those other times might be?

I think David's suggestion is pretty good. The debugger could set some
semidocumented sysprop when it started a debugging session (for the
first time) and reset it when it finishes the last running session.
NbClipboard would simply ignore the system clipboard during this time.

After all, how frequently do you really need to access the system
clipboard from the IDE? Could probably live with having it not work
during those times when you happen to be debugging something -
probably the clipboard is used more when you are writing fresh code
etc. (just a guess).

Whatever the outcome, this should probably be a RELNOTE.

I like that idea. For extra credit, the IDE could -tell- you when Paste is a no-op why 
nothing is happening ("Pasting from the system clipboard is disabled during debugging. 
For details, see issue <full url here>").

Trung, it's hard to believe this bug has been there for a long time - only recently did it 
start happening to me all the time. I was under the impression that the editor only recently 
started looking for the system clipboard whenever the editor is focused? It certainly may 
be the case that Ctrl-V leading to a deadlock may have been there a long time - but I don't 
ever do that while debugging; the editor does however get focused pretty often ...

But still all the JTextComponent-based components (all text fields and
text areas in the dialogs etc.) use the system clipboard for Ctrl-V
including the editor (because we do not intend to duplicate the
complex code behind JTextComponent.paste() in the editor module in
order to delegate to NbClipboard).
So IMHO to provide a consistent workaround we would have to wrap the
system clipboard in the default Toolkit (should be overridable through
setting of "awt.toolkit" property) and override
Toolkit.getSystemClipboard().

> So IMHO to provide a consistent workaround we would have to wrap the
> system clipboard in the default Toolkit (should be overridable through
> setting of "awt.toolkit" property) and override
> Toolkit.getSystemClipboard().

such a wrapper Toolkit will have to delegate to the original Toolkit,
dangerous idea given all the platforms the IDE is supposed to run on.

Remember, whatever we tries here, the IDE stills can deadlock at the
moment the user presses Ctrl+V and we have to access the real system
clipboard.

> such a wrapper Toolkit will have to delegate to the original Toolkit,
> dangerous idea given all the platforms the IDE is supposed to run on.

Agreed. I was mentioning this more as an example I did not want to
advocate this solution.

> Remember, whatever we tries here, the IDE stills can deadlock at the
> moment the user presses Ctrl+V and we have to access the real system
> clipboard.

Why? If we would return NbClipboard wrapper from
Toolkit.getDefaultToolkit().getSystemClipboard() and NbClipboard 
would return empty Transferable during debugging session then I think
there would be no deadlock. Another problem is if the application that
owns the clipboard hangs or is otherwise suspended then once you do
Ctrl-V in NB (outside of the debugging session) then NB will wait for
the app to deliver the clipboard contents. But IMHO that's "hang" not
"deadlock" and the hang can be avoided by e.g. killing of that app.

 Of course this solution is not optimal as well because it effectively
disables pasting of anything into NB during active debugging session.

I reopened issue 40693, we can work around the AWT bug.  I will commit
my part which fixes the NbClipboard hang, Yarda is working on a
JTextComponent part.  Yarda's part will be ugly but it will work.

Then we can just close this bug.  No need to do anything here.

FYI: issue 40693 was fixed in trunk.  I've asked for approval to get
the fix in release36

*** This issue has been marked as a duplicate of 40693 ***

Verified ... and Closing all issues resolved into NetBeans 6.7 and earlier.