Bug 84787

Created attachment 6594 [details]
the result of $juk > juk.stdout 2> juk.stderr

this is the best i could do.  i just ran juk from konsole directing the output
and error output to two files (stdout was empty).  the computer hangs at the
very end of the song in this case.

You use Gentoo, so could you please provide your CFLAGS and CXXFLAGS from /etc/make.conf?

Also, what version of arts do you have installed?

I suspect a problem with the ID3 tags which are sometimes added to the end of the .mp3 files, so you can try re-tagging the file with JuK to work around the problem (for example, open up the tag editor, change the Artist tag, change it back to the original, and hit Ctrl-T to force saving the file).

Finally, it would be nice if you could attach the smallest .mp3 file you have that is non-copyrighted that causes the error so that I can try to reproduce.

here's what i can give you:

  my box @home:
  CHOST="i686-pc-linux-gnu"
  CFLAGS="-march=athlon-tbird -O2 -pipe"
  CXXFLAGS="-march=athlon-tbird -O2 -pipe"
  artsd version arts-1.2.3

  my box @work:
  CFLAGS="-march=athlon-tbird -O2 -pipe"
  CHOST="i686-pc-linux-gnu"
  CXXFLAGS="-march=athlon-tbird -O2 -pipe"
  artsd version arts-1.2.3

i also tried editing the id3 info in one of the mp3 files in question (someone had named the file one artist and id3'd the file with a different artist... go fig.)  i played the file, and it killed my system at the same place again.  i should also mention that this has happened with other files as well -- i've just not been smart enough to write down which ones.  but in each file, the "death spot" is at different parts of the track.

as for attaching an afflicted mp3 file, i'm afraid i don't have many non-copyrighted mp3s, let alone small non-copyrighted ones.  if i do come across one though, i will attach it.  i didn't make any of the mp3s in question here, so i don't even know what software could be used to replicate it -- that's assuming it's just not file corruption causing this.  is there anything else i can do here?

I haven't been able to reproduce this bug, which means there's several possibilities:

1) Not a KDE/JuK bug.  Which means the next group of suspects would be the kernel and/or its sound drivers.  Mind you, there IS a kernel bug somewhere, as an application should *never* be able to lock up the system.  If you are using gentoo-dev-sources you may want to report a bug to Gentoo Bugzilla.

2) A KDE bug, but in arts, not JuK.  If this is the case, any multimedia application you use would lock up the computer in the same place.  So try playing your song with kaboodle, or at the command line using artsplay.  If it still crashes your system, please say so, as it's not a juk bug.  If this is the case, and you would like to test arts from CVS, then all you will need to test is the arts module from KDE CVS.  More on that later...

3) A KDE or JuK bug, but fixed in CVS HEAD.  If this is the case, then you may want to try installing enough of KDE from CVS to test to see if this still happens to you.  You can install KDE CVS by following the instructions at http://developer.kde.org/source/anoncvs.html  You will need the following modules: arts, kdelibs, kdebase, kdesupport, kdemultimedia, in that order.

If you choose to install KDE CVS, what you *don't* want to do is install over your stable KDE.  Instead, the best way would be to create a new user, and install KDE in single-user mode.  That's the way I run KDE CVS.  If you need help with installation, try consulting http://quality.kde.org/develop/cvsguide/ or visiting the #kde channel on irc.kde.org

Unfortunately, there's not much I can do to help without being able to reproduce the bug.

No repsonce from the user and this really isn't a JuK bug.  As Michael said, basically if a user-space application is killing your computer there's something wrong elsewhere in your configuration.