Crash adding many songs

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Choose 'Add Directory' in the playlist
2. Add a folder containing a lot of songs
   In my case, 'a lot' is somewhere between 6000-10000 tracks.
3. QMMP begins adding songs (slowly, reading the id3 tags?), it gets to around 
5000-6000 songs and crashes. Every time.

What is the expected output? What do you see instead?

  Should be able to add lots of songs. It crashes instead.

What version of the product are you using? On what operating system?

  Version 0.7.4 (As packaged with Mint 17 Cinnamon)

Please provide any additional information below.

  I should note that the songs are located on an NFS volume (my NAS).

  As a workaround, I attempt adding the first 5000 songs, this succeeds. Then some very strange (and perhaps telling?) behaviour kicks in; if I multi-select and add the next 10 albums at once, it will crash. If I add these 10 albums one at a time instead, it works, even though it's the same amount of songs in the end. If I continue adding albums one at a time, it will eventually crash adding just a single album, but I will be able to add more songs than if I added them all together in a group.

  It's interesting that adding many albums at once increases the probability of the crash, even though it will still reach a point where it will always crash adding a single song, you will end up with many more songs in the playlist than if you added them in batches.

Original issue reported on code.google.com by turkey...@gmail.com on 23 Jun 2014 at 7:29

[GoogleCodeExporter]

I should add, when it crashes, QMMP just disappears. There is no crash dialog 
or error information.
Perhaps this should be higher priority since it's a crash bug?

Original comment by turkey...@gmail.com on 23 Jun 2014 at 7:31

[GoogleCodeExporter]

Start qmmp from command line. May be it will produce useful output.

Original comment by trialuser02 on 23 Jun 2014 at 8:31

• Added labels: Priority-Critical
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Woah, I have a callstack... why are there symbols in the release exe? O_o

Crash while parsing ID3v2 from a FLAC file. Check output buffers for ID3 
parsing?
It's strange that it crashes more often the more files are already populating 
the playlist. Is there any shared/temp memory pools, decode memory that might 
be reduced by having many files already loaded in the play list?

#0 __memcpy_sse2_unaligned() at 
/build/buildd/eglibc-2.19/string/../sysdeps/x86_64/multiarch/memcpy-sse2-unalign
ed.S:36
#1 TagLib::ByteVector::replace(TagLib::ByteVector const&, TagLib::ByteVector 
const&)() at /usr/lib/x86_64-linux-gnu/libtag.so.1
#2 TagLib::ID3v2::SynchData::decode(TagLib::ByteVector const&)() at 
/usr/lib/x86_64-linux-gnu/libtag.so.1
#3 TagLib::ID3v2::FrameFactory::createFrame(TagLib::ByteVector const&, 
TagLib::ID3v2::Header*) const() at /usr/lib/x86_64-linux-gnu/libtag.so.1
#4 TagLib::ID3v2::Tag::parse(TagLib::ByteVector const&)() at 
/usr/lib/x86_64-linux-gnu/libtag.so.1
#5 TagLib::ID3v2::Tag::read()() at /usr/lib/x86_64-linux-gnu/libtag.so.1
#6 TagLib::ID3v2::Tag::Tag(TagLib::File*, long, TagLib::ID3v2::FrameFactory 
const*)() at /usr/lib/x86_64-linux-gnu/libtag.so.1
#7 TagLib::FLAC::File::read(bool, TagLib::AudioProperties::ReadStyle)() at 
/usr/lib/x86_64-linux-gnu/libtag.so.1
#8 TagLib::FLAC::File::File(char const*, bool, 
TagLib::AudioProperties::ReadStyle)() at /usr/lib/x86_64-linux-gnu/libtag.so.1
#9 DecoderFLACFactory::createPlayList(QString const&, bool)() at 
/usr/lib/qmmp/Input/libflac.so
#10 MetaDataManager::createPlayList(QString const&, bool) const() at 
/usr/lib/libqmmp.so.0
#11 FileLoader::addFile(QString const&)() at /usr/lib/libqmmpui.so.0
#12 FileLoader::addDirectory(QString const&)() at /usr/lib/libqmmpui.so.0
#13 FileLoader::addDirectory(QString const&)() at /usr/lib/libqmmpui.so.0
#14 FileLoader::run()() at /usr/lib/libqmmpui.so.0

Original comment by turkey...@gmail.com on 23 Jun 2014 at 10:41

[GoogleCodeExporter]

Looks like known taglib bug: https://code.google.com/p/qmmp/issues/detail?id=627

Unfortunately, latest distributions use latest taglib. Try to update taglib and 
qmmp from this ppa: https://launchpad.net/~forkotov02/+archive/ppa

And about debug symbols. I think, you should report this bug here: 
https://packages.debian.org/source/sid/qmmp 
Ubuntu imports this package without modifications.

Original comment by trialuser02 on 23 Jun 2014 at 12:07

[GoogleCodeExporter]

Okay, Updating to the version in the PPA you link fixes one problem, but it 
seems there are 2 problems. That fixed the crash i pasted adding some 
particular songs (taglib fix), but it didn't actually fix the crash adding many 
songs at once.
I was now successfully able to populate the playlist with all my music by 
adding a few albums at a time until they were all added.

I don't understand linux package management or release practises. If you want 
to mention to the appropriate people that they're releasing a build with 
symbols, that'd be good. I'm not sure who to tell or what to tell them.

Original comment by turkey...@gmail.com on 23 Jun 2014 at 10:04

[GoogleCodeExporter]

I'm trying to get another callstack, but it seems to have stopped crashing...
Since I have had all songs added to the playlist before at some point, has it 
decoded the tag info into a database somewhere? It seems if I clear the 
playlist and add everything again that it goes much faster now than before, and 
it stopped crashing now :/

Original comment by turkey...@gmail.com on 23 Jun 2014 at 10:08

[GoogleCodeExporter]

qmmp hasn't database or cache for tags. Possibly these files were cached by OS. 
Also you should try to use gdb. May be it will catch this crash.

Original comment by trialuser02 on 26 Jun 2014 at 6:53

[GoogleCodeExporter]

I did use gdb, that's how I gave you the first callstack. I have no code 
though, so it didn't show me the line.

It's not happening anymore for me though. it only happened the first time I 
tried to populate my library. Now it's populated, I can remove the songs and 
add them again, and it's fine (and faster than the first time).

I was suspicious of a string buffer, or some shared memory used for string 
processing? But that's just a guess.
Anyway, the ppa build works better, hopefully it makes it into the distro soon.

Original comment by turkey...@gmail.com on 26 Jun 2014 at 7:29