Send Moses-support mailing list submissions to
moses-support@mit.edu
To subscribe or unsubscribe via the World Wide Web, visit
http://mailman.mit.edu/mailman/listinfo/moses-support
or, via email, send a message with subject or body 'help' to
moses-support-request@mit.edu
You can reach the person managing the list at
moses-support-owner@mit.edu
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Moses-support digest..."
Today's Topics:
1. Re: Exception when exiting moses (Jeroen Vermeulen)
2. Re: Exception when exiting moses (Jani Dugonik)
----------------------------------------------------------------------
Message: 1
Date: Sun, 21 Jun 2015 22:30:56 +0700
From: Jeroen Vermeulen <jtv@precisiontranslationtools.com>
Subject: Re: [Moses-support] Exception when exiting moses
To: Marcin Junczys-Dowmunt <junczys@amu.edu.pl>, moses-support@mit.edu
Message-ID:
<9C9D9C3A-1F86-49A4-B232-8A38CD7CC2C9@precisiontranslationtools.com>
Content-Type: text/plain; charset=UTF-8
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 <junczys@amu.edu.pl> 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
><junczys@amu.edu.pl> 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
>>>>>> Moses-support@mit.edu
>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>>>>
>>>>> _______________________________________________
>>>>> Moses-support mailing list
>>>>> Moses-support@mit.edu
>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>> _______________________________________________
>>>> Moses-support mailing list
>>>> Moses-support@mit.edu
>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>_______________________________________________
>Moses-support mailing list
>Moses-support@mit.edu
>http://mailman.mit.edu/mailman/listinfo/moses-support
------------------------------
Message: 2
Date: Sun, 21 Jun 2015 16:14:20 +0000
From: Jani Dugonik <Jani.Dugonik@um.si>
Subject: Re: [Moses-support] Exception when exiting moses
To: Jeroen Vermeulen <jtv@precisiontranslationtools.com>, "Marcin
Junczys-Dowmunt" <junczys@amu.edu.pl>, "moses-support@mit.edu"
<moses-support@mit.edu>
Message-ID: <6062457DD8A12440BCDC6E4495BE231C1C73334E@ex2.thor.um.si>
Content-Type: text/plain; charset="us-ascii"
Yes, I'm also having the problem when running MERT, here are the last lines:
terminate called after throwing an instance of 'util::ErrnoException'
what(): util/mmap.cc:52 in void util::UnmapOrThrow(void*, size_t) threw ErrnoException because `munmap(start, length)'.
Invalid argument munmap failed
Aborted
Exit code: 134
The decoder died.
I hope this helps,
Jani
________________________________________
Od: moses-support-bounces@mit.edu [moses-support-bounces@mit.edu] v imenu Jeroen Vermeulen [jtv@precisiontranslationtools.com]
Poslano: 21. junij 2015 17:30
Za: Marcin Junczys-Dowmunt; moses-support@mit.edu
Zadeva: Re: [Moses-support] Exception when exiting moses
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 <junczys@amu.edu.pl> 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
><junczys@amu.edu.pl> 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
>>>>>> Moses-support@mit.edu
>>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>>>>
>>>>> _______________________________________________
>>>>> Moses-support mailing list
>>>>> Moses-support@mit.edu
>>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>>> _______________________________________________
>>>> Moses-support mailing list
>>>> Moses-support@mit.edu
>>>> http://mailman.mit.edu/mailman/listinfo/moses-support
>> _______________________________________________
>> Moses-support mailing list
>> Moses-support@mit.edu
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>
>_______________________________________________
>Moses-support mailing list
>Moses-support@mit.edu
>http://mailman.mit.edu/mailman/listinfo/moses-support
_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
------------------------------
_______________________________________________
Moses-support mailing list
Moses-support@mit.edu
http://mailman.mit.edu/mailman/listinfo/moses-support
End of Moses-support Digest, Vol 104, Issue 69
**********************************************
Subscribe to:
Post Comments (Atom)
0 Response to "Moses-support Digest, Vol 104, Issue 69"
Post a Comment