Comment 2 for bug 285630

> Окт 19 02:19:20 <erikh> I did find some funky string allocations in Ember::WfutSession. I've committed a fix for those, could you update and see if that has anything to do with it (probably not).
This didn't helped.

> Окт 19 02:18:05 <erikh> Nope. Going through your bt. But FileParser.cpp:48 shouldn't even try to access any string, at least not in my version of libwfut.
> Окт 19 02:18:19 <erikh> It says "parseFile(e, file);"
> Окт 19 02:18:40 <erikh> And parsefile accepts a reference and a pointer, so there's no dereferencing going on.
It accesses string somewhere from parseFile(), from #0 frame - it doesn't show inlined calls.

At /usr/include/c++/4.3.0/bits/basic_string.h:278 there is private function that accesses private data (_M_data()).
And the only access to std::string from parseFile() is
   file.filename = Encoder::decodeString(fname);
file is FileObject _struct_, and file.filename is its std::string member. I'm unsure about are members in structs constructed properly. Probably will be better to have it as simple classes.