And another question, do you have by any chance a non-standard setup for your temporary folder? Particularly small, located in memory etc.?
W dniu 16.01.2013 17:09, Marcin Junczys-Dowmunt pisze: > Hi Jacob, > that's not good :) > > First question, are you using the most recent moses version? Does this > happen right away at the beginning when your start the processing or > after some time? > > SIBGUS error and the place where this happens seem to indicate that > something is wrong with memory mapping although I never came across that > particular type of error. Does it happen with a small phrase table too, > eg. first 10000 phrases? > > I have a version that can create phrase tables without memory mapping > (useful for 32bit systems), but this is not yet working for reordering > models. Anyway, I will try to get that working with you. > Best, > Marcin > > W dniu 16.01.2013 16:56, Jacob Dlougach pisze: >> I have decided to try compact phrase tables, but I have come across a >> strange bug in processPhraseTableMin and processLexicalTableMin: they >> both always crash with a core dump on my data. >> >> Here is the stack trace from processLexicalTableMin: >> Program terminated with signal 7, Bus error. >> #0 0x00000000004094cf in construct (value=@0x7f1ce9ffa72f: 16 '\020', >> p=0x7f1c38f2a000 "", this=<optimized out>) at >> moses/TranslationModel/CompactPT/MmapAllocator.h:165 >> 165 new(p) value_type(value); >> (gdb) bt >> #0 0x00000000004094cf in construct (value=@0x7f1ce9ffa72f: 16 '\020', >> p=0x7f1c38f2a000 "", this=<optimized out>) at >> moses/TranslationModel/CompactPT/MmapAllocator.h:165 >> #1 push_back (__x=@0x7f1ce9ffa72f: 16 '\020', this=0x7fffef2e7d80) at >> /usr/include/c++/4.6/bits/stl_vector.h:830 >> #2 operator= (__value=@0x7f1ce9ffa72f: 16 '\020', this=<optimized >> out>) at /usr/include/c++/4.6/bits/stl_iterator.h:425 >> #3 __copy_m<char*, std::back_insert_iterator<std::vector<unsigned >> char, Moses::MmapAllocator<unsigned char> > > > (__result=..., >> __last=<optimized out>, >> __first=0x7f1ccc08fc18 "\020\002οw\305\002\277") at >> /usr/include/c++/4.6/bits/stl_algobase.h:329 >> #4 __copy_move_a<false, char*, >> std::back_insert_iterator<std::vector<unsigned char, >> Moses::MmapAllocator<unsigned char> > > > (__last=<optimized out>, >> __first=<optimized out>, __result=...) at >> /usr/include/c++/4.6/bits/stl_algobase.h:384 >> #5 __copy_move_a2<false, __gnu_cxx::__normal_iterator<char*, >> std::basic_string<char> >, >> std::back_insert_iterator<std::vector<unsigned char, >> Moses::MmapAllocator<unsigned char> > > > (__result=..., __last=..., >> __first=...) at /usr/include/c++/4.6/bits/stl_algobase.h:422 >> #6 copy<__gnu_cxx::__normal_iterator<char*, std::basic_string<char> >, >> std::back_insert_iterator<std::vector<unsigned char, >> Moses::MmapAllocator<unsigned char> > > > ( >> __result=..., __last=..., __first=...) at >> /usr/include/c++/4.6/bits/stl_algobase.h:454 >> #7 Moses::StringVector<unsigned char, unsigned long, >> Moses::MmapAllocator>::push_back<std::basic_string<char> > >> (this=0x7fffef2e7d78, s=...) >> at moses/TranslationModel/CompactPT/StringVector.h:387 >> #8 0x000000000040b0c3 in >> Moses::LexicalReorderingTableCreator::FlushEncodedQueue >> (this=0x7fffef2e7920, force=false) >> at moses/TranslationModel/CompactPT/LexicalReorderingTableCreator.cpp:221 >> #9 0x000000000040c6d2 in Moses::EncodingTaskReordering::operator() >> (this=0x1e8cb08) at >> moses/TranslationModel/CompactPT/LexicalReorderingTableCreator.cpp:372 >> #10 0x000000000044c084 in thread_proxy () >> #11 0x00007f1d7160fe9a in start_thread () from >> /lib/x86_64-linux-gnu/libpthread.so.0 >> #12 0x00007f1d7133ccbd in clone () from /lib/x86_64-linux-gnu/libc.so.6 >> #13 0x0000000000000000 in ?? () >> >> Here is my system information: >> Linux 3.2.0-34-generic #53-Ubuntu SMP x86_64 GNU/Linux >> >> I am planning to build debug version and run it with GDB. Also I will >> try to find a small lexical table so that others could reproduce this >> effect (current one is 800MB). However it would be great if someone >> could propose some workaround for that issue. >> >> Jacob Dlougach >> >> >> _______________________________________________ >> 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
