This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 182801 - "Checking for external changes" triggered by every closed dialog
Summary: "Checking for external changes" triggered by every closed dialog
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 6.x
Hardware: PC Linux
: P1 normal (vote)
Assignee: Jaroslav Tulach
URL:
Keywords: PERFORMANCE
: 183214 (view as bug list)
Depends on: 182793
Blocks:
  Show dependency tree
 
Reported: 2010-03-25 15:37 UTC by Jesse Glick
Modified: 2010-04-14 13:09 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
snapshot while spinning (7.48 KB, application/x-itunes-itlp)
2010-04-05 05:33 UTC, err
Details
2nd snapshot after stopping the debugged task (24.66 KB, application/octet-stream)
2010-04-05 05:35 UTC, err
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2010-03-25 15:37:05 UTC
100325-f4b67c70efe1, JDK 6, Ubuntu. Not sure if this is a side effect of e.g. bug #182800 (if so then there is still a serious robustness bug in the indexer), but after starting up, every minute or so, another progress bar appears in the status area:

"Checking for external changes [#####53%     ] X
/space/jdk1.6.0_18/jre/lib"

and never disappears. No activity in thread dump. Persistent progress bars that never go away make this build completely unusable.
Comment 1 Jan Lahoda 2010-03-25 15:43:08 UTC
How does this relate to parsing.api? AFAIK was introduced by jtulach in:
http://hg.netbeans.org/core-main/rev/7c5f5b8074fe
and the string is defined and used in core.ui
Comment 2 Jesse Glick 2010-03-25 16:30:05 UTC
Seems to be caused by bug #182793, though could probably do a separate robustness fix to reliably cancel progress handle in case of problems.
Comment 3 err 2010-04-05 05:33:14 UTC
Created attachment 96666 [details]
snapshot while spinning 

CPU stuck at 100%. I see this occasionally. This time debugging IDE.

Attached snapshot.

After took the snapshot managed to X the IDE under test; primary IDE still spinning.

Took a second snapshot, will attach.

Hit the X on the IDE and NB said it would terminate
  - nbvi-suite (debug)
  - Checking for external changes
There's no visual evidence that the debugger is still running, the buttons have all gone away.

Clicked go ahead and exit, the gui went away, but the console is sticking around. Ah, I see an occasional output from my stuff as things are closing down.

Product Version: NetBeans IDE Dev (Build 201004030201)
Java: 1.6.0_18; Java HotSpot(TM) Client VM 16.0-b13
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Comment 4 err 2010-04-05 05:35:09 UTC
Created attachment 96667 [details]
2nd snapshot after stopping the debugged task
Comment 5 err 2010-04-05 20:56:02 UTC
The "Checking for ..." happens frequently when debugging
- set a break-point that will hit several times when conditions are correct
- do the thing in the app that causes the condition
- get the break-point, immediately continue
- another break-point, continue
Observe the Checking for external changes message

This seems to be quite repeatable, but have not observed the stuck cpu sofar today.

In this case I am debugging the IDE and have a breakpoint at 2nd line of IndentationPanel.prefsChange() in the EditorOptions module. The action to trigger the breakpoint is Tools>Options and Editor>Formatting was current the last time.
Comment 6 err 2010-04-05 21:07:30 UTC
While sitting at a breakpoint in the same session just described. In main IDE started some editting did some code completion, very soon after that things went to hell.
Comment 7 Jaroslav Tulach 2010-04-12 18:45:40 UTC
Try to observe $userdir/var/log/uigestures, I guess there will be plenty of WINDOW_ACTIVATED reports (at least on my Linux whenever I open a dialog and close it, I seem to get an event like):

<record>
  <date>2010-04-12T20:44:55</date>
  <millis>1271097895930</millis>
  <sequence>89642</sequence>
  <logger>org.netbeans.ui.focus</logger>
  <level>FINE</level>
  <thread>14</thread>
  <message>LOG_WINDOW_ACTIVATED</message>
  <key>LOG_WINDOW_ACTIVATED</key>
  <catalog>org.netbeans.core.ui.warmup.Bundle</catalog>
  <param>3</param>
</record>
Comment 8 Jaroslav Tulach 2010-04-12 19:03:29 UTC
Now the behavior shall be much better: core-main#c03e95c8eb6f
Comment 9 Jaroslav Tulach 2010-04-12 20:12:13 UTC
*** Bug 183214 has been marked as a duplicate of this bug. ***
Comment 10 Jaroslav Tulach 2010-04-13 09:16:51 UTC
I consider this an important fix that shall be backported to 6.9 beta. What do you think?
Comment 11 John Jullion-ceccarelli 2010-04-13 11:42:33 UTC
+1. Let's get it into Beta if it is a low-risk fix.
Comment 12 Antonin Nebuzelsky 2010-04-13 11:51:38 UTC
Marian, can you test in the trunk and approve backport to Beta?
Comment 13 Quality Engineering 2010-04-13 17:37:39 UTC
Integrated into 'main-golden', will be available in build *201004131450* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/c03e95c8eb6f
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #182801: There needs to be proper DEACTIVATED event before we shall react to ACTIVATED one. Otherwise every closed dialog (on KDE Linux) yields scan for external changes
Comment 14 Marian Mirilovic 2010-04-14 12:51:08 UTC
I am no more able to reproduce this issue- verified in trunk, please proceed with integration into NB 6.9 Beta.
Comment 15 Antonin Nebuzelsky 2010-04-14 13:09:29 UTC
Thanks for verification.

Fix backported to 6.9 beta:

http://hg.netbeans.org/release69_beta/rev/b0fcf3f1c0b5