Crash when adding shares

Submitted by secretsquizza on Mon, 08/08/2011 - 11:28
Forums: 
Soulseek General Discussion

Hi,

Must say I love the direction of the new client (PC version on win7 32-bit. SoulseekQt nightly build 7/31/2011). Stumbled across it by accident today, so I'm very new to it. Apologies if this has already been posted, but I received a crash when adding a large folder to the shares.

I'd already got one folder added containing just under 10k files.
When I go to add a second folder (I've not tried adding it on its own), that contains over 51k files (userlist only - which is currently empty), I get a visual c++ runtime error stating "This application has requested the runtime to terminate in an unusual way. Please contact the application's support team for more information".

I haven't attached the debugger as per previous bug reports - can do if you can't replicate or need me to for any reason.

Thanks (and keep up the good work!),

Squizz.

Submitted by Nir on Mon, 08/08/2011 - 17:07.

Hi squizz,

A crash report would be very helpful here certainly. Another thing you can try is sharing a folder that has just some of the 51k files, have the client scan them (diagnostics->mp3 scan tab should stop showing activity), close the client, add some more files/folders, restart the client, repeat... If it's a particular file that's crashing the client you might be able to isolate it this way, and I might be able to reproduce the bug if I have that file as well.

Thanks, Nir

Submitted by secretsquizza on Mon, 08/08/2011 - 23:16.

Hi Nir,

Thanks for the quick reply. I'll get on it a bit later after I finish work (got to debug my own code now!). Will send a crash report and try and trim down the issue to fewer files - there are many subfolders in the main folder, so should be easy enough to narrow down to the culprit file(s).

Cheers,

Squizz.

Submitted by secretsquizza on Tue, 08/09/2011 - 11:08.

I found the problem file - for some reason there was a file amongst my shares just titled "8" ( I have no idea what it is - but it scanned without virii). This particular file was causing the issue. I have removed the file and the rest of the shares load without issue.

I was unable to get the debugger version to work correctly and visual studio wouldn't allow debugging. You can try yourself with the file below if you want however.

Here is a mediafire link for the file (in case you wish to debug - it never caused a problem in the older client):

http://www.mediafire.com/download.php?ht023ykfbe7acsy

Submitted by Nir on Wed, 08/10/2011 - 18:44.

I tried sharing the file on two different computers and couldn't get the client to crash, I guess that means there's a good chance this is not related to scanning the MP3 per se. Ironically during all the sharing and re-sharing I discovered a rather worrisome bug in the underlying data management system that can result in loss of information. I'd say there's only a small to moderate chance this has anything to do with your crash, but I see you're using the PC version so I'll link here to a fixed build later tonight. If you decide to try it out, I suggest that you start with a clean client configuration by removing or renaming c:\soulseek-client.dat. Or you could go ahead with what you have and see how it goes.

edit: Here we go: SoulseekQt data loss fix.zip

Submitted by secretsquizza on Thu, 08/11/2011 - 11:35.

I've found the issue, although your fixed version did not resolve it. As soon as I added a file extension to the file (I renamed it the 8.dat) it loaded the share without a problem, without the file extension it causes the crash.

I was unable to locate c:\soulseek-client.dat as it simply isn't in the root of c: on my machine. After some major searching (after i tested the fix), I found it in c:\users\me\appData\Local\VirtualStore . You have to press "show compatability files" on the root of c: to be zapped to the location of the dat file. I guess windows 7 is protecting the root of c somehow - could this be affecting things??

Squizz

Submitted by Nir on Fri, 08/12/2011 - 01:10.

Good catch! There was an out-of-bounds problem with one of the string manipulation functions in the share scanning code that triggered when processing filenames shorter than 4 characters. I posted the fixed version to the download page. Thank you for helping track down this bug.