ScarletFire build

Of course, started to check before going to work)
Win8 x64

If program closed in tray - nothing any errors.
In windowed mode it works 5-10 min.

SoulseekQt.exe caused a Stack Overflow at location 0042a383 in module SoulseekQt.exe.

Registers:
eax=000930b8 ebx=000930b8 ecx=09476ef0 edx=0009305c esi=0124d158 edi=000931e4
eip=0042a383 esp=00092fb0 ebp=0009305c iopl=0 nv up ei pl nz na po nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210206

Call stack:

crushed in 5 minutes. =(

SoulseekQt.exe caused a Stack Overflow at location 00ed65ec in module SoulseekQt.exe.

Registers:
eax=00200000 ebx=0b5418f0 ecx=0b5418f0 edx=0f696310 esi=0b5418f0 edi=01435178
eip=00ed65ec esp=00092fd0 ebp=000930cc iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00210202

Call stack:
00ED65EC SoulseekQt.exe:00ED65EC google::sparse_hashtable, google::libc_allocator_with_realloc >::Identity, google::sparse_hash_set, google::libc_allocator_with_realloc >::SetKey, std::equal_to, google::libc_allocator_with_realloc >::find_position sparsehashtable.h:842
struct pair google::sparse_hashtable, google::libc_allocator_with_realloc >::Identity, google::sparse_hash_set, google::libc_allocator_with_realloc >::SetKey, std::equal_to, google::libc_allocator_with_realloc >::find_position(
struct sparse_hashtable * this = ,
struct Item * key = )
000931B8
004289A8 SoulseekQt.exe:004289A8 ItemSet::erase stl_iterator.h:734
void ItemSet::erase(
struct ItemSet * this = ,
struct Item * i_item = )
004247F2 SoulseekQt.exe:004247F2 TypeItemsMap::iterator::items Data.cpp:2354
struct ItemSet * TypeItemsMap::iterator::items(
struct iterator * this =
)
00428EF3 SoulseekQt.exe:00428EF3 Data::MarkItemConnections Data.cpp:598
void Data::MarkItemConnections(
struct Data * this = ,
struct ItemBody * ip_item = ,
struct TypeItemsMap m_typeItemsMap = {
struct pair * mp_pair = ,
SparseTypeMap * mp_map =
}
}
)

I deleted the old settings and its work good. Need again to share all the music, maybe it was the cause.

***
crushed while sharing. perhaps because of the large volume.

SoulseekQt.exe caused a Stack Overflow at location 00ed65ec in module SoulseekQt.exe.

Registers:
eax=00200000 ebx=0b6a3930 ecx=0b6a3930 edx=0dfc45e8 esi=0b6a3930 edi=01435178
eip=00ed65ec esp=00092fd0 ebp=000930cc iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010202

Call stack:
00ED65EC SoulseekQt.exe:00ED65EC google::sparse_hashtable, google::libc_allocator_with_realloc >::Identity, google::sparse_hash_set, google::libc_allocator_with_realloc >::SetKey, std::equal_to, google::libc_allocator_with_realloc >::find_position sparsehashtable.h:842
struct pair google::sparse_hashtable, google::libc_allocator_with_realloc >::Identity, google::sparse_hash_set, google::libc_allocator_with_realloc >::SetKey, std::equal_to, google::libc_allocator_with_realloc >::find_position(
struct sparse_hashtable * this = ,
struct Item * key = )
000931B8
004289A8 SoulseekQt.exe:004289A8 ItemSet::erase stl_iterator.h:734
void ItemSet::erase(
struct ItemSet * this = ,
struct Item * i_item = )
004247F2 SoulseekQt.exe:004247F2 TypeItemsMap::iterator::items Data.cpp:2354
struct ItemSet * TypeItemsMap::iterator::items(
struct iterator * this =
)
00428EF3 SoulseekQt.exe:00428EF3 Data::MarkItemConnections Data.cpp:598
void Data::MarkItemConnections(
struct Data * this = ,
struct ItemBody * ip_item = ,
struct TypeItemsMap m_typeItemsMap = {
struct pair * mp_pair = ,
SparseTypeMap * mp_map =
}
}
)

3Tb = 320k files. But in previous build it works) check work with less, and will increase.

do not quite understand. I repeated every situation case by 2-3 times, and each time the same reports.
code after the "Call stack:" debugger generates after some time.

may still be some information or settings will help to understand?

Thanks. Now I continue to check this build. Files (about 1Tb) are added to share and everything works.

sir yes sir!
The client has been operating for almost an hour. Restarted several times - problems keeping share are not seen.
I continue to check work and I will write about the results.

First each time on start the client rescanned some files (about 3k), I do not understand why these files, but the launch of "resсan shares" fix everything.

and now back to praise)
Memory consumption has decreased clearly.
the amount and time of freezes was noticeably smaller.

Great thanks to you both. Willing to be a guinea pig at any time)

I learned the scan log, each time the same albums. 4-5 albums from different groups for each letter of the alphabet in order, including numbers and Cyrillic. I understand the logic of the program in it, but you know better)
Number of shared files i check in rooms, and am seen the difference in the 3k files before and after of rescan.

glad to know that I was able to find another bug. thanks for the speed of their correction. continue further testing.