muscan -s <dir> segfaults

[snayle]

With actual revision (981) every attempt to scan my shares with

% muscan -v -s <dir containing mp3s/oggs>

is segfaulting without doing any work.

Some revisions ago (974) it still was able to scan a few files but then segfaulted when scanning a particular dir which I wasn't able to identify, sorry.

[belegdol]

Seems to work fine here. Would you be able to obtain a backtrace?

[snayle]

OK svn-muscan now scans again. It got confused with the config file of the 0.1.13 stable client. Obviously its using a different config format for that.

With this being fixed I'm running into the old error again. It scans a lot of files but segfaults in a certain directory. And since it doesn't seem to the dirs in a particular order, I can't say which folder is causing the problems. The 0.1.13 muscan program doens't even seem to be bothered by a file and just runs through it, so no 'corrupt mp3' warnings.

And yes, I 'would' be able to obtain a backtrace if I knew how to make one ;)

[lbponey]

As far as I remember, I didn't make many significant changes to muscan. This could be an encoding problem maybe? Do you have strange letters (accents for example) in file names? Backtraces would be greatly appreciated! I can help you to make it: how did you install muscan? using a package or from svn? If you built it from sources, you have to do a debug release (configurable in cmake). If you use debian repository, you'll have to install dbg packages I think (I never tested it personally). Once you have a debug version installed, run muscan with the following command line: gdb muscan -v -s <dir containing mp3s/oggs> Then type 'run' to launch muscan. When muscan crashes, type 'bt' and copy here the output.

Tell me if you have any problem!

[snayle]

Hi lbponey, thank you for your quick reply. I found out that the problem lies in creating the shares db or just finishing the scan. It is _not_ the charsets, because it also fails on absolute clean mp3 directories (I tested on some smaller dirs). On one of the tries there was an actual error message printed here:

terminate called after throwing an instance of 'std::length_error'

what(): basic_string::_S_create

It looks helpful and I hope it is. I've built the svn version by sources using cmake 2.6-patch2 (built from sources). If you still need a real backtrace, tell me then I will follow the instructions you gave me.

[snayle]

If you built it from sources, you have to do a debug release (configurable in cmake).

Please tell me how to configure Cmake to build a debug rls. I din't find the right switch in the man page.

[lbponey]

Thanks. A backtrace would be very useful too. To build a debug release, add this to the cmake command:

-DCMAKE_BUILD_TYPE=Debug

[lbponey]

Oh, and you can also launch muscan with "-v" option to have a muscan log.

[lbponey]

And could you also tell me if you're running muscan on a linux platform?

[mike-labo]

Same issue here :

muscan does the scan, begins to save the config.shares.state (just a few bytes), and then :

[museek.direntry] pack [museek.direntry] pack [museek.direntry] pack

Program received signal SIGSEGV, Segmentation fault. 0xb7c9a3fa in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6

My system is debian lenny with kernel 2.6.26-1-686. I tried with the dev-packages (1:0.2~newnet+20081013+r974-1) and from the svn source.

[lbponey]

Thanks for that! Can you give a full backtrace (command 'bt' in gdb)?

[mike-labo]

This is the backtrace :

#0 0xb7c6d3fa in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string () from /usr/lib/libstdc++.so.6 #1 0x08071104 in DirEntry::pack (this=0x8b38470) at /tmp/museek+/Muhelp/DirEntry.cc:154 #2 0x08070f62 in DirEntry::pack (this=0x8b2f3f8) at /tmp/museek+/Muhelp/DirEntry.cc:141 #3 0x08070f62 in DirEntry::pack (this=0xbff9c3cc) at /tmp/museek+/Muhelp/DirEntry.cc:141 #4 0x08071f10 in DirEntry::save (this=0xbff9c3cc, fn=@0xbff9c428) at /tmp/museek+/Muhelp/DirEntry.cc:166 #5 0x08067aa2 in main (argc=5, argv=0xbff9c614) at /tmp/museek+/muscan/muscan.cc:147

[lbponey]

Thanks to all of you! This was a strange bug... I think it is solved in r1004. Test it and reopen this ticket if you still have problems.