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
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@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
No, I haven't tried the other apps yet. I've only ever used the GUI and the command-line. I'll try that soon. Meanwhile, here's some Java error traces from launching the GUI. $ /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@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@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)
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?
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@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?
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@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@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?
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@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@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@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@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@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@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@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?
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@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@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@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@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@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?
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@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@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@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@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@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@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@gmail.com <mailto:christian.gruen@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@gmail.com <mailto:bdysonsmith@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@gmail.com <mailto:rickhg12hs@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@gmail.com <mailto:bdysonsmith@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@gmail.com <mailto:rickhg12hs@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@gmail.com <mailto:christian.gruen@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?
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@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@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@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@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@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@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@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? > > >
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@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@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@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@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@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@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@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@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? >> >> >>
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@mailman.uni-konstanz.de] Im Auftrag von Graydon Saunders Gesendet: Mittwoch, 23. Januar 2019 14:19 An: Christian Grün <christian.gruen@gmail.com> Cc: BaseX <basex-talk@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@gmail.com<mailto:christian.gruen@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@gmail.com<mailto:m.lettere@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@gmail.com<mailto:christian.gruen@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@gmail.com<mailto:bdysonsmith@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@gmail.com<mailto:rickhg12hs@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@gmail.com<mailto:bdysonsmith@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@gmail.com<mailto:rickhg12hs@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@gmail.com<mailto:christian.gruen@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?
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@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@mailman.uni-konstanz.de] *Im Auftrag von *Graydon Saunders *Gesendet:* Mittwoch, 23. Januar 2019 14:19 *An:* Christian Grün <christian.gruen@gmail.com> *Cc:* BaseX <basex-talk@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@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@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@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@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@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@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@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@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?
Hi all, I have revised the cache management of the project view in the latest 9.2.1 snapshot: • The maximum number of cached file paths is now limited to 50,000. • If a symbolic link is found in the directory structure, it will only be traversed once. Cheers, Christian On Wed, Jan 23, 2019 at 3:56 PM Bridger Dyson-Smith <bdysonsmith@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@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@mailman.uni-konstanz.de] Im Auftrag von Graydon Saunders Gesendet: Mittwoch, 23. Januar 2019 14:19 An: Christian Grün <christian.gruen@gmail.com> Cc: BaseX <basex-talk@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@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@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@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@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@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@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@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@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?
participants (6)
-
Bridger Dyson-Smith -
Christian Grün -
Graydon Saunders -
Johannes Echterhoff -
Marco Lettere -
Rick Graham