PDA

View Full Version : SlimServer crashes while scanning: Perl interpreter failed



veloearl
2005-12-30, 07:59
(I am reposting this to reflect new information in the title. I tried editing the title in my earlier post, but it didn't change the title of the thread in the list.)

I have a new installation of SlimServer 6.2 on Windows XP. When I configure it with my music folder and tell it to scan, it runs for a little while and then crashes. The Event Log says 'Perl interpreter failed.'

Some theories:

I installed SlimServer first and started ripping my music to flac. A few days later, I found a Perl script that transcodes a flac-encoded music folder structure to Mp3 (for the iPod). I installed ActivePerl 5.8.7 to provide a runtime for the Perl script (I didn't know SlimServer came with Perl.) Could this be the problem, e.g., is SlimServer running in the ActivePerl runtime, with which it is not compatible?

I also tried to figure out where the server was crashing, but it is ambiguous. Here is the point(s) in my folder structure where it failed:

Artist A
- Album 1
Artist B
- Album 2
- (missing Album 3) <- did this one cause the failure?
- (missing Album 4)
Artist C
- Album 5
Artist D
- (missing Album 6) <- or was it this one?
(missing Artists E...)

Artist B | Album 3 is classical, so there is lots of punctuation in the song titles, and the song titles are long, etc. But if that caused the failure, why would Artist C | Album 5 have shown up? I see nothing unusual about Artist D | Album 6 that would cause the crash.

Does anyone have any idea?

Michaelwagner
2005-12-30, 08:22
Does the event log not have more information than just "it failed"? Does it give a line number or a function name in which it failed?

Michaelwagner
2005-12-30, 08:24
BTW, one red herring dismissed. I have Active State Perl on my machine as well. 5.8.7. It works. They co-exist. So that's unlikely to be the problem.

bishopdonmiguel
2005-12-30, 08:55
> Does anyone have any idea?

Random thought... You wouldn't happen to have any playlists that point to non-existing directories? I tried a few times to get 6.x running (from 5.4.1) but it would crash exactly as you describe. I later found that I had a gaggle of M3U playlists that pointed to files in directories that were no longer around. These didn't bother 5.4.1 until I tried to play them (which then crashed the service) but I haven't had time to go back and attempt another 6.x upgrade.

veloearl
2005-12-30, 08:57
Does the event log not have more information than just "it failed"? Does it give a line number or a function name in which it failed?
No, it simply says 'Perl interpreter failed.' The full message is shown below.

Event Type: Error
Event Source: Application
Event Category: None
Event ID: 0
Date: 12/30/2005
Time: 10:12:35 AM
User: N/A
Computer: XP-LT
Description:
The description for Event ID ( 0 ) in Source ( Application ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Perl interpreter failed.

veloearl
2005-12-30, 09:03
> Does anyone have any idea?

Random thought... You wouldn't happen to have any playlists that point to non-existing directories? I tried a few times to get 6.x running (from 5.4.1) but it would crash exactly as you describe. I later found that I had a gaggle of M3U playlists that pointed to files in directories that were no longer around. These didn't bother 5.4.1 until I tried to play them (which then crashed the service) but I haven't had time to go back and attempt another 6.x upgrade.
I don't have any playlists, but thanks for the suggestion.

Michaelwagner
2005-12-30, 09:08
No, it simply says 'Perl interpreter failed.' The full message is [snip]
The following information is part of the event: Perl interpreter failed.
Hmm...never saw that before. I've made mine crash, but it always has enough sense to tell me where or why. So it might be a resource problem.

One thing that Active Perl does is create a bunch of temporary files (all .dlls, for some reason) in a temp directory.
Are you short of disk space on any of your disks?

Are you running NTFS file system? Is there a permissions problem?

Where are your music files? On a local disk or on a network share? There's a problem with user permissions for network shares in the default installation that needs to be side-stepped.

That's all that occurs to me right away. But I have a cold so I'm not thinking so well today. :-(

veloearl
2005-12-30, 09:20
Hmm...never saw that before. I've made mine crash, but it always has enough sense to tell me where or why. So it might be a resource problem.

One thing that Active Perl does is create a bunch of temporary files (all .dlls, for some reason) in a temp directory.
Are you short of disk space on any of your disks?
Lots of free space...

Are you running NTFS file system? Is there a permissions problem?

Where are your music files? On a local disk or on a network share? There's a problem with user permissions for network shares in the default installation that needs to be side-stepped.
I am running NTFS. All of my music is on a local, external volume. The SYSTEM account has full control of the volume, and SlimServer runs under the Local System account. So it seems permissions are OK.


That's all that occurs to me right away. But I have a cold so I'm not thinking so well today. :-(
Hope you feel better soon.

Michaelwagner
2005-12-30, 09:52
Nothing jumps out at me ...

You said you're running 6.2
there's one more digit, that is, is it
6.2.1 or 6.2.2?

There were some scanning bugs found in 6.2.1 that were fixed in 6.2.2 (the maintainance release).

They were mostly performance related, not crash related, but sometimes bugs manifest themselves in odd ways ... might be worth a try. Do you know how to get 6.2.2?

Other than that, anything seem obvious to anyone else that I'm missing?

dean
2005-12-30, 12:06
Perl Interpreter Failed is usually a sign that there's something else
wrong with the system, could be disk errors, memory errors, virus,
etc... That error means that there was an internal error in perl
itself.

veloearl
2005-12-30, 12:47
I installed 6.2.2 and it still crashes. Then I started removing artists from the library that I suspected the server did not like. Seems SlimServer has a distaste for Chopin and Beethoven, but has no issues with Pixies, Logh, or Guided By Voices.

I am thinking there is something either in the tags or the filenames/folder names about these two that it does not like. Are there any limitations regarding tags/names that I need to be aware of, like maximum lengths, unsupported characters, etc.? It has to be something with how these are identified, as they are simply .flac files, like the others.

Is there any way to get better debugging info out of the server? I turned on the d_scan debugging option and rescanned the library. After the service crashed, I restarted it and browsed to the log.txt file, but it was empty. No additional info was logged to the event log. Then I thought maybe the file was getting reset when I restarted the service, so I repeated the process and tried to find a local file named log.txt before restarting the server. I looked within the SlimServer folder structure, but no such file exists.

Michaelwagner
2005-12-30, 13:37
Seems SlimServer has a distaste for Chopin and Beethoven.

I am thinking there is something either in the tags or the filenames/folder names about these two that it does not like. Are there any limitations regarding tags/names that I need to be aware of, like maximum lengths, unsupported characters, etc.? It has to be something with how these are identified, as they are simply .flac files, like the others.

We're now out of the area where I have any quick answer for you, since you're doing stuff I don't have any experience with (flac for a start).

Here's what I would do. It'll take about half an hour.

Make a new directory, preferably close to the root, like c:\testmusic

Copy into that directory the Chopin album that fails.

Start up Slimserver, telling it that the new directory you just created is your entire music directory. Ask it to scan it. Should take less than a minute to scan a single album. If it succeeds, it's a naming/tree depth kind of thing.

If it fails, remove files one by one and repeat until it doesn't fail. Now you've identified a specific file that fails.

Or do it the other way around. Put the first track into the directory, see if it succeeds. Then put the next track in. Keep going until it fails.

Then send the failing track off to Slim in a bug report saying Slimserver fails when scanning that track. And attach the track. Once they can reproduce the problem, they have a chance to fix it.



Is there any way to get better debugging info out of the server?
Yes, but with Windows it's a bit counter-intuitive.
If you got the windows package, out of the box you can't enable debugging. What you have to do is get a copy of active state perl (but I think you said you had it already) and run slimserver from the command line as
perl slimserver.pl --logfile log.txt --s_scan
(if scan is what you want to enable)

You might want to put it in a bat file.

Hope this helps.

Michael

veloearl
2005-12-30, 13:49
Great idea, I'll give that a try. Thanks for your help.

veloearl
2006-01-01, 09:52
OK, using debugging via the command line, I figured out what is happening. SlimServer is parsing my cue sheets, and then looking for the referenced .wav files.

I used EAC to create cue sheets when ripping to flac. EAC put the cue sheets in the root folder, instead of in the album folder (not sure why). So the file names in the .cue file have paths relative to the folder in which EAC placed the .cue file. SlimServer is combining that path with the path to the folder it is currently scanning, resulting in a path with redundant information. The path exceeds the maximum pathlength, for example:

E:\My Music\Library\Licensed\Beethoven\Favourite Piano Sonatas (1971) - A. Brendel\CD 2\Ludwig van Beethoven\Favourite Piano Sonatas (1971) - Alfred Brendel (1971)\06 - Sonata No 21 in C major op 53 'Waldstein'; 3. Rondo (Allegretto moderato - Prestissimo).wav

This path is 261 characters long. I think this is what is causing the crash.

SlimServer should either know not to treat .cue as playlists, or let me tell it to ignore .cue files completely. And it should always validate the path length before looking for the file.

Michaelwagner
2006-01-01, 10:38
The path exceeds the maximum pathlength, for example:

E:\My Music\Library\Licensed\Beethoven\Favourite Piano Sonatas (1971) - A. Brendel\CD 2\Ludwig van Beethoven\Favourite Piano Sonatas (1971) - Alfred Brendel (1971)\06 - Sonata No 21 in C major op 53 'Waldstein'; 3. Rondo (Allegretto moderato - Prestissimo).wav

This path is 261 characters long. I think this is what is causing the crash.

It's a good guess. I notice it's over 255 characters and 255 is a magic number.

Certainly if 255 is a limit (in some operating system), Slimserver should check and not choke.

And of course, if perl is going to die on it, perl should also be checking. So we may have a dual failure here.

In any case, you've now gotten to the point where you can describe the failure enough to file a bug report for it.

Would you like to file a bug report? Do you need help with that?


SlimServer should either know not to treat .cue as playlists, or let me tell it to ignore .cue files completely.

I don't know enough about cue sheets ... I'll let someone else handle that part of it.

veloearl
2006-01-01, 10:40
I've already filed a bug report. Thanks again for your help!

Michaelwagner
2006-01-01, 10:52
I just confirmed that, at least in windows 2000, 255 or thereabouts is a hard limit. I tried to create a set of nested directories, all called
supercalafragilisticexpealedocious
Round about 260 characters or so it failed.

So there are really 2 problems.

Slim should check and not honour file names it constructs that are over the limits for the file system housing the file. Not an easy thing to figure out.

(I should explain that ... If the server is hosted on system A, but the file system on system B, some combination of rules for system A and system B may apply)

And Perl should not fail in such an undignified and unhelpful way.

Michaelwagner
2006-01-01, 10:55
Forward Link to bug report
http://bugs.slimdevices.com/show_bug.cgi?id=2773

Michaelwagner
2006-01-01, 11:10
veloearl: If I were you, I'd change the severity.

(Since I'm not you, I can't).

You left the severity as "normal", but I would think either Major or Critical would be more appropriate, according to the definitions from "A bugs life"
http://bugs.slimdevices.com/page.cgi?id=fields.html#bug_severity

Severities are listed as follows:
This field describes the impact of a bug.
Blocker Blocks development and/or testing work
Critical crashes, loss of data, severe memory leak
Major major loss of function
Minor minor loss of function, or other problem where easy workaround is present
Trivial cosmetic problem like misspelled words or misaligned text
Enhancement Request for enhancement

kdf
2006-01-01, 12:36
On 1-Jan-06, at 9:52 AM, Michaelwagner wrote:

>
> Slim should check and not honour file names it constructs that are over
> the limits for the file system housing the file. Not an easy thing to
> figure out.
>
> And Perl should not fail in such an undignified and unhelpful way.
>
if it is a perl interpreter failure, I expect that any method
slimserver could use to test (thus relying on perl) might still cause
perl to see the 261 characters.

Lets not forget issue #3: bad setup of EAC. The CUE and the audio file
should be appearing in the same folder. Even if perl can stop crashing
over it, you'll want the music to index properly.

-kdf

Robin Bowes
2006-01-01, 12:46
veloearl said the following on 01/01/2006 16:52:

> SlimServer should either know not to treat .cue as playlists, or let me
> tell it to ignore .cue files completely. And it should always validate
> the path length before looking for the file.

Vote here:

http://bugs.slimdevices.com/show_bug.cgi?id=2323

R.

veloearl
2006-01-01, 12:53
if it is a perl interpreter failure, I expect that any method
slimserver could use to test (thus relying on perl) might still cause
perl to see the 261 characters.

Lets not forget issue #3: bad setup of EAC. The CUE and the audio file
should be appearing in the same folder. Even if perl can stop crashing
over it, you'll want the music to index properly.

-kdf
Although I am not a Perl developer, I expect the Perl failure is occuring when the script attempts to look for a file whose path exceeds the OS maximum. I would expect a string in Perl could contain well in excess of 261 characters, so it should be feasible to validate the length of the path before attempting to test for the presence of the file.

I agree regarding the EAC config...

Michaelwagner
2006-01-01, 13:18
I would expect a string in Perl could contain well in excess of 261 characters, so it should be feasible to validate the length of the path before attempting to test for the presence of the file.
Yes, the problem is how to write the function

will-all-interfaces-between-here-and-the-file-system-allow-this-filespec(fs)

considering that the file may be housed locally or on a SAN or a NAS or a different operating system over a network share.

For instance, does OSX have a 255 character limit? A different one?
What about Linux?
Samba?
Does Windoz have different limits depending on version?
Depending on whether it's a FAT32 or an NTFS system?

Is file length the only issue? What about embedded special characers in folder names? Might unicode end up in a song file name? In a folder name? With the network in between allow those characters?

How can code, inside perl, find out all the environments along the way and if any of them are going to choke?

kdf
2006-01-01, 13:25
On 1-Jan-06, at 12:18 PM, Michaelwagner wrote:

>
> veloearl Wrote:
>> I would expect a string in Perl could contain well in excess of 261
>> characters, so it should be feasible to validate the length of the
>> path
>> before attempting to test for the presence of the file.
> Yes, the problem is how to write the function
>
> will-all-interfaces-between-here-and-the-file-system-allow-this-
> filespec(fs)
>
> considering that the file may be housed locally or on a SAN or a NAS or
> a different operating system over a network share.
>
just have to make sure to test the parts of the path, before the point
where it is built and used...hopefully.
-k

vacaboca
2006-01-03, 13:20
I've experienced the same issue since installing the 12/30 and now the 1/3 6.2.2 builds... before that, I'd been running the original 6.2.1 release. I'm on Windows XP, and am not using EAC or FLAC.

I have tens of thousands of songs spread over a number of disks, all linked with shortcuts under my music 'collection' folder. I have a new/changed scan scheduled to run every morning at 1am. Last night I had to recover one of my volumes to another location, so I removed that shortcut from the music collection. I estimate that dropped somewhere around 10k songs out of the collection.

This morning's scan apparently failed, and I found the server stopped when I checked this morning. In the application event log (in Windows), I see the 'perl interpreter failed' error, apparently related to the stopping of the server (and the scan).

In hopes I could fix it, I installed (over the top of the 12/30 install) this morning's build (6.2.2 - 5505 - Windows XP), and attempted to do a "Clear library and rescan everything". Trying that twice resulted in the same error, and then on the third time it appeared to complete... however, now my library shows *0* songs, on several thousand albums and artists. New Music->All Songs shows page after page of 2-digit numbers.

I'm going to try a full uninstall/delete and then clean install. Sorry if my note is basically useless, just thought it might not be a cooincidence that I saw the same error at the same time, after being up and running for quite a while (a few weeks I guess) on 6.2.1.

Oh, the reason for my title (not sure it's path-related) is that I don't think I've changed or added anything in the last day (since my last successful scan) that had any longer a path than I'd had previously... of course, I'll have to go check now to make sure, I have been adding a lot lately, but only to existing directories.

bishopdonmiguel
2006-01-03, 13:51
vacaboca,

Check your playlist directory to see if any point to locations now invalid (i.e. you moved your files). Despite suggestions that this error is somehow a sign that there are low level problems, this is the confirmed cause of my system generating this error under W2K. Once I removed the invalid playlists, the scan proceeded and I now have 6.2.x running.

vacaboca
2006-01-03, 14:00
Thanks for the suggestion :) I only have a few playlists in there, but I'm pretty sure that they would have contained references to the volume that I removed. I deleted them, and have restarted the server from the command line... it's doing a scan right now, I'll see the output of any problems... if that doesn't work, I'll do a full wipe and install at some point soon.

Thanks!

vacaboca
2006-01-03, 15:10
I should probably post a new thread, as I think I'm drifting away from the 'Perl interpreter failed' error (not that familiar with this forum yet)... after slim server came up from a command line start, it ran (on its own?) a new/changed scan, which left it still with 0 songs (by lots of artists on lots of albums). Through the web interface I kicked off a "Clear library and rescan everything", and just saw the following output that seems to indicate my actual problem:

2006-01-03 16:45:51.0156 DBD::SQLite::db do failed: database disk image is malformed(1) at dbdimp.c line 401 at /PerlApp/Slim/DataStores/DBI/DataModel.pm line 89, <$fh> line 23.
2006-01-03 16:45:51.0161 Couldn't execute SQL statement: [DROP TABLE albums;] : [DBD::SQLite::db do failed: database disk image is malformed(1) at dbdimp.c line 401 at /PerlApp/Slim/DataStores/DBI/DataModel.pm line 89, <$fh> line 23.
]

There were actually a number of related lines - each failed table DROPs... does that mean my database is corrupted? Is there a way to start with/create a fresh empty database without doing a full re-install? I'll search the forums for that particular error.

Thanks!

vacaboca
2006-01-05, 06:09
I did a full uninstall/re-install, and that fixed everything... I'm not sure what corrupted my database - it was either the installer or the removal of an entire disk volume via deletion of the shortcut to it. I now believe that the "perl interpreter failed" was probably related to resource constraints on my system... actually, it might have been that crash that corrupted my database.

Michaelwagner
2006-01-05, 06:35
Glad to hear it's fixed.

Not clear on what caused it in the first place, but if there's some thought that your hardware caused the first crash, and the first crash corrupted the database, it will likely be totally irreproduceable.

The question "Can you delete and recreate the database without a total re-install" is a good one. I thought clear database and rescan actually ran the routines to fully re-initialize the database from scratch (i.e. for each table, "drop table"), but your comments seem to indicate otherwise. So perhaps there's a bug lurking ...

I just re-checked the code ... when you do a rescan, the code executes dbdrop followed by dbcreate, so the intention is to totally drop the database and recreate from scratch. There is another routine, dbclear, that does less, merely emptying the database tables. It might fail in face of a corrupt database, but in the code version I have here (6.2.2 from about a week ago) it isn't actually used.

There could be a mistake in dbdrop, but at least the code intent is the "right" one.

I'll check dbdrop tonight. Gotta go to work.

vacaboca
2006-01-05, 11:06
Thanks for the info Michael! The code definitely attempted the drops - they just failed with image/database corrupt/malformed messages... instead of erroring out gracefully at that point (and saying something about my DB being screwed up :) ), I think it just stopped trying to scan, leaving things very confused (as some data apparently was cleared, while other data wasn't).

In any event, I'm happy with where I've ended up, and now feel relatively comfortable with the full uninstall/re-install process... it was nice to see that doing a full scan of my library still finished successfully in a few hours.