I don't think it's your fault. It seems an incorrect copy of mmapallocator is created somewhere that tries to unmap itself at destruction. Since the file has already been unmapped it throws an exception. I am still not sure where that copy is coming from. Maybe that's due to c++11? Maybe that new emplacement constructor.
On 21.06.2015 16:26, Jeroen Vermeulen wrote: > Hope I didn't break the mmap allocator - though that would have been > some time back anyway. > > It does remind me that Boost has a portable mmap wrapper. It's in the > iostreams library. Might be worth trying to replace kenlm's wrappers > with that one to reduce maintenance burden. > > > Jeroen > > On June 21, 2015 8:47:50 PM GMT+07:00, Marcin Junczys-Dowmunt > <[email protected]> wrote: >> Recompiling it just now with debug on. There is already a mistake in >> >> https://github.com/moses-smt/mosesdecoder/blob/master/moses/TranslationModel/CompactPT/MmapAllocator.h#L156 >> >> The size is wrong, the offset is missing. But it wasn't that. >> >> #0 0x00007ffff6e05cc9 in __GI_raise (sig=sig@entry=6) at >> ../nptl/sysdeps/unix/sysv/linux/raise.c:56 >> #1 0x00007ffff6e090d8 in __GI_abort () at abort.c:89 >> #2 0x00007ffff792e6b5 in __gnu_cxx::__verbose_terminate_handler() () >> from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >> #3 0x00007ffff792c836 in ?? () from >> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >> #4 0x00007ffff792b8f9 in ?? () from >> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >> #5 0x00007ffff792c4aa in __gxx_personality_v0 () from >> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 >> #6 0x00007ffff73c1ff3 in ?? () from >> /lib/x86_64-linux-gnu/libgcc_s.so.1 >> #7 0x00007ffff73c2517 in _Unwind_Resume () from >> /lib/x86_64-linux-gnu/libgcc_s.so.1 >> #8 0x00000000004798a7 in util::UnmapOrThrow (start=<optimized out>, >> length=<optimized out>) >> at util/mmap.cc:52 >> #9 0x00000000005552c1 in _M_deallocate (__n=<optimized out>, >> __p=<optimized out>, this=0x12ba3a0) >> at /usr/include/c++/4.8/bits/stl_vector.h:174 >> #10 ~_Vector_base (this=0x12ba3a0, __in_chrg=<optimized out>) >> at /usr/include/c++/4.8/bits/stl_vector.h:160 >> #11 ~vector (this=0x12ba3a0, __in_chrg=<optimized out>) at >> /usr/include/c++/4.8/bits/stl_vector.h:416 >> #12 Moses::StringVector<unsigned char, unsigned long, >> Moses::MmapAllocator>::~StringVector ( >> this=0x2746458, __in_chrg=<optimized out>) at >> moses/TranslationModel/CompactPT/StringVector.h:154 >> #13 0x000000000055862e in >> Moses::LexicalReorderingTableCompact::~LexicalReorderingTableCompact ( >> this=0x2746000, __in_chrg=<optimized out>) >> at >> moses/TranslationModel/CompactPT/LexicalReorderingTableCompact.cpp:56 >> #14 0x0000000000558669 in >> Moses::LexicalReorderingTableCompact::~LexicalReorderingTableCompact ( >> this=0x2746000, __in_chrg=<optimized out>) >> at >> moses/TranslationModel/CompactPT/LexicalReorderingTableCompact.cpp:60 >> #15 0x00000000005269b3 in checked_delete<Moses::LexicalReorderingTable> >> >> (x=<optimized out>) >> at /usr/include/boost/checked_delete.hpp:34 >> #16 ~scoped_ptr (this=0x12c4408, __in_chrg=<optimized out>) >> at /usr/include/boost/smart_ptr/scoped_ptr.hpp:82 >> #17 Moses::LexicalReordering::~LexicalReordering (this=0x12c4360, >> __in_chrg=<optimized out>) >> at moses/FF/LexicalReordering/LexicalReordering.cpp:82 >> #18 0x0000000000526b99 in Moses::LexicalReordering::~LexicalReordering >> (this=0x12c4360, >> __in_chrg=<optimized out>) at >> moses/FF/LexicalReordering/LexicalReordering.cpp:83 >> #19 0x000000000045ea06 in >> RemoveAllInColl<std::vector<Moses::FeatureFunction*> > (coll=...) >> at ./moses/Util.h:436 >> #20 Moses::FeatureFunction::Destroy () at >> moses/FF/FeatureFunction.cpp:38 >> #21 0x0000000000417157 in batch_run () at moses/ExportInterface.cpp:274 >> #22 0x00000000004184d8 in decoder_main (argc=5, argv=0x7fffffffdef8) at >> >> moses/ExportInterface.cpp:327 >> #23 0x00007ffff6df0ec5 in __libc_start_main (main=0x40c6b0 <main(int, >> char**)>, argc=5, >> argv=0x7fffffffdef8, init=<optimized out>, fini=<optimized out>, >> rtld_fini=<optimized out>, >> stack_end=0x7fffffffdee8) at libc-start.c:287 >> #24 0x0000000000415d2a in _start () >> >> >> On 21.06.2015 15:44, Kenneth Heafield wrote: >>> What exception? I can haz stack trace? >>> >>> On 06/21/2015 09:02 AM, Marcin Junczys-Dowmunt wrote: >>>> Hi, >>>> is anyone else getting exceptions when moses exits with the latest >>>> master? It seems to be happening in my reordering table and breaks >> MERT. >>>> Wasn't me though :) >>>> >>>> _______________________________________________ >>>> Moses-support mailing list >>>> [email protected] >>>> http://mailman.mit.edu/mailman/listinfo/moses-support >>>> >>> _______________________________________________ >>> Moses-support mailing list >>> [email protected] >>> http://mailman.mit.edu/mailman/listinfo/moses-support >> _______________________________________________ >> Moses-support mailing list >> [email protected] >> http://mailman.mit.edu/mailman/listinfo/moses-support _______________________________________________ Moses-support mailing list [email protected] http://mailman.mit.edu/mailman/listinfo/moses-support
