Bugzilla – Bug 3553
SlimServer scan goes into an infinite loop with a directory named " "
Last modified: 2008-09-15 14:38:25 UTC
I ran into a case where the SlimServer scan code would go into an infinite loop, constantly increasing memory usage, until the system ran into OOMs, and eventually killed the SlimServer process. Notable items to help reproduce the problem: * Audiodir was set to "/c/media/Music/". The folder that caused the issue was "/c/media/Music/ /". * Running "slimserver.pl --scanonly --d_scan" showed that it kept looping on the base directory, never descending into any subdirectories. * It appears to be a generic issue, although I didn't try it under Windows.
and trying 6.3 didn't resolve this? (I woudl have suggested that 6.2.2 already had the looping fixed), but there has certainly been many attempts along to way to eliminate any loops due to shortcuts/links going back into the music folder tree.
chris to reproduce
I *think* I was able to reproduce this on OSX. That is, in the log file it looks like it's done scanning, but the perl task is still sucking up all available CPU. I'll attach the log in a sec. Dean already suggested we punt on this one to 6.5.
Created attachment 1281 [details] log file
it appears to be a bug in URI::file. This code in Misc.pm: sub fileURLFromPath { my $path = shift; return $path if (Slim::Music::Info::isURL($path)); my $uri = URI::file->new( fixPathCase($path) ); $uri->host(''); return $uri->as_string; } takes something like "/Users/chris/music/ " and turns it into "file:///Users/chris/music/" dropping the trailing space. Let's fix this (and possibly update URI) in 6.5
Yep, it is a problem with the URI module, although I don't think they would call it a bug. Here is the code that causes the problem, from URI.pm: sub new { ... # Get rid of potential wrapping ... $uri =~ s/\s+$//; ... } Here's a patch that fixes the issue, by forcing a trailing "/" on all entries that end in a space. Just adding a trailing "/" to $item worked on Perl 5.8.6, but didn't seem to work on 5.8.8. For some reason, the "catfile" function handles this differently for each perl version. This change here worked on both. The only potential issue I can see is if it were a file name that ended in a space, but you shouldn't run into a problem there much, if ever. And I guess not handling that one file right would probably be better than looping. Anyway, here it is: --- Scan.pm.orig Fri Jun 23 16:48:18 2006 +++ Scan.pm Fri Jun 23 16:49:26 2006 @@ -534,8 +534,10 @@ my @dircontents = Slim::Utils::Misc::readDirectory($playlistpathpath); for my $item (@dircontents) { + my @args = ($playlistpath, $item); + push(@args, '') if("$item" =~ /\s$/); - my $url = Slim::Utils::Misc::fileURLFromPath(catfile($playlistpathpath, $item)); + my $url = Slim::Utils::Misc::fileURLFromPath(catfile(@args)); $::d_scan && msg(" directory entry: $url\n");
So this isn't an issue in 6.5 - but a patch didn't make it for 6.3.0 I can commit this to 6.3.x, but it's unlikely that we'll actually ship a 6.3.1 Chris - thoughts?
Sure, why not commit it to 6.3. If we ever do a 6.3.1 build it'll be in there.
Fixed in change 8230