Could be, but I hope it's unlikely. If it's not it could bite a lot of people!
It's called a "move" constructor and there's an assignment version as well. Unless you go out of your way to make it happen, a "move" happens when you copy-construct or copy-assign, and the right-hand expression is an rvalue. The move constructor or move assignment operator is free to "steal" any memory the original might have allocated etc. - because it's a temporary and won't be used again anyway. No need to copy it; just take over the pointers. The important thing to keep in mind in that situation is that the right-hand value will still go through its destructor. So you need to leave it in a state where its destructor won't deallocate the memory you now have pointers to etc. But I wouldn't know how to deal with any of this without using C++11-specific syntax. Jeroen On June 21, 2015 9:38:19 PM GMT+07:00, Marcin Junczys-Dowmunt <[email protected]> wrote: >Yay, error disappears with c++11 disabled. Now I need to find out what >is going on. So I am the first C++11 victim after all although I was so > >happy to welcome it :) Karma. > >On 21.06.2015 16:31, Marcin Junczys-Dowmunt wrote: >> 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 > >_______________________________________________ >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
