BaseX/GUI v9.1.2 memory use

> Version: 9.1.2 > Used Memory: 1593 MB > Global options: > AUTHMETHOD: Basic > CACHETIMEOUT: 3600 > DBPATH: /usr/local/src/basex/data > DEBUG: false > FAIRLOCK: false > HOST: localhost > HTTPLOCAL: false > IGNORECERT: false > IGNOREHOSTNAME: false > KEEPALIVE: 600 > LANG: English > LANGKEYS: false > LOG: true > LOGMSGMAXLEN: 1000 > LOGPATH: .logs > NONPROXYHOSTS: > PARALLEL: 8 > PARSERESTXQ: 3 > PASSWORD: > PORT: 1984 > PROXYHOST: > PROXYPORT: 0 > REPOPATH: /usr/local/src/basex/repo > RESTPATH: > RESTXQPATH: > SERVERHOST: > SERVERPORT: 1984 > STOPPORT: 8985 > TIMEOUT: 30 > USER: > WEBPATH: /usr/local/src/basex/webapp > Local options > ADDARCHIVES: true > ADDCACHE: false > ADDRAW: false > ARCHIVENAME: false > ATTRINCLUDE: > ATTRINDEX: true > AUTOFLUSH: true > AUTOOPTIMIZE: false > BINDINGS: > CASESENS: false > CATFILE: > CHECKSTRINGS: true > CHOP: true > COMPPLAN: true > COPYNODE: true > CREATEFILTER: *.xml > CREATEONLY: false > CSVPARSER: > DEFAULTDB: false > DIACRITICS: false > DOTCOMPACT: false > DOTPLAN: false > DTD: false > ENFORCEINDEX: false > EXPORTER: > FORCECREATE: false > FTINCLUDE: > FTINDEX: false > HTMLPARSER: > INLINELIMIT: 100 > INTPARSE: false > JSONPARSER: > LANGUAGE: en > LSERROR: 0 > MAINMEM: false > MAXCATS: 100 > MAXLEN: 96 > MAXSTAT: 30 > MIXUPDATES: false > PARSER: xml > QUERYINFO: true > RUNQUERY: true > RUNS: 1 > SERIALIZE: true > SERIALIZER: > SKIPCORRUPT: false > SPLITSIZE: 0 > STEMMING: false > STOPWORDS: > STRIPNS: false > TAILCALLS: 256 > TEXTINCLUDE: > TEXTINDEX: true > TEXTPARSER: > TOKENINCLUDE: > TOKENINDEX: false > UPDINDEX: false > WRITEBACK: false > XINCLUDE: true > XMLPLAN: true

On Tue, Jan 22, 2019 at 9:51 PM Rick Graham <rickhg12hs at gmail.com> wrote: > > Hello, > > Thanks again, as always, for a great product. > > I just installed BaseX v9.1.2 (upgrading from a previous v9.1.2 snapshot), launched the GUI and then got interrupted. When I returned, almost all of the JVM's memory was being used. I hit "GC" several times but it didn't seem to help. I had no database loaded/open. Seems like some memory isn't getting freed properly. > > Here's my "INFO" > >> General Information: >> Version: 9.1.2 >> Used Memory: 1593 MB >> Global options: >> AUTHMETHOD: Basic >> CACHETIMEOUT: 3600 >> DBPATH: /usr/local/src/basex/data >> DEBUG: false >> FAIRLOCK: false >> HOST: localhost >> HTTPLOCAL: false >> IGNORECERT: false >> IGNOREHOSTNAME: false >> KEEPALIVE: 600 >> LANG: English >> LANGKEYS: false >> LOG: true >> LOGMSGMAXLEN: 1000 >> LOGPATH: .logs >> NONPROXYHOSTS: >> PARALLEL: 8 >> PARSERESTXQ: 3 >> PASSWORD: >> PORT: 1984 >> PROXYHOST: >> PROXYPORT: 0 >> REPOPATH: /usr/local/src/basex/repo >> RESTPATH: >> RESTXQPATH: >> SERVERHOST: >> SERVERPORT: 1984 >> STOPPORT: 8985 >> TIMEOUT: 30 >> USER: >> WEBPATH: /usr/local/src/basex/webapp >> Local options >> ADDARCHIVES: true >> ADDCACHE: false >> ADDRAW: false >> ARCHIVENAME: false >> ATTRINCLUDE: >> ATTRINDEX: true >> AUTOFLUSH: true >> AUTOOPTIMIZE: false >> BINDINGS: >> CASESENS: false >> CATFILE: >> CHECKSTRINGS: true >> CHOP: true >> COMPPLAN: true >> COPYNODE: true >> CREATEFILTER: *.xml >> CREATEONLY: false >> CSVPARSER: >> DEFAULTDB: false >> DIACRITICS: false >> DOTCOMPACT: false >> DOTPLAN: false >> DTD: false >> ENFORCEINDEX: false >> EXPORTER: >> FORCECREATE: false >> FTINCLUDE: >> FTINDEX: false >> HTMLPARSER: >> INLINELIMIT: 100 >> INTPARSE: false >> JSONPARSER: >> LANGUAGE: en >> LSERROR: 0 >> MAINMEM: false >> MAXCATS: 100 >> MAXLEN: 96 >> MAXSTAT: 30 >> MIXUPDATES: false >> PARSER: xml >> QUERYINFO: true >> RUNQUERY: true >> RUNS: 1 >> SERIALIZE: true >> SERIALIZER: >> SKIPCORRUPT: false >> SPLITSIZE: 0 >> STEMMING: false >> STOPWORDS: >> STRIPNS: false >> TAILCALLS: 256 >> TEXTINCLUDE: >> TEXTINDEX: true >> TEXTPARSER: >> TOKENINCLUDE: >> TOKENINDEX: false >> UPDINDEX: false >> WRITEBACK: false >> XINCLUDE: true >> XMLPLAN: true > > > Best regards, > Richard >

$ /usr/local/src/basex/bin/basexgui > java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError: GC > overhead limit exceeded > at java.util.concurrent.FutureTask.report(FutureTask.java:122) > at java.util.concurrent.FutureTask.get(FutureTask.java:192) > at javax.swing.SwingWorker.get(SwingWorker.java:602) > at org.basex.gui.layout.GUIWorker$1.done(GUIWorker.java:40) > at javax.swing.SwingWorker$5.run(SwingWorker.java:737) > at > javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.run(SwingWorker.java:832) > at sun.swing.AccumulativeRunnable.run(AccumulativeRunnable.java:112) > at > javax.swing.SwingWorker$DoSubmitAccumulativeRunnable.actionPerformed(SwingWorker.java:842) > at javax.swing.Timer.fireActionPerformed(Timer.java:313) > at javax.swing.Timer$DoPostEvent.run(Timer.java:245) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758) > at java.awt.EventQueue.access$500(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:709) > at java.awt.EventQueue$3.run(EventQueue.java:703) > at java.security.AccessController.doPrivileged(Native Method) > at > java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:74) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:728) > at > java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205) > at > java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at > java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded > at java.util.Arrays.copyOf(Arrays.java:3332) > at java.lang.String.<init>(String.java:166) > at org.basex.util.Token.string(Token.java:115) > at org.basex.util.TokenBuilder.toString(TokenBuilder.java:405) > at org.basex.io.IOFile.add(IOFile.java:528) > at org.basex.io.IOFile.create(IOFile.java:500) > at org.basex.io.IOFile.<init>(IOFile.java:74) > at org.basex.io.IOFile.<init>(IOFile.java:39) > at org.basex.io.IOFile.children(IOFile.java:226) > at org.basex.io.IOFile.children(IOFile.java:193) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > Exception in thread "AWT-EventQueue-0" java.lang.OutOfMemoryError: Java > heap space > at java.awt.image.DataBufferInt.<init>(DataBufferInt.java:75) > at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:591) > at com.sun.java.swing.plaf.gtk.GTKEngine.finishPainting(GTKEngine.java:582) > at > com.sun.java.swing.plaf.gtk.GTKPainter.paintTabbedPaneContentBackground(GTKPainter.java:866) > at > javax.swing.plaf.synth.SynthTabbedPaneUI.paintContentBorder(SynthTabbedPaneUI.java:731) > at > javax.swing.plaf.synth.SynthTabbedPaneUI.paint(SynthTabbedPaneUI.java:486) > at > javax.swing.plaf.synth.SynthTabbedPaneUI.update(SynthTabbedPaneUI.java:376) > at javax.swing.JComponent.paintComponent(JComponent.java:780) > at javax.swing.JComponent.paint(JComponent.java:1056) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) > at org.basex.gui.view.ViewContainer.paint(ViewContainer.java:221) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) > at javax.swing.JComponent.paintChildren(JComponent.java:889) > at javax.swing.JComponent.paint(JComponent.java:1065) On Tue, Jan 22, 2019 at 10:03 PM Christian Grün <christian.gruen at gmail.com> wrote: > Hm, I couldn’t reproduce this out of the box. Does the problem only > occur in your GUI instance? Did you check out the behavior on > command-line or in the DBA as well? > > > On Tue, Jan 22, 2019 at 9:51 PM Rick Graham <rickhg12hs at gmail.com> wrote: > > > > Hello, > > > > Thanks again, as always, for a great product. > > > > I just installed BaseX v9.1.2 (upgrading from a previous v9.1.2 > snapshot), launched the GUI and then got interrupted. When I returned, > almost all of the JVM's memory was being used. I hit "GC" several times > but it didn't seem to help. I had no database loaded/open. Seems like > some memory isn't getting freed properly. > > > > Here's my "INFO" > > > >> General Information: > >> Version: 9.1.2 > >> Used Memory: 1593 MB > >> Global options: > >> AUTHMETHOD: Basic > >> CACHETIMEOUT: 3600 > >> DBPATH: /usr/local/src/basex/data > >> DEBUG: false > >> FAIRLOCK: false > >> HOST: localhost > >> HTTPLOCAL: false > >> IGNORECERT: false > >> IGNOREHOSTNAME: false > >> KEEPALIVE: 600 > >> LANG: English > >> LANGKEYS: false > >> LOG: true > >> LOGMSGMAXLEN: 1000 > >> LOGPATH: .logs > >> NONPROXYHOSTS: > >> PARALLEL: 8 > >> PARSERESTXQ: 3 > >> PASSWORD: > >> PORT: 1984 > >> PROXYHOST: > >> PROXYPORT: 0 > >> REPOPATH: /usr/local/src/basex/repo > >> RESTPATH: > >> RESTXQPATH: > >> SERVERHOST: > >> SERVERPORT: 1984 > >> STOPPORT: 8985 > >> TIMEOUT: 30 > >> USER: > >> WEBPATH: /usr/local/src/basex/webapp > >> Local options > >> ADDARCHIVES: true > >> ADDCACHE: false > >> ADDRAW: false > >> ARCHIVENAME: false > >> ATTRINCLUDE: > >> ATTRINDEX: true > >> AUTOFLUSH: true > >> AUTOOPTIMIZE: false > >> BINDINGS: > >> CASESENS: false > >> CATFILE: > >> CHECKSTRINGS: true > >> CHOP: true > >> COMPPLAN: true > >> COPYNODE: true > >> CREATEFILTER: *.xml > >> CREATEONLY: false > >> CSVPARSER: > >> DEFAULTDB: false > >> DIACRITICS: false > >> DOTCOMPACT: false > >> DOTPLAN: false > >> DTD: false > >> ENFORCEINDEX: false > >> EXPORTER: > >> FORCECREATE: false > >> FTINCLUDE: > >> FTINDEX: false > >> HTMLPARSER: > >> INLINELIMIT: 100 > >> INTPARSE: false > >> JSONPARSER: > >> LANGUAGE: en > >> LSERROR: 0 > >> MAINMEM: false > >> MAXCATS: 100 > >> MAXLEN: 96 > >> MAXSTAT: 30 > >> MIXUPDATES: false > >> PARSER: xml > >> QUERYINFO: true > >> RUNQUERY: true > >> RUNS: 1 > >> SERIALIZE: true > >> SERIALIZER: > >> SKIPCORRUPT: false > >> SPLITSIZE: 0 > >> STEMMING: false > >> STOPWORDS: > >> STRIPNS: false > >> TAILCALLS: 256 > >> TEXTINCLUDE: > >> TEXTINDEX: true > >> TEXTPARSER: > >> TOKENINCLUDE: > >> TOKENINDEX: false > >> UPDINDEX: false > >> WRITEBACK: false > >> XINCLUDE: true > >> XMLPLAN: true > > > > > > Best regards, > > Richard > > >

> > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) >> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >> >

[pid 13436] > stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", > 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links)

On Tue, Jan 22, 2019 at 10:21 PM Christian Grün <christian.gruen at gmail.com> wrote: > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) >>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>> >> > Looks like a endless loop that is caused by parsing the files in your > project directory. Do you possibly have any symbolic links? > > Can you reproduce the problem with a completely fresh BaseX zip archive? > > >

On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith <bdysonsmith at gmail.com> wrote: > Hi Rick, et al, > I think (but am not 100% sure) that the GUI defaults to looking through > your home directory on startup. So, somewhere in > `~/rick/.wine/dosdevices/...` you have symbolic links that are looped. > > I think you might be able to circumvent this problem by finding > `.basexgui` - it would probably be close to wherever you started the GUI > from on your filesystem. I think you can edit some of the PATHS there and > that may help? > > Again, I'm not sure. HTH! > Best, > Bridger > > On Tue, Jan 22, 2019 at 4:56 PM Rick Graham <rickhg12hs at gmail.com> wrote: > >> The command-line seemed to be operating normally. >> >> What exactly is/are my project directories? >> >> I attached to the running GUI instance `strace -f -e trace=stat -p 13368` >> and it has infinite repetitions of: >> >> [pid 13436] >>> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", >>> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links) >> >> >> What's going on here? >> >> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün < >> christian.gruen at gmail.com> wrote: >> >>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) >>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>> >>>> >>> Looks like a endless loop that is caused by parsing the files in your >>> project directory. Do you possibly have any symbolic links? >>> >>> Can you reproduce the problem with a completely fresh BaseX zip archive? >>> >>> >>>

> Glad that helped :) > > I see this when I start from a fresh install vs expanding the ZIP into the > same directory. > > On Tue, Jan 22, 2019, 5:17 PM Rick Graham <rickhg12hs at gmail.com wrote: > >> Thanks Bridger! >> >> Indeed, I quit basexgui and manually edited .basexgui to set the project >> directory to a newly created empty directory. basexgui seems normal/stable >> after that. >> >> I rarely, as in almost never, use wine but I didn't have this issue with >> previous versions of BaseX. Something seems unexpected here. >> >> >> On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith < >> bdysonsmith at gmail.com> wrote: >> >>> Hi Rick, et al, >>> I think (but am not 100% sure) that the GUI defaults to looking through >>> your home directory on startup. So, somewhere in >>> `~/rick/.wine/dosdevices/...` you have symbolic links that are looped. >>> >>> I think you might be able to circumvent this problem by finding >>> `.basexgui` - it would probably be close to wherever you started the GUI >>> from on your filesystem. I think you can edit some of the PATHS there and >>> that may help? >>> >>> Again, I'm not sure. HTH! >>> Best, >>> Bridger >>> >>> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham <rickhg12hs at gmail.com> >>> wrote: >>> >>>> The command-line seemed to be operating normally. >>>> >>>> What exactly is/are my project directories? >>>> >>>> I attached to the running GUI instance `strace -f -e trace=stat -p >>>> 13368` and it has infinite repetitions of: >>>> >>>> [pid 13436] >>>>> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", >>>>> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links) >>>> >>>> >>>> What's going on here? >>>> >>>> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün < >>>> christian.gruen at gmail.com> wrote: >>>> >>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) >>>>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>> >>>>>> >>>>> Looks like a endless loop that is caused by parsing the files in your >>>>> project directory. Do you possibly have any symbolic links? >>>>> >>>>> Can you reproduce the problem with a completely fresh BaseX zip >>>>> archive? >>>>> >>>>> >>>>>

On Tue, Jan 22, 2019 at 4:56 PM Rick Graham <rickhg12hs at gmail.com> wrote: > The command-line seemed to be operating normally. > > What exactly is/are my project directories? > > I attached to the running GUI instance `strace -f -e trace=stat -p 13368` > and it has infinite repetitions of: > > [pid 13436] >> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", >> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links) > > > What's going on here? > > On Tue, Jan 22, 2019 at 10:21 PM Christian Grün <christian.gruen at gmail.com> > wrote: > >> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) >>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>> >>> >> Looks like a endless loop that is caused by parsing the files in your >> project directory. Do you possibly have any symbolic links? >> >> Can you reproduce the problem with a completely fresh BaseX zip archive? >> >> >>

On Tue, Jan 22, 2019, 5:17 PM Rick Graham <rickhg12hs at gmail.com wrote: > Thanks Bridger! > > Indeed, I quit basexgui and manually edited .basexgui to set the project > directory to a newly created empty directory. basexgui seems normal/stable > after that. > > I rarely, as in almost never, use wine but I didn't have this issue with > previous versions of BaseX. Something seems unexpected here. > > > On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith < > bdysonsmith at gmail.com> wrote: > >> Hi Rick, et al, >> I think (but am not 100% sure) that the GUI defaults to looking through >> your home directory on startup. So, somewhere in >> `~/rick/.wine/dosdevices/...` you have symbolic links that are looped. >> >> I think you might be able to circumvent this problem by finding >> `.basexgui` - it would probably be close to wherever you started the GUI >> from on your filesystem. I think you can edit some of the PATHS there and >> that may help? >> >> Again, I'm not sure. HTH! >> Best, >> Bridger >> >> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham <rickhg12hs at gmail.com> wrote: >> >>> The command-line seemed to be operating normally. >>> >>> What exactly is/are my project directories? >>> >>> I attached to the running GUI instance `strace -f -e trace=stat -p >>> 13368` and it has infinite repetitions of: >>> >>> [pid 13436] >>>> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", >>>> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links) >>> >>> >>> What's going on here? >>> >>> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün < >>> christian.gruen at gmail.com> wrote: >>> >>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) >>>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>> >>>>> >>>> Looks like a endless loop that is caused by parsing the files in your >>>> project directory. Do you possibly have any symbolic links? >>>> >>>> Can you reproduce the problem with a completely fresh BaseX zip archive? >>>> >>>> >>>>

On Tue, Jan 22, 2019, 17:36 Christian Grün <christian.gruen at gmail.com> wrote: > Good to hear that! I can’t recollect that something particular has changed > in version 9.1.2, regarding the scanning of project files, but I’ll have > some thoughts how we can trace and interrupt such loops (or ignore symbolic > links instead). > > > > Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith < > bdysonsmith at gmail.com> geschrieben: > >> Glad that helped :) >> >> I see this when I start from a fresh install vs expanding the ZIP into >> the same directory. >> >> On Tue, Jan 22, 2019, 5:17 PM Rick Graham <rickhg12hs at gmail.com wrote: >> >>> Thanks Bridger! >>> >>> Indeed, I quit basexgui and manually edited .basexgui to set the project >>> directory to a newly created empty directory. basexgui seems normal/stable >>> after that. >>> >>> I rarely, as in almost never, use wine but I didn't have this issue with >>> previous versions of BaseX. Something seems unexpected here. >>> >>> >>> On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith < >>> bdysonsmith at gmail.com> wrote: >>> >>>> Hi Rick, et al, >>>> I think (but am not 100% sure) that the GUI defaults to looking through >>>> your home directory on startup. So, somewhere in >>>> `~/rick/.wine/dosdevices/...` you have symbolic links that are looped. >>>> >>>> I think you might be able to circumvent this problem by finding >>>> `.basexgui` - it would probably be close to wherever you started the GUI >>>> from on your filesystem. I think you can edit some of the PATHS there and >>>> that may help? >>>> >>>> Again, I'm not sure. HTH! >>>> Best, >>>> Bridger >>>> >>>> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham <rickhg12hs at gmail.com> >>>> wrote: >>>> >>>>> The command-line seemed to be operating normally. >>>>> >>>>> What exactly is/are my project directories? >>>>> >>>>> I attached to the running GUI instance `strace -f -e trace=stat -p >>>>> 13368` and it has infinite repetitions of: >>>>> >>>>> [pid 13436] >>>>>> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", >>>>>> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links) >>>>> >>>>> >>>>> What's going on here? >>>>> >>>>> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün < >>>>> christian.gruen at gmail.com> wrote: >>>>> >>>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) >>>>>>>> at >>>>>>>> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>>> at >>>>>>>> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>>> at >>>>>>>> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>>> >>>>>>> >>>>>> Looks like a endless loop that is caused by parsing the files in your >>>>>> project directory. Do you possibly have any symbolic links? >>>>>> >>>>>> Can you reproduce the problem with a completely fresh BaseX zip >>>>>> archive? >>>>>> >>>>>> >>>>>>

On 22/01/19 23:50, Graydon Saunders wrote: > I've been handling updates by making data/ a symbolic link to a data > directory that's a sibling of the basex directory. (Move the old, > unpack the new, go into new and replace data/ with a symbolic link up > and over.) > > Would hate to see that stop working. > > On Tue, Jan 22, 2019, 17:36 Christian Grün <christian.gruen at gmail.com > <mailto:christian.gruen at gmail.com>> wrote: > > Good to hear that! I can’t recollect that something particular has > changed in version 9.1.2, regarding the scanning of project files, > but I’ll have some thoughts how we can trace and interrupt such > loops (or ignore symbolic links instead). > > > > Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith > <bdysonsmith at gmail.com <mailto:bdysonsmith at gmail.com>> geschrieben: > > Glad that helped :) > > I see this when I start from a fresh install vs expanding the > ZIP into the same directory. > > On Tue, Jan 22, 2019, 5:17 PM Rick Graham > <rickhg12hs at gmail.com <mailto:rickhg12hs at gmail.com> wrote: > > Thanks Bridger! > > Indeed, I quit basexgui and manually edited .basexgui to > set the project directory to a newly created empty > directory. basexgui seems normal/stable after that. > > I rarely, as in almost never, use wine but I didn't have > this issue with previous versions of BaseX. Something > seems unexpected here. > > > On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith > <bdysonsmith at gmail.com <mailto:bdysonsmith at gmail.com>> wrote: > > Hi Rick, et al, > I think (but am not 100% sure) that the GUI defaults > to looking through your home directory on startup. So, > somewhere in `~/rick/.wine/dosdevices/...` you have > symbolic links that are looped. > > I think you might be able to circumvent this problem > by finding `.basexgui` - it would probably be close to > wherever you started the GUI from on your filesystem. > I think you can edit some of the PATHS there and that > may help? > > Again, I'm not sure. HTH! > Best, > Bridger > > On Tue, Jan 22, 2019 at 4:56 PM Rick Graham > <rickhg12hs at gmail.com <mailto:rickhg12hs at gmail.com>> > wrote: > > The command-line seemed to be operating normally. > > What exactly is/are my project directories? > > I attached to the running GUI instance `strace -f > -e trace=stat -p 13368` and it has infinite > repetitions of: > > [pid 13436] > stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", > 0x7f7beb2796e0) = -1 ELOOP (Too many levels of > symbolic links) > > > What's going on here? > > On Tue, Jan 22, 2019 at 10:21 PM Christian Grün > <christian.gruen at gmail.com > <mailto:christian.gruen at gmail.com>> wrote: > > at > org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) > at > org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at > org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at > org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > > > Looks like a endless loop that is caused by > parsing the files in your project directory. > Do you possibly have any symbolic links? > > Can you reproduce the problem with a > completely fresh BaseX zip archive? > >

> Same for us over here. The ability to follow symlinks is a very powerful > feature that we use to externalize folders (data, restxq for instance). So > please don't remove it altogether! > M. > > On 22/01/19 23:50, Graydon Saunders wrote: > > I've been handling updates by making data/ a symbolic link to a data > directory that's a sibling of the basex directory. (Move the old, unpack > the new, go into new and replace data/ with a symbolic link up and over.) > > Would hate to see that stop working. > > On Tue, Jan 22, 2019, 17:36 Christian Grün <christian.gruen at gmail.com> > wrote: > >> Good to hear that! I can’t recollect that something particular has >> changed in version 9.1.2, regarding the scanning of project files, but I’ll >> have some thoughts how we can trace and interrupt such loops (or ignore >> symbolic links instead). >> >> >> >> Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith < >> bdysonsmith at gmail.com> geschrieben: >> >>> Glad that helped :) >>> >>> I see this when I start from a fresh install vs expanding the ZIP into >>> the same directory. >>> >>> On Tue, Jan 22, 2019, 5:17 PM Rick Graham <rickhg12hs at gmail.com wrote: >>> >>>> Thanks Bridger! >>>> >>>> Indeed, I quit basexgui and manually edited .basexgui to set the >>>> project directory to a newly created empty directory. basexgui seems >>>> normal/stable after that. >>>> >>>> I rarely, as in almost never, use wine but I didn't have this issue >>>> with previous versions of BaseX. Something seems unexpected here. >>>> >>>> >>>> On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith < >>>> bdysonsmith at gmail.com> wrote: >>>> >>>>> Hi Rick, et al, >>>>> I think (but am not 100% sure) that the GUI defaults to looking >>>>> through your home directory on startup. So, somewhere in >>>>> `~/rick/.wine/dosdevices/...` you have symbolic links that are looped. >>>>> >>>>> I think you might be able to circumvent this problem by finding >>>>> `.basexgui` - it would probably be close to wherever you started the GUI >>>>> from on your filesystem. I think you can edit some of the PATHS there and >>>>> that may help? >>>>> >>>>> Again, I'm not sure. HTH! >>>>> Best, >>>>> Bridger >>>>> >>>>> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham <rickhg12hs at gmail.com> >>>>> wrote: >>>>> >>>>>> The command-line seemed to be operating normally. >>>>>> >>>>>> What exactly is/are my project directories? >>>>>> >>>>>> I attached to the running GUI instance `strace -f -e trace=stat -p >>>>>> 13368` and it has infinite repetitions of: >>>>>> >>>>>> [pid 13436] >>>>>>> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", >>>>>>> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links) >>>>>> >>>>>> >>>>>> What's going on here? >>>>>> >>>>>> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün < >>>>>> christian.gruen at gmail.com> wrote: >>>>>> >>>>>>> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) >>>>>>>>> at >>>>>>>>> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>>>> at >>>>>>>>> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>>>> at >>>>>>>>> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>>>> >>>>>>>> >>>>>>> Looks like a endless loop that is caused by parsing the files in >>>>>>> your project directory. Do you possibly have any symbolic links? >>>>>>> >>>>>>> Can you reproduce the problem with a completely fresh BaseX zip >>>>>>> archive? >>>>>>> >>>>>>> >>>>>>> >

Von: BaseX-Talk [mailto:basex-talk-bounces at mailman.uni-konstanz.de] Im Auftrag von Graydon Saunders Gesendet: Mittwoch, 23. Januar 2019 14:19 An: Christian Grün <christian.gruen at gmail.com> Cc: BaseX <basex-talk at mailman.uni-konstanz.de> Betreff: Re: [basex-talk] BaseX/GUI v9.1.2 memory use Never had a problem with the GUI parsing project files. No issues with symbolic links. I have generally found basex very reliable but never try to update the installed version; it's always move the old, unpack the new. On Wed, Jan 23, 2019, 08:09 Christian Grün <christian.gruen at gmail.com<mailto:christian.gruen at gmail.com>> wrote: Thanks for your assessments. So maybe we should ensure that every file and directory will only be parsed once. Did anyone of you have problems with the automatic parsing of project files in the BaseX GUI, or with symbolic links in particular? Am Mi., 23. Jan. 2019, 09:12 hat Marco Lettere <m.lettere at gmail.com<mailto:m.lettere at gmail.com>> geschrieben: Same for us over here. The ability to follow symlinks is a very powerful feature that we use to externalize folders (data, restxq for instance). So please don't remove it altogether! M. On 22/01/19 23:50, Graydon Saunders wrote: I've been handling updates by making data/ a symbolic link to a data directory that's a sibling of the basex directory. (Move the old, unpack the new, go into new and replace data/ with a symbolic link up and over.) Would hate to see that stop working. On Tue, Jan 22, 2019, 17:36 Christian Grün <christian.gruen at gmail.com<mailto:christian.gruen at gmail.com>> wrote: Good to hear that! I can’t recollect that something particular has changed in version 9.1.2, regarding the scanning of project files, but I’ll have some thoughts how we can trace and interrupt such loops (or ignore symbolic links instead). Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith <bdysonsmith at gmail.com<mailto:bdysonsmith at gmail.com>> geschrieben: Glad that helped :) I see this when I start from a fresh install vs expanding the ZIP into the same directory. On Tue, Jan 22, 2019, 5:17 PM Rick Graham <rickhg12hs at gmail.com<mailto:rickhg12hs at gmail.com> wrote: Thanks Bridger! Indeed, I quit basexgui and manually edited .basexgui to set the project directory to a newly created empty directory. basexgui seems normal/stable after that. I rarely, as in almost never, use wine but I didn't have this issue with previous versions of BaseX. Something seems unexpected here. On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith <bdysonsmith at gmail.com<mailto:bdysonsmith at gmail.com>> wrote: Hi Rick, et al, I think (but am not 100% sure) that the GUI defaults to looking through your home directory on startup. So, somewhere in `~/rick/.wine/dosdevices/...` you have symbolic links that are looped. I think you might be able to circumvent this problem by finding `.basexgui` - it would probably be close to wherever you started the GUI from on your filesystem. I think you can edit some of the PATHS there and that may help? Again, I'm not sure. HTH! Best, Bridger On Tue, Jan 22, 2019 at 4:56 PM Rick Graham <rickhg12hs at gmail.com<mailto:rickhg12hs at gmail.com>> wrote: The command-line seemed to be operating normally. What exactly is/are my project directories? I attached to the running GUI instance `strace -f -e trace=stat -p 13368` and it has infinite repetitions of: [pid 13436] stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links) What's going on here? On Tue, Jan 22, 2019 at 10:21 PM Christian Grün <christian.gruen at gmail.com<mailto:christian.gruen at gmail.com>> wrote: at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) Looks like a endless loop that is caused by parsing the files in your project directory. Do you possibly have any symbolic links? Can you reproduce the problem with a completely fresh BaseX zip archive?

On Wed, Jan 23, 2019, 08:09 Christian Grün <christian.gruen at gmail.com> wrote: > Thanks for your assessments. So maybe we should ensure that every file and > directory will only be parsed once. > > Did anyone of you have problems with the automatic parsing of project > files in the BaseX GUI, or with symbolic links in particular? > > > > > > Am Mi., 23. Jan. 2019, 09:12 hat Marco Lettere <m.lettere at gmail.com> > geschrieben: > >> Same for us over here. The ability to follow symlinks is a very powerful >> feature that we use to externalize folders (data, restxq for instance). So >> please don't remove it altogether! >> M. >> >> On 22/01/19 23:50, Graydon Saunders wrote: >> >> I've been handling updates by making data/ a symbolic link to a data >> directory that's a sibling of the basex directory. (Move the old, unpack >> the new, go into new and replace data/ with a symbolic link up and over.) >> >> Would hate to see that stop working. >> >> On Tue, Jan 22, 2019, 17:36 Christian Grün <christian.gruen at gmail.com> >> wrote: >> >>> Good to hear that! I can’t recollect that something particular has >>> changed in version 9.1.2, regarding the scanning of project files, but I’ll >>> have some thoughts how we can trace and interrupt such loops (or ignore >>> symbolic links instead). >>> >>> >>> >>> Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith < >>> bdysonsmith at gmail.com> geschrieben: >>> >>>> Glad that helped :) >>>> >>>> I see this when I start from a fresh install vs expanding the ZIP into >>>> the same directory. >>>> >>>> On Tue, Jan 22, 2019, 5:17 PM Rick Graham <rickhg12hs at gmail.com wrote: >>>> >>>>> Thanks Bridger! >>>>> >>>>> Indeed, I quit basexgui and manually edited .basexgui to set the >>>>> project directory to a newly created empty directory. basexgui seems >>>>> normal/stable after that. >>>>> >>>>> I rarely, as in almost never, use wine but I didn't have this issue >>>>> with previous versions of BaseX. Something seems unexpected here. >>>>> >>>>> >>>>> On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith < >>>>> bdysonsmith at gmail.com> wrote: >>>>> >>>>>> Hi Rick, et al, >>>>>> I think (but am not 100% sure) that the GUI defaults to looking >>>>>> through your home directory on startup. So, somewhere in >>>>>> `~/rick/.wine/dosdevices/...` you have symbolic links that are looped. >>>>>> >>>>>> I think you might be able to circumvent this problem by finding >>>>>> `.basexgui` - it would probably be close to wherever you started the GUI >>>>>> from on your filesystem. I think you can edit some of the PATHS there and >>>>>> that may help? >>>>>> >>>>>> Again, I'm not sure. HTH! >>>>>> Best, >>>>>> Bridger >>>>>> >>>>>> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham <rickhg12hs at gmail.com> >>>>>> wrote: >>>>>> >>>>>>> The command-line seemed to be operating normally. >>>>>>> >>>>>>> What exactly is/are my project directories? >>>>>>> >>>>>>> I attached to the running GUI instance `strace -f -e trace=stat -p >>>>>>> 13368` and it has infinite repetitions of: >>>>>>> >>>>>>> [pid 13436] >>>>>>>> stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", >>>>>>>> 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links) >>>>>>> >>>>>>> >>>>>>> What's going on here? >>>>>>> >>>>>>> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün < >>>>>>> christian.gruen at gmail.com> wrote: >>>>>>> >>>>>>>> at >>>>>>>>>> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) >>>>>>>>>> at >>>>>>>>>> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>>>>> at >>>>>>>>>> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>>>>> at >>>>>>>>>> org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >>>>>>>>>> >>>>>>>>> >>>>>>>> Looks like a endless loop that is caused by parsing the files in >>>>>>>> your project directory. Do you possibly have any symbolic links? >>>>>>>> >>>>>>>> Can you reproduce the problem with a completely fresh BaseX zip >>>>>>>> archive? >>>>>>>> >>>>>>>> >>>>>>>> >>

On Wed, Jan 23, 2019 at 8:30 AM Johannes Echterhoff < echterhoff at interactive-instruments.de> wrote: > For what it’s worth: in our developments we had a directory as part of the > project files where we stored all queries that were executed during > development and testing (these queries were dynamically created by other > queries). Saving these queries is just part of our process. However, after > a while that resulted in hundreds to thousands of query files. That > resulted in a massive memory demand, and we noticed increased CPU usage, > both of which we could not explain at first. Eventually we found out that > the BaseX GUI automatically parsed all these queries, each time > initializing a custom module we wrote, where the initialization of that > module created a temporary directory with a number of files. The solution > for us was to simply move the directory where we save the executed queries > somewhere outside of the project files opened in the BaseX GUI. > > > > Best regards, > > Johannes > > > > > > *Von:* BaseX-Talk [mailto:basex-talk-bounces at mailman.uni-konstanz.de] *Im > Auftrag von *Graydon Saunders > *Gesendet:* Mittwoch, 23. Januar 2019 14:19 > *An:* Christian Grün <christian.gruen at gmail.com> > *Cc:* BaseX <basex-talk at mailman.uni-konstanz.de> > *Betreff:* Re: [basex-talk] BaseX/GUI v9.1.2 memory use > > > > Never had a problem with the GUI parsing project files. No issues with > symbolic links. > > > > I have generally found basex very reliable but never try to update the > installed version; it's always move the old, unpack the new. > > On Wed, Jan 23, 2019, 08:09 Christian Grün <christian.gruen at gmail.com> > wrote: > > Thanks for your assessments. So maybe we should ensure that every file and > directory will only be parsed once. > > > > Did anyone of you have problems with the automatic parsing of project > files in the BaseX GUI, or with symbolic links in particular? > > > > > > > > > > > > Am Mi., 23. Jan. 2019, 09:12 hat Marco Lettere <m.lettere at gmail.com> > geschrieben: > > Same for us over here. The ability to follow symlinks is a very powerful > feature that we use to externalize folders (data, restxq for instance). So > please don't remove it altogether! > > M. > > > > On 22/01/19 23:50, Graydon Saunders wrote: > > I've been handling updates by making data/ a symbolic link to a data > directory that's a sibling of the basex directory. (Move the old, unpack > the new, go into new and replace data/ with a symbolic link up and over.) > > > > Would hate to see that stop working. > > On Tue, Jan 22, 2019, 17:36 Christian Grün <christian.gruen at gmail.com> > wrote: > > Good to hear that! I can’t recollect that something particular has changed > in version 9.1.2, regarding the scanning of project files, but I’ll have > some thoughts how we can trace and interrupt such loops (or ignore symbolic > links instead). > > > > > > Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith < > bdysonsmith at gmail.com> geschrieben: > > Glad that helped :) > > > > I see this when I start from a fresh install vs expanding the ZIP into the > same directory. > > > > On Tue, Jan 22, 2019, 5:17 PM Rick Graham <rickhg12hs at gmail.com wrote: > > Thanks Bridger! > > > > Indeed, I quit basexgui and manually edited .basexgui to set the project > directory to a newly created empty directory. basexgui seems normal/stable > after that. > > > > I rarely, as in almost never, use wine but I didn't have this issue with > previous versions of BaseX. Something seems unexpected here. > > > > > > On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith < > bdysonsmith at gmail.com> wrote: > > Hi Rick, et al, > > I think (but am not 100% sure) that the GUI defaults to looking through > your home directory on startup. So, somewhere in > `~/rick/.wine/dosdevices/...` you have symbolic links that are looped. > > > > I think you might be able to circumvent this problem by finding > `.basexgui` - it would probably be close to wherever you started the GUI > from on your filesystem. I think you can edit some of the PATHS there and > that may help? > > > > Again, I'm not sure. HTH! > > Best, > > Bridger > > > > On Tue, Jan 22, 2019 at 4:56 PM Rick Graham <rickhg12hs at gmail.com> wrote: > > The command-line seemed to be operating normally. > > > > What exactly is/are my project directories? > > > > I attached to the running GUI instance `strace -f -e trace=stat -p 13368` > and it has infinite repetitions of: > > > > [pid 13436] > stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", > 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links) > > > > What's going on here? > > > > On Tue, Jan 22, 2019 at 10:21 PM Christian Grün <christian.gruen at gmail.com> > wrote: > > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) > > > > Looks like a endless loop that is caused by parsing the files in your > project directory. Do you possibly have any symbolic links? > > > > Can you reproduce the problem with a completely fresh BaseX zip archive? > > > > > > > >

On Wed, Jan 23, 2019 at 3:56 PM Bridger Dyson-Smith <bdysonsmith at gmail.com> wrote: > > Mea culpa! I may have steered the train of conversation in a non-productive direction: my home is parsed due to how I launch the GUI. In any event, I haven't had any issues with parsing project files or symbolic links, either. > > Apologies, > Bridger > > On Wed, Jan 23, 2019 at 8:30 AM Johannes Echterhoff <echterhoff at interactive-instruments.de> wrote: >> >> For what it’s worth: in our developments we had a directory as part of the project files where we stored all queries that were executed during development and testing (these queries were dynamically created by other queries). Saving these queries is just part of our process. However, after a while that resulted in hundreds to thousands of query files. That resulted in a massive memory demand, and we noticed increased CPU usage, both of which we could not explain at first. Eventually we found out that the BaseX GUI automatically parsed all these queries, each time initializing a custom module we wrote, where the initialization of that module created a temporary directory with a number of files. The solution for us was to simply move the directory where we save the executed queries somewhere outside of the project files opened in the BaseX GUI. >> >> >> >> Best regards, >> >> Johannes >> >> >> >> >> >> Von: BaseX-Talk [mailto:basex-talk-bounces at mailman.uni-konstanz.de] Im Auftrag von Graydon Saunders >> Gesendet: Mittwoch, 23. Januar 2019 14:19 >> An: Christian Grün <christian.gruen at gmail.com> >> Cc: BaseX <basex-talk at mailman.uni-konstanz.de> >> Betreff: Re: [basex-talk] BaseX/GUI v9.1.2 memory use >> >> >> >> Never had a problem with the GUI parsing project files. No issues with symbolic links. >> >> >> >> I have generally found basex very reliable but never try to update the installed version; it's always move the old, unpack the new. >> >> On Wed, Jan 23, 2019, 08:09 Christian Grün <christian.gruen at gmail.com> wrote: >> >> Thanks for your assessments. So maybe we should ensure that every file and directory will only be parsed once. >> >> >> >> Did anyone of you have problems with the automatic parsing of project files in the BaseX GUI, or with symbolic links in particular? >> >> >> >> >> >> >> >> >> >> >> >> Am Mi., 23. Jan. 2019, 09:12 hat Marco Lettere <m.lettere at gmail.com> geschrieben: >> >> Same for us over here. The ability to follow symlinks is a very powerful feature that we use to externalize folders (data, restxq for instance). So please don't remove it altogether! >> >> M. >> >> >> >> On 22/01/19 23:50, Graydon Saunders wrote: >> >> I've been handling updates by making data/ a symbolic link to a data directory that's a sibling of the basex directory. (Move the old, unpack the new, go into new and replace data/ with a symbolic link up and over.) >> >> >> >> Would hate to see that stop working. >> >> On Tue, Jan 22, 2019, 17:36 Christian Grün <christian.gruen at gmail.com> wrote: >> >> Good to hear that! I can’t recollect that something particular has changed in version 9.1.2, regarding the scanning of project files, but I’ll have some thoughts how we can trace and interrupt such loops (or ignore symbolic links instead). >> >> >> >> >> >> Am Di., 22. Jan. 2019, 23:22 hat Bridger Dyson-Smith <bdysonsmith at gmail.com> geschrieben: >> >> Glad that helped :) >> >> >> >> I see this when I start from a fresh install vs expanding the ZIP into the same directory. >> >> >> >> On Tue, Jan 22, 2019, 5:17 PM Rick Graham <rickhg12hs at gmail.com wrote: >> >> Thanks Bridger! >> >> >> >> Indeed, I quit basexgui and manually edited .basexgui to set the project directory to a newly created empty directory. basexgui seems normal/stable after that. >> >> >> >> I rarely, as in almost never, use wine but I didn't have this issue with previous versions of BaseX. Something seems unexpected here. >> >> >> >> >> >> On Tue, Jan 22, 2019 at 11:04 PM Bridger Dyson-Smith <bdysonsmith at gmail.com> wrote: >> >> Hi Rick, et al, >> >> I think (but am not 100% sure) that the GUI defaults to looking through your home directory on startup. So, somewhere in `~/rick/.wine/dosdevices/...` you have symbolic links that are looped. >> >> >> >> I think you might be able to circumvent this problem by finding `.basexgui` - it would probably be close to wherever you started the GUI from on your filesystem. I think you can edit some of the PATHS there and that may help? >> >> >> >> Again, I'm not sure. HTH! >> >> Best, >> >> Bridger >> >> >> >> On Tue, Jan 22, 2019 at 4:56 PM Rick Graham <rickhg12hs at gmail.com> wrote: >> >> The command-line seemed to be operating normally. >> >> >> >> What exactly is/are my project directories? >> >> >> >> I attached to the running GUI instance `strace -f -e trace=stat -p 13368` and it has infinite repetitions of: >> >> >> >> [pid 13436] stat("/home/rick/.wine/dosdevices/z:/sys/class/thermal/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone2/subsystem/thermal_zone0/device/subsystem/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:75/subsystem/devices/PNP0C0A:02", 0x7f7beb2796e0) = -1 ELOOP (Too many levels of symbolic links) >> >> >> >> What's going on here? >> >> >> >> On Tue, Jan 22, 2019 at 10:21 PM Christian Grün <christian.gruen at gmail.com> wrote: >> >> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:167) >> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >> at org.basex.gui.view.project.ProjectFiles.add(ProjectFiles.java:173) >> >> >> >> Looks like a endless loop that is caused by parsing the files in your project directory. Do you possibly have any symbolic links? >> >> >> >> Can you reproduce the problem with a completely fresh BaseX zip archive? >> >> >> >> >> >>