Bug report: MOC quits with screenful of errors when entering dir with specific file

I'm using: moc 2.5.0-alpha3 Build: Jun 29 2008 13:51:46

Recently I've encountered a problem when descending into my Music directory using the MOC browser. By quite some copying back and forth, I found out that it was related to one specific file with the name "Verdi - Nabucco - Va, pensiero (Parte III, Scena seconda - Coro e prefezia).mp3". Initially I thought it was related to the long filename, but after isolating the file in an otherwise empty directory and renaming it to "Verdi.mp3", the result was the same. As soon as I descend into the directory containing the file, MOC quits with a screenful of error messages.

After a bit of experimenting, I figured out it was probably related to reading the tags. When I toggle off the ReadTags option, I can descend into the directory without any problems. When I choose for MOC to play the file, however, it quits abruptly again (altho the file does start playing).

I've uploaded the file here: http://pinnerup.anarcho.dk/pub/Verdi%20-%20Nabucco%20-%20Va,%20pensiero%20(Parte%20III,%20Scena%20seconda%20-%20Coro%20e%20prefezia).mp3

I can't reproduce this error, but I am using the current SVN version of MOC.
Can you try to run MOCs server part in a separate terminal (-S and -F options) and look for (and post here) a specific message before the crash ?
Further I think it would be good to know if you have configured MOC to use librcc for id3 recoding (when you run 'configure' what is the state of 'RCC' ?).

*edit*
I just had a look on that mp3 file. It seems that after the ID3 tag there is also an APE2 tag. This could possibly lead to confusing the ID3 tag reader (as the tag identifier is poorly chosen on both sides...)
What version of libid3tag is installed on your system ? As I do not experience this error it could be possible that there is a bug in an older/other version. The version on my system is 0.15.1b.

Hi!
I'm using moc on Debian testing (64bit). My kernel is 2.6.26.6 with realtime patch.
$ mocp -V
moc 2.5.0-alpha3 Build: Jul 2 2008 15:31:25
Compiled with: OSS ALSA JACK DEBUG internet streams resample

That's what I can tell for now:
With ReadTags set to "yes" mocp stops responding when I enter any folder with file ending with .wav .mp3 .ogg and .flac. (even if it is a text file named test.wav)

With "ReadTags = no" I can browse folders without errors.
I can even switch the "ShowTime" option (with ^t) but only once. (I have "ShowTime = IfAvailabe" entry in config) When I try to switch it back, mocp stops responding.

When I write "stops responding" I mean that "^C" is useless and
killall mocp too.
Only
killall -s KILL mocp
works.

That's all for now...
I will try to reproduce these errors on Ubuntu and on unpatched kernel later...

Ok, the error happens also on regular Debian kernel (2.6.26-1-amd64).
I tried to reproduce this err on the console, and succeded :) One bad thing about this, was that when mocp hanged I couldn't switch to other console screen (with either CtrlAltF{1-6} or Alt{Left,Right}).
CtrlAltDel was the solution :/

Could you try to use a splitted screen[1] session to watch both parts ?
There is at least a small chance that something helpful pops up.

Maybe a bit unrelated, but I had something leading to a crash in MOC. I updated the database library (berkeley db) that is now used to store the tags and then recompiled moc. On the next startup the tag-db could not be loaded by moc and it crashed on the next try to read a tag.
The only thing I could do was to remove the old tag-database from mocs directory.

[1] http://www.gnu.org/software/screen/

May I send you file made by this command?
$ mocp -S -F > mocp_server_stdout.txt
Will it be enough? Screen seems too complicated to me... I've tried once to learn it but without success. :)


One more thing is that Q option doesn't kill the mocp server process as it should. When I try to launch mocp again (after shutting the previous one down with Q) I get:
$ mocp
Running the server...
It seems that the server is already running with pid 3375.
If it is not true, remove the pid file (/home/a2m/.moc/pid) and try again.
FATAL_ERROR: Exiting.
FATAL_ERROR: Server exited

But mocp -x gives:
$ mocp -x
FATAL_ERROR: The server is not running

In pstree output I can see mocp server is running. I can delete the pid file but then mocp simply creates new server process and both of them are running.

Once you master screen you will not want to live without it... :-) but catching the output would work too.

I would however vote for 'mocp -S -F > mocp_server_stdout.txt 2> mocp_server_stderr.txt' to get everything. But there should be no need to send these files, put them up to pastebin[1] or similar - or if you spot suspicious lines just post them.

One thing about that message: it says 'if it is not true', but in your case, moc IS (technically) running. In these cases I kill it with 'kill -9 [pid]' (TERM). This strong medicine mostly works...

[1] http://pastebin.org

On Ubuntu 8.04 amd64 moc is working fine. The version in ubuntu repo is:
moc 2.5.0-alpha2 Build: Oct 29 2007 01:16:41
Compiled with: OSS ALSA JACK DEBUG internet streams resample

On my Debian system it is 2.5.0-alpha3


I don't think pastebin is good for these files. One of them is 12MB (yes MB). When compressed with bz2 it is only 600KB. Link:
http://rapidshare.com/files/172832101/moc_error.tar.bz2.html

the behaviour of your moc version is probably relatet to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=489804

After updating the Debian package all works fine. Thanks a lot!

I have experienced the same problem, but I could not make the same connection between files that you did. Sometimes it crashed with a certain file, and sometime it doesn't! weard hu?

In past there were bugs in libid3tag resulting in crashes, I'm not sure if all known bugs were fixed in official release. Which exact version of the library do you use? Does you distribution patches libid3tags?

Never mind, there was bug in MOC. The fix is in SVN. This file has improper track number which results in reading it as 2147483648 and it was passed to sprintf() supplied with a too short buffer.