Exaile

long scan causes gui to hang

Bug #420654 reported by ackstorm on 2009-08-28

This bug affects 3 people

Affects		Status	Importance	Assigned to	Milestone
	Exaile	Fix Released	Undecided	Unassigned	Exaile 0.3.1

Bug Description

Upon initiating a rescan with 0.3.0, I could not get past 31% without the GUI hanging.

Scan seemed to be causing an infinite loop, as top showed exaile using 99% cpu

If left running the scan would appear to start moving again in small jumps, with long hangs in between. However, once the GUI hung at 31% it never recovered until the app was killed and restarted.

Terminal window did not show any errors except that of decoding errors for FLAC files (and the errors happened well before the hang)

I at the suggestion of reacocard on freenode's #exaile I hit cntrl-c in the terminal I ran it out of a few times. Here are the tracebacks.

      ^CTraceback (most recent call last):
        File "/home/exile/Download/exaile-0.3.0/xl/event.py", line 431, in emit
          event.data, *cb.args, **cb.kwargs)
        File "/home/exile/Download/exaile-0.3.0/xlgui/panel/collection.py", line 413, in refresh_tags_in_tree
          self.load_tree()
        File "/home/exile/Download/exaile-0.3.0/xlgui/panel/collection.py", line 434, in load_tree
          self.load_subtree(None)
        File "/home/exile/Download/exaile-0.3.0/xlgui/panel/collection.py", line 571, in load_subtree
          sort_by=sort_by)
        File "/home/exile/Download/exaile-0.3.0/xl/trackdb.py", line 297, in list_tag
          for t in self.search(search_terms):
        File "/home/exile/Download/exaile-0.3.0/xl/trackdb.py", line 366, in search
          tracksres = searcher.search(query, tracks.copy())
        File "/home/exile/Download/exaile-0.3.0/xl/trackdb.py", line 628, in search
          tracks = self.__do_search(tokens, tracks)
        File "/home/exile/Download/exaile-0.3.0/xl/trackdb.py", line 682, in __do_search
          if content == tr[tag]:
        File "/home/exile/Download/exaile-0.3.0/xl/trackdb.py", line 92, in __getitem__
          return self._track[tag]
        File "/home/exile/Download/exaile-0.3.0/xl/track.py", line 221, in __getitem__
          return self.get_tag(tag)
        File "/home/exile/Download/exaile-0.3.0/xl/track.py", line 169, in get_tag
          def get_tag(self, tag):
      KeyboardInterrupt

      ^CTraceback (most recent call last):
        File "/home/exile/Download/exaile-0.3.0/xl/event.py", line 431, in emit
          event.data, *cb.args, **cb.kwargs)
        File "/home/exile/Download/exaile-0.3.0/xlgui/panel/collection.py", line 413, in refresh_tags_in_tree
          self.load_tree()
        File "/home/exile/Download/exaile-0.3.0/xlgui/panel/collection.py", line 434, in load_tree
          self.load_subtree(None)
        File "/home/exile/Download/exaile-0.3.0/xlgui/panel/collection.py", line 622, in load_subtree
          tracks=self.tracks, sort_fields=sort_by)
        File "/home/exile/Download/exaile-0.3.0/xl/trackdb.py", line 366, in search
          tracksres = searcher.search(query, tracks.copy())
        File "/home/exile/Download/exaile-0.3.0/xl/trackdb.py", line 628, in search
          tracks = self.__do_search(tokens, tracks)
        File "/home/exile/Download/exaile-0.3.0/xl/trackdb.py", line 654, in __do_search
          to_remove = self.__do_search(token[1], current_list)
        File "/home/exile/Download/exaile-0.3.0/xl/trackdb.py", line 682, in __do_search
          if content == tr[tag]:
        File "/home/exile/Download/exaile-0.3.0/xl/track.py", line 221, in __getitem__
          return self.get_tag(tag)
      KeyboardInterrupt

reacocard suspected there may be a problem with synchronization between the scan and the GUI

Tags:

Revision history for this message

ackstorm (temper) wrote on 2009-08-28:

after three attempts to rescan i tried again with --debug and --eventdebug but now the scan is only takign 15 seconds, which would imply the previous scans completed despite the GUI locking up at 31%

as such, I can't provide the debugging output

Revision history for this message

ackstorm (temper) wrote on 2009-08-28:

ran strace -aeff -p 16848 and caught the below -- repeating over and over and over

--- snip ---

      futex(0x7f3d90045a74, FUTEX_WAIT_PRIVATE, 1565, NULL) = 0
      futex(0x3a13e42c88, FUTEX_WAKE_PRIVATE, 1) = 0
      futex(0x7f3d9003abd4, FUTEX_WAKE_OP_PRIVATE, 1, 1, 0x7f3d9003abd0, {FUTEX_OP_SET, 0, FUTEX_OP_CMP_GT, 1}) = 1
      futex(0x3a13e42c88, FUTEX_WAKE_PRIVATE, 1) = 1
      stat("/usr/share/locale/en_US.UTF8/LC_MESSAGES/messages.mo", 0x7ffff8bfde80) = -1 ENOENT (No such file or directory)
      stat("/usr/share/locale/en_US/LC_MESSAGES/messages.mo", 0x7ffff8bfde80) = -1 ENOENT (No such file or directory)
      stat("/usr/share/locale/en.UTF8/LC_MESSAGES/messages.mo", 0x7ffff8bfde80) = -1 ENOENT (No such file or directory)
      stat("/usr/share/locale/en/LC_MESSAGES/messages.mo", 0x7ffff8bfde80) = -1 ENOENT (No such file or directory)
      futex(0x7f3da0038780, FUTEX_WAKE_PRIVATE, 1) = 1
      futex(0x1235630, FUTEX_WAKE_PRIVATE, 1) = 1
       futex(0x7f3da0038b10, FUTEX_WAKE_PRIVATE, 1) = 1
       futex(0x1235630, FUTEX_WAKE_PRIVATE, 1) = 1
       brk(0xe8b5000) = 0xe8b5000
       brk(0xe8e5000) = 0xe8e5000
       brk(0xe9a5000) = 0xe9a5000
       brk(0xeca5000) = 0xeca5000
       brk(0xe5b5000) = 0xe5b5000
       stat("/usr/share/locale/en_US.UTF8/LC_MESSAGES/messages.mo", 0x7ffff8bfe5c0) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en_US/LC_MESSAGES/messages.mo", 0x7ffff8bfe5c0) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en.UTF8/LC_MESSAGES/messages.mo", 0x7ffff8bfe5c0) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en/LC_MESSAGES/messages.mo", 0x7ffff8bfe5c0) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en_US.UTF8/LC_MESSAGES/messages.mo", 0x7ffff8bfe5c0) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en_US/LC_MESSAGES/messages.mo", 0x7ffff8bfe5c0) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en.UTF8/LC_MESSAGES/messages.mo", 0x7ffff8bfe5c0) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en/LC_MESSAGES/messages.mo", 0x7ffff8bfe5c0) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en_US.UTF8/LC_MESSAGES/messages.mo", 0x7ffff8bfde80) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en_US/LC_MESSAGES/messages.mo", 0x7ffff8bfde80) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en.UTF8/LC_MESSAGES/messages.mo", 0x7ffff8bfde80) = -1 ENOENT (No such file or directory)
       stat("/usr/share/locale/en/LC_MESSAGES/messages.mo", 0x7ffff8bfde80) = -1 ENOENT (No such file or directory)
       futex(0x7f3da0038b10, FUTEX_WAKE_PRIVATE, 1) = 1
       futex(0x1235630, FUTEX_WAKE_PRIVATE, 1) = 1
       futex(0x7f3da0038b40, FUTEX_WAKE_PRIVATE, 1) = 1
       futex(0x1235630, FUTEX_WAKE_PRIVATE, 1) = 1
       --- snip ---

ran strace -aeff -p 16848 and caught the below -- repeating over and over and over

--- snip ---

Revision history for this message

ackstorm (temper) wrote on 2009-08-28:

I will note that this was not a full scan from an empty library.

I started with a 0.2.14 database (which would hang on scans occassionally as well). I moved up to 0.3.1b1, which I only rescanned in once or twice and seemed to work fine.

Then I upgraded to 0.3.0 and ran into this issue.

I am scanning primarily over a NFS file system. (90% of the content is over NFS).

Revision history for this message

adibadi (adibadi) wrote on 2009-10-01:

Just to confirm, I'm also having this problem, only when rescanning and not on initial scan.

I'm using 3.0.1 on Ubuntu Jaunty 9.04 64bit. My media is on an NFS share, but the same thing happens when it's mounted with CIFS.

Revision history for this message

ackstorm (temper) wrote on 2009-10-01:

I've noticed if I walk away it will eventually complete the scan and return the GUI to functional status.

Unfortunately during this time you have no control over the interface.

Revision history for this message

ackstorm (temper) wrote on 2009-10-31:

Seems to be resolved in latest BZR?

Revision history for this message

reacocard (reacocard) wrote on 2009-10-31:

yeah, one of my more recent commits should have fixed this. closing for now, re-open if anyone else can reproduce it on latest bzr.

Changed in exaile:
milestone:	none → 0.3.1
status:	New → Fix Committed

reacocard (reacocard) on 2010-03-16

Changed in exaile:
status:	Fix Committed → Fix Released

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.