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 205241

Summary: Infinite loop in FolderObj, burning CPU, draining battery
Product: platform Reporter: Jan Lahoda <jlahoda>
Component: FilesystemsAssignee: Jaroslav Tulach <jtulach>
Status: RESOLVED FIXED    
Severity: normal CC: apb, ceklock, dstrupl, err, jglick, mmirilovic, musilt2, stefan79
Priority: P2 Keywords: PERFORMANCE
Version: 7.1   
Hardware: PC   
OS: Linux   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 204389    
Bug Blocks:    
Attachments: Full thread dump.

Description Jan Lahoda 2011-11-17 14:11:19 UTC
Created attachment 113286 [details]
Full thread dump.

Custom build:
Product Version: NetBeans IDE Dev (Build 20111108-4d254cf6d7f4)
Java: 1.7.0; Java HotSpot(TM) 64-Bit Server VM 21.0-b17
System: Linux version 2.6.38-11-generic running on amd64; UTF-8; en_US (nb)
User directory: /usr/local/home/lahvac/.netbeans/dev
Cache directory: /usr/local/home/lahvac/.netbeans/dev/var/cache

I realized that my IDE is consuming a lot of CPU cycles, when I looked at the console, I have seen messages like this:
WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /usr/local/home/lahvac/src/nb/working/java.hints/build/classes/org/netbeans/modules/java/hints/bugs@51b9f24d:24daeb27[invalid], trying again for 6,128,960

(in fact, my messages.log as almost 1.5GB!). There appears to be an infinite loop in FolderObj.java, which is burning out the CPU.

I am attaching a thread dump.
Comment 1 Jaroslav Tulach 2011-11-21 11:34:42 UTC
More logging in ergonomics#7226c9a6fd1f

Should this bug be fixed for 7.1, then I suggest following check (but only in release71 branch, not in trunk):

@@ -189,6 +189,9 @@
                     lfs.getCachedOnly(fileName.getFile()) :
                     lfs.getFileObject(fInfo, FileObjectFactory.Caller.GetChildern);
                 if (fo != null) {
+                    if (!fo.isValid() && counter > 1000) {
+                        continue;
+                    }
                     final FileNaming foFileName = ((BaseFileObj)fo).getFileName();
                     if (!fo.isValid()) {
                         final Level level = counter < 10 ? Level.FINE : Level.WARNING;
Comment 2 Jaroslav Tulach 2011-11-21 14:03:34 UTC
*** Bug 205171 has been marked as a duplicate of this bug. ***
Comment 3 Quality Engineering 2011-11-22 15:51:44 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/7226c9a6fd1f
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #205241: Print out value of onlyExisting to check whether setting it to false could help to prevent the endless loop
Comment 4 Dusan Balek 2011-12-01 09:52:13 UTC
Custom Build:
  Product Version         = NetBeans IDE Dev (Build 20111122-9a8edc0fe2de) (#9a8edc0fe2de)
  Operating System        = Linux version 2.6.34-12-desktop running on amd64
  Java; VM; Vendor        = 1.6.0_23; Java HotSpot(TM) 64-Bit Server VM 19.0-b09; Sun Microsystems Inc.
  Runtime                 = Java(TM) SE Runtime Environment 1.6.0_23-b05


WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /home/balek/wrk/netbeans/wrk/java.hints/build/classes/org/netbeans/modules/java/hints/encapsulation@15dc0a0c:14d782db[invalid], trying again for 435,008 with true
WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /home/balek/wrk/netbeans/wrk/java.hints/build/classes/org/netbeans/modules/java/hints/encapsulation@15dc0a0c:14d782db[invalid], trying again for 435,009 with true
WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /home/balek/wrk/netbeans/wrk/java.hints/build/classes/org/netbeans/modules/java/hints/encapsulation@15dc0a0c:14d782db[invalid], trying again for 435,010 with true
WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /home/balek/wrk/netbeans/wrk/java.hints/build/classes/org/netbeans/modules/java/hints/encapsulation@15dc0a0c:14d782db[invalid], trying again for 435,011 with true
WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /home/balek/wrk/netbeans/wrk/java.hints/build/classes/org/netbeans/modules/java/hints/encapsulation@15dc0a0c:14d782db[invalid], trying again for 435,012 with true
WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /home/balek/wrk/netbeans/wrk/java.hints/build/classes/org/netbeans/modules/java/hints/encapsulation@15dc0a0c:14d782db[invalid], trying again for 435,013 with true
WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /home/balek/wrk/netbeans/wrk/java.hints/build/classes/org/netbeans/modules/java/hints/encapsulation@15dc0a0c:14d782db[invalid], trying again for 435,014 with true
WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /home/balek/wrk/netbeans/wrk/java.hints/build/classes/org/netbeans/modules/java/hints/encapsulation@15dc0a0c:14d782db[invalid], trying again for 435,015 with true
WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /home/balek/wrk/netbeans/wrk/java.hints/build/classes/org/netbeans/modules/java/hints/encapsulation@15dc0a0c:14d782db[invalid], trying again for 435,016 with true
WARNING [org.netbeans.modules.masterfs.filebasedfs.fileobjects.FolderObj]: Invalid fileObject /home/balek/wrk/netbeans/wrk/java.hints/build/classes/org/netbeans/modules/java/hints/encapsulation@15dc0a0c:14d782db[invalid], trying again for 435,017 with true
Comment 5 Jesse Glick 2011-12-01 15:07:09 UTC
(In reply to comment #1)
> I suggest following check (but only in release71 branch, not in trunk):
> 
> +                    if (!fo.isValid() && counter > 1000) {
> +                        continue;
> +                    }

Seems sane to have such a limit even in trunk even if it is not known how to reproduce the problem, right? Under what circumstances would you want the filesystems layer to run some validity check 1001 times in a row, and does this benefit outweight the known serious performance issue?
Comment 6 Jaroslav Tulach 2011-12-05 06:50:41 UTC
*** Bug 205710 has been marked as a duplicate of this bug. ***
Comment 7 Jaroslav Tulach 2011-12-05 10:19:02 UTC
*** Bug 205739 has been marked as a duplicate of this bug. ***
Comment 8 Jaroslav Tulach 2011-12-05 12:15:39 UTC
*** Bug 205871 has been marked as a duplicate of this bug. ***
Comment 9 Marian Mirilovic 2011-12-05 12:41:15 UTC
Jarda, 
any ideas why it started to happen just recently ? Do we have regression in NB 7.1, introduced right before branching ? If so I think it's stopper, otherwise we will fight with flow of duplicates and complaints for 7.1
Comment 10 Jaroslav Tulach 2011-12-06 08:19:27 UTC
The problem was introduced as part of fixing bug 204389.
Comment 11 Jaroslav Tulach 2011-12-06 08:24:31 UTC
OK, it does not make sense to loop endlessly. Limiting the loop to 100: ergonomics#2cdc7bf32eae

Can be merged to release71 as "hg merge 2cdc7bf32eae"
Comment 12 Jaroslav Tulach 2011-12-06 14:26:45 UTC
transplanted to release71 as

changeset:   12946391a8a5
branch:      release71
parent:      d2dbb04348e3
Comment 13 Quality Engineering 2011-12-07 06:34:44 UTC
Integrated into 'releases'
Changeset: http://hg.netbeans.org/releases/rev/12946391a8a5
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #205241: Limit the number of interation by 100. In case of production build continue, in development builds throw an assert
Comment 14 Quality Engineering 2011-12-07 12:13:36 UTC
Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/2cdc7bf32eae
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #205241: Limit the number of interation by 100. In case of production build continue, in development builds throw an assert
Comment 15 Jesse Glick 2011-12-14 21:00:53 UTC
*** Bug 206407 has been marked as a duplicate of this bug. ***
Comment 16 Marian Mirilovic 2012-01-24 16:24:01 UTC
*** Bug 207650 has been marked as a duplicate of this bug. ***