Strange memory problem

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start mC2 and let it run.

I think this is related to the indexer somehow. After a while the CPU and
Memory drops at the same time.

It does not appear to be a leak since VLC does not report anything and the
mem is release when indexer is finished.

See attachment for screendump.

Original issue reported on code.google.com by onne...@gmail.com on 25 Apr 2008 at 10:18

Attachments:

• mc2mem.png

[GoogleCodeExporter]

I think it's synchronizing the library.  This is the stack of the only active 
thread
when it happens:
ntkrnlpa.exe+0x69d3f
ntkrnlpa.exe!PsLookupThreadByThreadId+0x4abc
taglib_plugin.dll!std::vector<char,std::allocator<char> >::size+0x1d
taglib_plugin.dll!std::vector<char,std::allocator<char> >::operator[]+0x92
taglib_plugin.dll!TagLib::ByteVector::data+0x47
taglib_plugin.dll!TagLib::ByteVector::replace+0xc3
taglib_plugin.dll!TagLib::ID3v2::SynchData::decode+0xa8
taglib_plugin.dll!TagLib::ID3v2::FrameFactory::createFrame+0x397
taglib_plugin.dll!TagLib::ID3v2::Tag::parse+0x2c6
taglib_plugin.dll!TagLib::ID3v2::Tag::read+0x13b
taglib_plugin.dll!TagLib::ID3v2::Tag::Tag+0xdb
taglib_plugin.dll!TagLib::MPEG::File::read+0xa5
taglib_plugin.dll!TagLib::MPEG::File::File+0xf9
taglib_plugin.dll!TagReaderTaglib::GetID3v2Tag+0x97
taglib_plugin.dll!TagReaderTaglib::ReadTag+0xe3
mC2.exe!musik::core::Indexer::SyncDirectory+0x59d
mC2.exe!musik::core::Indexer::SyncDirectory+0x359
mC2.exe!musik::core::Indexer::Synchronize+0x321
mC2.exe!musik::core::Indexer::ThreadLoop+0x62
mC2.exe!boost::_mfi::mf0<void,musik::core::Indexer>::operator()+0x35
mC2.exe!boost::_bi::list1<boost::_bi::value<musik::core::Indexer *>
>::operator()<boost::_mfi::mf0<void,musik::core::Indexer>,boost::_bi::list0>+0x4
7
mC2.exe!boost::_bi::bind_t<void,boost::_mfi::mf0<void,musik::core::Indexer>,boos
t::_bi::list1<boost::_bi::value<musik::core::Indexer
*> > >::operator()+0x4f
mC2.exe!boost::detail::function::void_function_obj_invoker0<boost::_bi::bind_t<v
oid,boost::_mfi::mf0<void,musik::core::Indexer>,boost::_bi::list1<boost::_bi::va
lue<musik::core::Indexer
*> > >,void>::invoke+0x3f
mC2.exe!boost::function0<void,std::allocator<boost::function_base> 
>::operator()+0x7b
mC2.exe!thread_proxy+0x51
mC2.exe!_callthreadstartex+0x51
mC2.exe!_threadstartex+0xa2
kernel32.dll!GetModuleFileNameA+0x1b4

Not freeing temporary objects until Synchronize() ends could explain the memory 
usage.

Original comment by bjorn.ol...@gmail.com on 25 Apr 2008 at 12:38

[GoogleCodeExporter]

Located the problem to SQLite 3.5.8
The problem is a SQL statement in the Indexer::SyncOptimize where the 
tracks-tables
sort_order is set. Using SQLite 3.5.7 this statement take around 0.2seconds in
release. In 3.5.8 it steals alot of memory and takes around 40 seconds to 
complete.

Original comment by onne...@gmail.com on 25 Apr 2008 at 12:54

[GoogleCodeExporter]

SQLite team is taking a look :)

Original comment by onne...@gmail.com on 25 Apr 2008 at 1:13

[GoogleCodeExporter]

I rewrote the statement to work alot faster. The bug is a known SQLite bug, and 
will
be fixed in the future.

Original comment by onne...@gmail.com on 25 Apr 2008 at 1:36

• Changed state: Fixed