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

Reply via email to