Hang when selecting files outside eproject directory

[stsquad]

I get a hang when I try and open files outside any existing eproject definitions. Typically this usually manifests when opening stuff via tramp but can be on local NFS systems. I can break out of the hang with Ctrl-G and the buffer is loaded but without any font locking on.

Using edebug I got to the this backtrace:

run-hooks(after-change-major-mode-hook)
run-mode-hooks(text-mode-hook)
text-mode()
normal-mode(t)
after-find-file(nil t)
find-file-noselect-1(#<buffer rnotes.tex<####>> "/eng/ajb/####/#####/doc/rnotes.tex" nil nil "/eng/ajb/#####/####/doc/rnotes.tex" (48634650 25))
find-file-noselect("/eng/ajb/########/#####/doc/rnotes.tex" nil nil nil)
find-file("/eng/ajb/######/#####/doc/rnotes.tex")
my-test()

Looking at after-change-major-mode-hook

(eproject--after-change-major-mode-hook global-font-lock-mode-enable-in-buffers)

I concluded eproject has gone off on a wild one somewhere. I see the maybe-turn-on logic has been refactored. Should I be tracking the virtual projects branch now?

[jrockway]

Thanks for the report. I'm guessing there might be some sort of loop
while traversing the filesystem; I'm not sure why this would happen,
exactly, but we don't have any checks in place to ensure that there
aren't cycles.

The easiest thing to do is to just strace emacs when opening a file in
the faulty location:

strace -e trace=stat emacs --batch --eval "(progn (require 'eproject)
(with-current-buffer (find-file "/eng/ajb/####/#####/doc/rnotes.tex")
(message "%s" eproject-root)))"

It should be pretty obvious if it's in an infinite loop in that case.
I'd appreciate it if you could take a look to see if it gets into a
filesystem traversal loop, and, if so, send me an outline of what it
looks like it's doing.

Incidentally, I never realized we were running eproject-maybe-turn-on
twice when a file is not in a project. I'm not sure why we made that
change.

--Jon

• On Tue, Aug 23 2011, stsquad wrote:

  I get a hang when I try and open files outside any existing eproject
  definitions. Typically this usually manifests when opening stuff via
  tramp but can be on local NFS systems. I can break out of the hang
  with Ctrl-G and the buffer is loaded but without any font locking on.

  Using edebug I got to the this backtrace:

  run-hooks(after-change-major-mode-hook)
  run-mode-hooks(text-mode-hook)
  text-mode()
  normal-mode(t)
  after-find-file(nil t)
  find-file-noselect-1(#<buffer rnotes.tex<####>> "/eng/ajb/####/#####/doc/rnotes.tex" nil nil "/eng/ajb/#####/####/doc/rnotes.tex" (48634650 25))
  find-file-noselect("/eng/ajb/########/#####/doc/rnotes.tex" nil nil nil)
  find-file("/eng/ajb/######/#####/doc/rnotes.tex")
  my-test()

  Looking at after-change-major-mode-hook

  (eproject--after-change-major-mode-hook global-font-lock-mode-enable-in-buffers)

  I concluded eproject has gone off on a wild one somewhere. I see the
  maybe-turn-on logic has been refactored. Should I be tracking the
  virtual projects branch now?

print just => another => perl => hacker => if $,=$"

[stsquad]

This is the strace output when moving to a new project via tramp. In this case it looks like it's just run out of where to go and gets confused:

stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
stat("/tmp/tramp.30189pe.c", {st_mode=S_IFREG|0600, st_size=833, ...}) = 0
open("/tmp/tramp.30189pe.c", O_RDONLY) = 20
stat("/etc/localtime", {st_mode=S_IFREG|0644, st_size=3661, ...}) = 0
stat("/tmp/tramp.30189pe.c", {st_mode=S_IFREG|0600, st_size=833, ...}) = 0
stat("/src/et_core.c", 0x7fffc31afb30) = -1 ENOENT (No such file or directory)
stat("/Documentation/CodingStyle", 0x7fffc31afb30) = -1 ENOENT (No such file or directory)
stat("/manifest.json", 0x7fffc31af580) = -1 ENOENT (No such file or directory)
stat("/opennms-daemon", 0x7fffc31af490) = -1 ENOENT (No such file or directory)
stat("/../rockbox.git/rbutil", 0x7fffc31afb30) = -1 ENOENT (No such file or directory)
stat("/AndroidManifest.xml", 0x7fffc31af580) = -1 ENOENT (No such file or directory)
stat("/debian", 0x7fffc31af580) = -1 ENOENT (No such file or directory)
stat("/.eproject", 0x7fffc31af580) = -1 ENOENT (No such file or directory)
--- SIGALRM (Alarm clock) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---
--- SIGIO (I/O possible) @ 0 (0) ---

What happens when it gets to the top of the filesystem tree and no project matches?

[jrockway]

To answer your question, "nothing"; the search ends and the next matcher is applied.

I can't reproduce this no matter how much I try. I'm relying on you for a patch.

[stsquad]

I've made it go away by changing the project description for my main workpace project from (generic-git) to (generic). I wonder if this is just an issue with accessing VC backed stuff over tramp?

Next time I have some time to kill I'll restore the change and see if I can get it to replicate.

[jrockway]

Thanks! Hopefully someone else will see this problem, and then we'll
have some more data to help us find out what's going on. I'll keep the
ticket open so that they can potentially add to it :)

• On Wed, Oct 12 2011, Alex Bennee wrote:

  I've made it go away by changing the project description for my main
  workpace project from (generic-git) to (generic). I wonder if this is
  just an issue with accessing VC backed stuff over tramp?

  Next time I have some time to kill I'll restore the change and see if
  I can get it to replicate.

print just => another => perl => hacker => if $,=$"