boost MPI issue on windows
Hi, I've got an MPI application that uses the boost mpi libraries. It runs fine on OSX and Linux when compiled using both debug and more optimized compiler flags. Unfortunately, on windows, the application only runs when compiled using Visual Studio 2008 debug configuration. When I run the executable compiled in the release configuration it crashes, but not in the same place every time in my code. It does only occur though when I make communicator::send and communicator::recv calls, sending and receiving vectors of ints. In those cases, I get exceptions like: {routine_=0x00d37d38 "MPI_Send" result_code_=805931010 message="MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x001BF950, count=-1833296, MPI_PACKED, dest=1, tag=2001, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -1833296" } Sometimes its for a send and sometimes for a receive, but the exception is always for a "negative count" which looks suspiciously like an uninitialized integer. I figured I'm doing something wrong either in how I've compiled the boost libraries or in my own code (although its odd that it works in both linux and osx). Any suggestions obviously appreciated. This is for boost-1.39. We are prevented from using anything newer because the machine we ultimately deploy on has boost-1.39 installed. On windows, I'm using microsoft's mpi implementation (based on MPICH2) under windows 7. The boost mpi libraries are compiled in both static debug and release mt versions. thanks very much, Nick
On 19 Oct 2010, at 14:04, Nick Collier wrote:
Hi,
I've got an MPI application that uses the boost mpi libraries. It runs fine on OSX and Linux when compiled using both debug and more optimized compiler flags. Unfortunately, on windows, the application only runs when compiled using Visual Studio 2008 debug configuration. When I run the executable compiled in the release configuration it crashes, but not in the same place every time in my code. It does only occur though when I make communicator::send and communicator::recv calls, sending and receiving vectors of ints. In those cases, I get exceptions like:
{routine_=0x00d37d38 "MPI_Send" result_code_=805931010 message="MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x001BF950, count=-1833296, MPI_PACKED, dest=1, tag=2001, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -1833296" }
Sometimes its for a send and sometimes for a receive, but the exception is always for a "negative count" which looks suspiciously like an uninitialized integer.
I figured I'm doing something wrong either in how I've compiled the boost libraries or in my own code (although its odd that it works in both linux and osx). Any suggestions obviously appreciated.
This is for boost-1.39. We are prevented from using anything newer because the machine we ultimately deploy on has boost-1.39 installed.
On windows, I'm using microsoft's mpi implementation (based on MPICH2) under windows 7. The boost mpi libraries are compiled in both static debug and release mt versions.
Not having Windows MPI and not having your code I cannot help much. But here are some suggestions: The send is probably the send in packed_archive_send in point_to_point.cpp Could you add some print statements there to check the size of the archive ar.size(). This is very strange since ar.size() is the size of a std::vector, and that cannot be negative. This sounds like sone strange compiler bug that we should identify and then work around. Matthias
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Could anyone who's been having a problem with Serialization archive back compatibility please update from the SVN trunk and check if the problem still exists? It should be fixed as of r66107. - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAky+mm4ACgkQO/fqqIuE2t6+kQCfUrk/SdsIQeHPYu/mp5FuYUPL J3IAmwVoL3cBy89kmK/8Cgr0VL2vqc9i =Lgpb -----END PGP SIGNATURE-----
Bryce Lelbach <admin <at> thefireflyproject.us> writes:
Could anyone who's been having a problem with Serialization archive back compatibility please update from the SVN trunk and check if the problem still exists? It should be fixed as of r66107.
Sorry to say that, but no, svn trunk does NOT fix the static linking problem. I compiled the svn trunk r66115 with the following command: bjam.exe -q --layout=system --with-system --with-thread --with-python --with-serialization toolset=gcc variant=release link=static threading=multi runtime-link=static Compilation takes bloody ages and produces a lot of this warning:
warning: visibility attribute not supported in this configuration; ignored
After that, trying to link an application using portable_binary_oarchive with libboost_serialization.a results in the following linker erros: Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_iarchiveEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_iarchiveEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_iarchiveEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_iarchiveEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_oarchiveEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_oarchiveEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_oarchiveEEE18get_const_instanceEv: symbol not found Cannot export ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_oarchiveEEE20get_mutable_instanceEv: symbol not found Regards, Philipp
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philip, I don't know where we stand with mingw right now. Ramey added - -fvisibility-hidden to the gcc toolset build flags, but I had to remove this at - -fvisibility-hidden is not supported on mingw and breaks with gcc (code has to be specially designed to work with -fvisibility-hidden). Can you test archive compatibility on MSVC or Linux gcc? We're working on mingw but atm there are a few outstanding issues with it. - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAky+6Y0ACgkQO/fqqIuE2t7E7wCfT/NizpVIloM5JkG98oaD4p2t 0LIAnRoVMmqVghp8CpuUR1Jm3BGfnFHj =nZ/s -----END PGP SIGNATURE-----
On 20.10.2010 15:07 "Bryce Lelbach" <admin@thefireflyproject.us> <admin@thefireflyproject.us> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Can you test archive compatibility on MSVC or Linux gcc? We're working on mingw but atm there are a few outstanding issues with it.
Linux x86 and Linux x64 with gcc 4.5.0 both work flawlessly. I tried a build with MS Visual C++ 2010 Express. Boost builds, but when linking against boost_serialization.lib the following linker error is raised: msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: class std::locale::facet * _ _thiscall std::locale::facet::_Decref(void)" (?_Decref@facet@locale@std@@QAEPAV1 23@XZ) already defined in boost_serialization.lib(binary_oarchive.obj). msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: void __thiscall std::locale: :facet::_Incref(void)" (?_Incref@facet@locale@std@@QAEXXZ) already defined in boost_ serialization.lib(binary_oarchive.obj). msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: static unsigned int __cdecl std::codecvt<char,char,int>::_Getcat(class std::locale::facet const * *,class st d::locale const *)" (?_Getcat@?$codecvt@DDH@std@@SAIPAPBVfacet@locale@2@PBV42@@Z ) already defined in boost_serialization.lib(binary_oarchive.obj. msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: class std::locale __thiscall std::basic_streambuf<char,struct std::char_traits<char> >::getloc(void)const " (?getloc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QBE?AVlocale@2@XZ) already defined in boost_serialization.lib(binary_oarchive.obj). msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: __int64 __thiscall std::basi c_streambuf<char,struct std::char_traits<char> >::sputn(char const *,__int64)" ( ?sputn@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QAE_JPBD_J@Z) already defined in boost_serialization.lib(binary_oarchive.obj). msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: __thiscall std::codecvt<char ,char,int>::codecvt<char,char,int>(unsigned int)" (??0?$codecvt@DDH@std@@QAE@I@Z ) already defined in boost_serialization.lib(binary_oarchive.obj). msvcprt.lib(MSVCP100.dll) : error LNK2005: "protected: virtual __thiscall std::c odecvt<char,char,int>::~codecvt<char,char,int>(void)" (??1?$codecvt@DDH@std@@MAE @XZ) already defined in boost_serialization.lib(binary_oarchive.obj). msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: class std::locale __thiscall std::basic_streambuf<char,struct std::char_traits<char> >::pubimbue(class std:: locale const &)" (?pubimbue@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QAE?A Vlocale@2@ABV32@@Z) already defined in boost_serialization.lib(binary_oarchive.obj). msvcprt.lib(MSVCP100.dll) : error LNK2005: "public: class std::_Yarn<char> & __t hiscall std::_Yarn<char>::operator=(char const *)" (??4?$_Yarn@D@std@@QAEAAV01@P BD@Z) already defined in boost_serialization.lib(binary_oarchive.obj). msvcprt.lib(MSVCP100.dll) : error LNK2005: "private: __thiscall std::locale::_Lo cimp::_Locimp(class std::locale::_Locimp const &)" (??0_Locimp@locale@std@@AAE@A BV012@@Z) already defined in boost_serialization.lib(binary_oarchive.obj). msvcprt.lib(MSVCP100.dll) : error LNK2005: "protected: virtual __thiscall std::l ocale::_Locimp::~_Locimp(void)" (??1_Locimp@locale@std@@MAE@XZ) already defined in b oost_serialization.lib(binary_oarchive.obj). NMAKE : fatal error U1077: ""C:\Program Files\Microsoft Visual Studio 10.0\VC\BI N\link.EXE"": Return-Code "0x450" Stop. Bottom line: boost_serialization is totally useless on Windows, as it neither works with -gcc 3.4.5 -gcc 4.4.0 -msvc 2010 Philipp
Philipp Münzel <mailing-lists <at> philippmuenzel.de> writes:
Bottom line: boost_serialization is totally useless on Windows, as it neither
works with
-gcc 3.4.5 -gcc 4.4.0 -msvc 2010
The VC10 failure seems a bit odd as all the regression tests are passing with it on both the Trunk and release branch (thats with the full version rather than the express version, but i would hope that that wouldn't matter).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Phlipp, can I get the details of your mingw build? mingw throws a win32 stack overflow on my box when compiling libboost_serialization (and fails the compile). On Wed, 20 Oct 2010 12:50:56 +0000 (UTC) Philipp Münzel <mailing-lists@philippmuenzel.de> wrote:
Bryce Lelbach <admin <at> thefireflyproject.us> writes:
Could anyone who's been having a problem with Serialization archive back compatibility please update from the SVN trunk and check if the problem still exists? It should be fixed as of r66107.
Sorry to say that, but no, svn trunk does NOT fix the static linking problem.
I compiled the svn trunk r66115 with the following command: bjam.exe -q --layout=system --with-system --with-thread --with-python --with-serialization toolset=gcc variant=release link=static threading=multi runtime-link=static
Compilation takes bloody ages and produces a lot of this warning:
warning: visibility attribute not supported in this configuration; ignored
After that, trying to link an application using portable_binary_oarchive with libboost_serialization.a results in the following linker erros:
Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_iarchiveEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_iarchiveEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_iarchiveEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_iarchiveEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_oarchiveEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_oarchiveEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_oarchiveEEE18get_const_instanceEv: symbol not found Cannot export ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_13mapI24 portable_binary_oarchiveEEE20get_mutable_instanceEv: symbol not found
Regards, Philipp
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
- -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAky+6jcACgkQO/fqqIuE2t5fAQCcC+7201gwzQkubp8vAl92jgg1 8ngAoJXRR3qJRMaV1dQ49vSxL7mceet8 =2ZJL -----END PGP SIGNATURE-----
Bryce Lelbach <admin <at> thefireflyproject.us> writes:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Phlipp, can I get the details of your mingw build? mingw throws a win32 stack overflow on my box when compiling libboost_serialization (and fails the compile).
I've been running the trunk regression tests with the mingw 4.5.1 build from http://tdm-gcc.tdragon.net/ -> seems more stable than other builds i've tried. The regression test run last night failed but the current trunk version without fvisiblity-hidden is looking better, though there are a lot of /////////// Info: resolving vtable for boost::archive::archive_exception by linking to __imp___ZTVN5boost7archive17archive_exceptionE (auto-import c:/mingw451/bin/../lib/gcc/mingw32/4.5.1/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.) //////////// warnings from the tests.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm looking into the VS 10 thing. I have a feeling this might just be you, or you might need to clean your Serialization build tree, update from trunk, and do a fresh build. Getting mingw to work is my top priority right now. I am a bit crippled on Windows (native *nix user) but I'll get this resolved as soon as possible :) - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAky/B14ACgkQO/fqqIuE2t7KnwCg9aTg/nEJck71sWr34JMo8SDI dDgAoIuFA6Z/i3vp6mz/rDt2Fxba+aOQ =oLSl -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Yah, I'm aware of the warnings, they go away when --enable-auto-import is added. I'm not going to add that flag to the Jamfile until I figure out exactly what the warnings mean, and make sure adding that flag actually fixes the problem. On Wed, 20 Oct 2010 13:28:59 +0000 (UTC) Richard Webb <richard.webb@boldonjames.com> wrote:
Bryce Lelbach <admin <at> thefireflyproject.us> writes:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Phlipp, can I get the details of your mingw build? mingw throws a win32 stack overflow on my box when compiling libboost_serialization (and fails the compile).
I've been running the trunk regression tests with the mingw 4.5.1 build from http://tdm-gcc.tdragon.net/ -> seems more stable than other builds i've tried.
The regression test run last night failed but the current trunk version without fvisiblity-hidden is looking better, though there are a lot of
/////////// Info: resolving vtable for boost::archive::archive_exception by linking to __imp___ZTVN5boost7archive17archive_exceptionE (auto-import c:/mingw451/bin/../lib/gcc/mingw32/4.5.1/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.) ////////////
warnings from the tests.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
- -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEUEARECAAYFAky/CTAACgkQO/fqqIuE2t50bACg36a4WeafqIJ5IEn9GLnMDjKo EzcAl1RSka9OHQyR6PfbcmSOnfTGvIQ= =l76P -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 20 Oct 2010 13:28:59 +0000 (UTC) Richard Webb <richard.webb@boldonjames.com> wrote:
I've been running the trunk regression tests with the mingw 4.5.1 build from http://tdm-gcc.tdragon.net/ -> seems more stable than other builds i've tried.
Thank you. This seems to fail less than my mingw build. Philip, MSVC-10 builds fine and build all examples/tests on my box without error. I think the issue there is on your end. - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAky/J5AACgkQO/fqqIuE2t5aGwCgiNUOHcF+BboneTS4tMGzXgo7 B5MAnRXJ1pEzrGjFjdUikajAbjoh8QMZ =Bnid -----END PGP SIGNATURE-----
On 20.10.2010 19:32 "Bryce Lelbach" <admin@thefireflyproject.us> <admin@thefireflyproject.us> wrote:
Philip, MSVC-10 builds fine and build all examples/tests on my box without error. I think the issue there is on your end.
You were absolutely right. I build boost with runtime-link=static and linked my application to the msvcp100.dll which is obviously a really stupid idea. Having everything setup for link=static and runtime-link=dynamic it works like a charm with msvc2010. Like Linux/GCC 4.5.0 did all the time. So mingw is kind of nice-to-have now. Thanks for testing and putting me on the right path. Regards, Philipp
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 As of r66123 mingw builds serialization and passes all tests on my machine. - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAky/Vp0ACgkQO/fqqIuE2t75mQCfXm9QACwAJJYSwmkreSi1gyqa IrUAoILQBP7ne3pHJbHjQdDHmQ42gcPo =2YId -----END PGP SIGNATURE-----
On 20.10.2010 22:52 "Bryce Lelbach" <admin@thefireflyproject.us> <admin@thefireflyproject.us> wrote:
As of r66123 mingw builds serialization and passes all tests on my machine.
Confirm! Awesome! You are my personal hero of the day :) Regards, Philipp
Bryce Lelbach <admin <at> thefireflyproject.us> writes:
As of r66123 mingw builds serialization and passes all tests on my machine.
The regression tests on Rev 66120 all passed in mingw 4.5.1 in c++98 mode :-). There are still 2 failures in c++0x mode, though those look like problems in the tests rather than in the lib. See http://tinyurl.com/24bkyjx for an example.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 21 Oct 2010 09:10:42 +0000 (UTC) Richard Webb <richard.webb@boldonjames.com> wrote:
Bryce Lelbach <admin <at> thefireflyproject.us> writes:
As of r66123 mingw builds serialization and passes all tests on my machine.
The regression tests on Rev 66120 all passed in mingw 4.5.1 in c++98 mode :-).
There are still 2 failures in c++0x mode, though those look like problems in the tests rather than in the lib. See http://tinyurl.com/24bkyjx for an example.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I'll look into that :) - -- Bryce Lelbach aka wash http://groups.google.com/group/ariel_devel -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkzAFwcACgkQO/fqqIuE2t6SIgCgtOKSX9y++HsssQb84+xyX6d7 +aQAoIsITR/69vQXDnWhJSXl453ITQmS =fbNZ -----END PGP SIGNATURE-----
The fixes to the serialization build have cleared up failures in the serialization tests for several other libs, but there are still errors in the date_time tests (see http://tinyurl.com/28dkxom for the log). The date_time test is complaining about the destructors for text_oarchive_impl and text_iarchive_impl being marked as dllimport. Do the destructors need to be decorated with BOOST_ARCHIVE_DECL when the function bodies are included inline?
Bryce Lelbach <admin <at> thefireflyproject.us> writes:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Phlipp, can I get the details of your mingw build? mingw throws a win32 stack overflow on my box when compiling libboost_serialization (and fails the compile).
I'm using mingw with gcc 4.4 that is shipped with the Qt SDK 2010.5. $ gcc -v Using built-in specs. Target: mingw32 Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32 Thread model: win32 gcc version 4.4.0 (GCC) Philipp
On 20.10.2010 15:10 "Bryce Lelbach" <admin@thefireflyproject.us> <admin@thefireflyproject.us> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Phlipp, can I get the details of your mingw build? mingw throws a win32 stack overflow on my box when compiling libboost_serialization (and fails the compile).
Hi! I'm using minGW with gcc 4.4.0 bundled in the Qt SDK 2010.5. $ gcc -v Using built-in specs. Target: mingw32 Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,jav a,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enabl e-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enab le-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32 Thread model: win32 gcc version 4.4.0 (GCC) Philipp
Bryce Lelbach <admin <at> thefireflyproject.us> writes:
Could anyone who's been having a problem with Serialization archive back compatibility please update from the SVN trunk and check if the problem still exists? It should be fixed as of r66107.
And trying to build a dll for boost serialization with gcc 4.4 fails also: bjam.exe -q --layout=system --with-serialization toolset=gcc variant=release link=shared threading=multi gcc.link.dll bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\threading-m ulti\libboost_serialization.dll.a Creating library file: bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\t hreading-multi\libboost_serialization.dll.aCannot export _ZN5boost13serializatio n9singletonINS_7archive6detail12_GLOBAL__N_13mapINS2_12xml_iarchiveEEEE12get_ins tanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_12xml_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_12xml_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_12xml_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_12xml_oarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_12xml_oarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_12xml_oarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_12xml_oarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_13text_iarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_13text_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_13text_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_13text_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_13text_oarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_13text_oarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_13text_oarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_13text_oarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_15binary_iarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_15binary_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_15binary_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_15binary_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_15binary_oarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_15binary_oarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_15binary_oarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_15binary_oarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_18naked_xml_iarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_18naked_xml_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_18naked_xml_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_18naked_xml_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_19naked_text_iarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_19naked_text_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_19naked_text_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_19naked_text_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_20polymorphic_iarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_20polymorphic_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_20polymorphic_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_20polymorphic_iarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_20polymorphic_oarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_20polymorphic_oarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_20polymorphic_oarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_20polymorphic_oarchiveEEEE20get_mutable_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_21naked_binary_iarchiveEEEE12get_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_21naked_binary_iarchiveEEEE12is_destroyedEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_21naked_binary_iarchiveEEEE18get_const_instanceEv: symbol not found Cannot export _ZN5boost13serialization9singletonINS_7archive6detail12_GLOBAL__N_ 13mapINS2_21naked_binary_iarchiveEEEE20get_mutable_instanceEv: symbol not found collect2: ld returned 1 exit status "g++" "-Wl,--out-implib,bin.v2\libs\serialization\build\gcc-mingw-4.4.0\re lease\threading-multi\libboost_serialization.dll.a" -o "bin.v2\libs\serializatio n\build\gcc-mingw-4.4.0\release\threading-multi\libboost_serialization.dll" -sh ared -Wl,--start-group "bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\ threading-multi\basic_archive.o" "bin.v2\libs\serialization\build\gcc-mingw-4.4. 0\release\threading-multi\basic_iarchive.o" "bin.v2\libs\serialization\build\gcc -mingw-4.4.0\release\threading-multi\basic_iserializer.o" "bin.v2\libs\serializa tion\build\gcc-mingw-4.4.0\release\threading-multi\basic_oarchive.o" "bin.v2\lib s\serialization\build\gcc-mingw-4.4.0\release\threading-multi\basic_oserializer. o" "bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\threading-multi\basi c_pointer_iserializer.o" "bin.v2\libs\serialization\build\gcc-mingw-4.4.0\releas e\threading-multi\basic_pointer_oserializer.o" "bin.v2\libs\serialization\build\ gcc-mingw-4.4.0\release\threading-multi\basic_serializer_map.o" "bin.v2\libs\ser ialization\build\gcc-mingw-4.4.0\release\threading-multi\basic_text_iprimitive.o " "bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\threading-multi\basic _text_oprimitive.o" "bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\thr eading-multi\basic_xml_archive.o" "bin.v2\libs\serialization\build\gcc-mingw-4.4 .0\release\threading-multi\binary_iarchive.o" "bin.v2\libs\serialization\build\g cc-mingw-4.4.0\release\threading-multi\binary_oarchive.o" "bin.v2\libs\serializa tion\build\gcc-mingw-4.4.0\release\threading-multi\extended_type_info.o" "bin.v2 \libs\serialization\build\gcc-mingw-4.4.0\release\threading-multi\extended_type_ info_typeid.o" "bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\threadin g-multi\extended_type_info_no_rtti.o" "bin.v2\libs\serialization\build\gcc-mingw -4.4.0\release\threading-multi\polymorphic_iarchive.o" "bin.v2\libs\serializatio n\build\gcc-mingw-4.4.0\release\threading-multi\polymorphic_oarchive.o" "bin.v2\ libs\serialization\build\gcc-mingw-4.4.0\release\threading-multi\stl_port.o" "bi n.v2\libs\serialization\build\gcc-mingw-4.4.0\release\threading-multi\text_iarch ive.o" "bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\threading-multi\ text_oarchive.o" "bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\thread ing-multi\void_cast.o" "bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\ threading-multi\archive_exception.o" "bin.v2\libs\serialization\build\gcc-mingw- 4.4.0\release\threading-multi\xml_grammar.o" "bin.v2\libs\serialization\build\gc c-mingw-4.4.0\release\threading-multi\xml_iarchive.o" "bin.v2\libs\serialization \build\gcc-mingw-4.4.0\release\threading-multi\xml_oarchive.o" "bin.v2\libs\seri alization\build\gcc-mingw-4.4.0\release\threading-multi\xml_archive_exception.o" "bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\threading-multi\shared _ptr_helper.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -mthreads ...failed gcc.link.dll bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\t hreading-multi\libboost_serialization.dll.a bin.v2\libs\serialization\build\gcc- mingw-4.4.0\release\threading-multi\libboost_serialization.dll... ...removing bin.v2\libs\serialization\build\gcc-mingw-4.4.0\release\threading-mu lti\libboost_serialization.dll.a ...failed updating 1 target...
Sorry for not getting back sooner, and thanks for the initial reply. I added a print to packed_archive_send, so it now looks like: void packed_archive_send(MPI_Comm comm, int dest, int tag, const packed_oarchive& ar) { std::cout << "ar size: " << ar.size() << std::endl; const void* size = &ar.size(); .... When I run this under release mode I with, I get: ar size: 4265919640 MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x01E8AE18, count=-29047656, MPI_PACKED, dest=1, tag =2147483647, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -29047656 When I run it under debug mode, I don't get the error and ar size: 1622. Any suggestions how to proceed are much appreciated. Thanks, Nick On Oct 19, 2010, at 8:20 PM, Matthias Troyer wrote:
On 19 Oct 2010, at 14:04, Nick Collier wrote:
Hi,
I've got an MPI application that uses the boost mpi libraries. It runs fine on OSX and Linux when compiled using both debug and more optimized compiler flags. Unfortunately, on windows, the application only runs when compiled using Visual Studio 2008 debug configuration. When I run the executable compiled in the release configuration it crashes, but not in the same place every time in my code. It does only occur though when I make communicator::send and communicator::recv calls, sending and receiving vectors of ints. In those cases, I get exceptions like:
{routine_=0x00d37d38 "MPI_Send" result_code_=805931010 message="MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x001BF950, count=-1833296, MPI_PACKED, dest=1, tag=2001, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -1833296" }
Sometimes its for a send and sometimes for a receive, but the exception is always for a "negative count" which looks suspiciously like an uninitialized integer.
I figured I'm doing something wrong either in how I've compiled the boost libraries or in my own code (although its odd that it works in both linux and osx). Any suggestions obviously appreciated.
This is for boost-1.39. We are prevented from using anything newer because the machine we ultimately deploy on has boost-1.39 installed.
On windows, I'm using microsoft's mpi implementation (based on MPICH2) under windows 7. The boost mpi libraries are compiled in both static debug and release mt versions.
Not having Windows MPI and not having your code I cannot help much. But here are some suggestions:
The send is probably the send in packed_archive_send in point_to_point.cpp Could you add some print statements there to check the size of the archive ar.size(). This is very strange since ar.size() is the size of a std::vector, and that cannot be negative. This sounds like sone strange compiler bug that we should identify and then work around.
Matthias
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi Nick, On 26 Oct 2010, at 00:52, Nick Collier wrote:
Sorry for not getting back sooner, and thanks for the initial reply. I added a print to packed_archive_send, so it now looks like:
void packed_archive_send(MPI_Comm comm, int dest, int tag, const packed_oarchive& ar) { std::cout << "ar size: " << ar.size() << std::endl; const void* size = &ar.size(); ....
When I run this under release mode I with, I get:
ar size: 4265919640
MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x01E8AE18, count=-29047656, MPI_PACKED, dest=1, tag =2147483647, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -29047656
When I run it under debug mode, I don't get the error and
ar size: 1622.
Any suggestions how to proceed are much appreciated.
This seems to point towards either a bug in your code, that you overwrite the memory location of the packed_oarchive, or a bug in the optimizer. Can you try a simple test program where you are sure that you don't write out of bounds anywhere? You could also try to see what goes on by adding more output statements to the size() function of packed_oprimitive, or add a size function to packed_oarchive that prints internal_buffer_.size() and then calls the size function of the packed_oprimitive base class. It seems that either the internal_buffer_ vector is messed up, or the reference in the base class by either a compiler bug o a bug in your code. Matthias
I winnowed my own code down to a simple scatter call. I get the error under release mode but not under debug. Here's the code: namespace mpi = boost::mpi; int main(int argc, char **argv) { mpi::environment env(argc, argv); mpi::communicator world; vector<int> out; vector<vector<int> > in; if (world.rank() == 0) { for (int i = 0; i < world.size(); ++i) { vector<int> vec(10, 12); in.push_back(vec); } } try { mpi::scatter(world, in, out, 0); } catch (std::exception& ex) { std::cerr << ex.what() << std::endl; throw ex; } cout << world.rank() << " : " << out.size() << endl; } And the error is: ar size: 4293462132 MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x0016F78C, count=-1505164, MPI_PACKED, dest=1, tag= 2147483647, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -1505164 MPI_Alloc_mem: Invalid argument, error stack: MPI_Alloc_mem(119): MPI_Alloc_mem(size=-1505164, MPI_INFO_NULL, baseptr=0x003EF6 8C) failed MPI_Alloc_mem(82).: Invalid value for size, must be non-negative but is -1505164 thanks, Nick On Oct 26, 2010, at 2:58 AM, Matthias Troyer wrote:
Hi Nick,
On 26 Oct 2010, at 00:52, Nick Collier wrote:
Sorry for not getting back sooner, and thanks for the initial reply. I added a print to packed_archive_send, so it now looks like:
void packed_archive_send(MPI_Comm comm, int dest, int tag, const packed_oarchive& ar) { std::cout << "ar size: " << ar.size() << std::endl; const void* size = &ar.size(); ....
When I run this under release mode I with, I get:
ar size: 4265919640
MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x01E8AE18, count=-29047656, MPI_PACKED, dest=1, tag =2147483647, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -29047656
When I run it under debug mode, I don't get the error and
ar size: 1622.
Any suggestions how to proceed are much appreciated.
This seems to point towards either a bug in your code, that you overwrite the memory location of the packed_oarchive, or a bug in the optimizer. Can you try a simple test program where you are sure that you don't write out of bounds anywhere?
You could also try to see what goes on by adding more output statements to the size() function of packed_oprimitive, or add a size function to packed_oarchive that prints internal_buffer_.size() and then calls the size function of the packed_oprimitive base class. It seems that either the internal_buffer_ vector is messed up, or the reference in the base class by either a compiler bug o a bug in your code.
Matthias
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 26 Oct 2010, at 15:52, Nick Collier wrote:
I winnowed my own code down to a simple scatter call. I get the error under release mode but not under debug. Here's the code:
namespace mpi = boost::mpi; int main(int argc, char **argv) { mpi::environment env(argc, argv); mpi::communicator world;
vector<int> out; vector<vector<int> > in; if (world.rank() == 0) { for (int i = 0; i < world.size(); ++i) { vector<int> vec(10, 12); in.push_back(vec); } }
try { mpi::scatter(world, in, out, 0); } catch (std::exception& ex) { std::cerr << ex.what() << std::endl; throw ex; }
cout << world.rank() << " : " << out.size() << endl; }
And the error is:
ar size: 4293462132 MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x0016F78C, count=-1505164, MPI_PACKED, dest=1, tag= 2147483647, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -1505164
This seems to happen in line 73 of boost/mpi/collectives/scatter.hpp . To see where exactly this optimization issue arises, could you please add a print statement std::cerr << oa.size() << std::endl; before line 73 to print the size of the archive there. Matthias
ar.size(), as added below, returns 48 in both debug and release modes. thanks, Nick On Oct 26, 2010, at 4:33 PM, Matthias Troyer wrote:
On 26 Oct 2010, at 15:52, Nick Collier wrote:
I winnowed my own code down to a simple scatter call. I get the error under release mode but not under debug. Here's the code:
namespace mpi = boost::mpi; int main(int argc, char **argv) { mpi::environment env(argc, argv); mpi::communicator world;
vector<int> out; vector<vector<int> > in; if (world.rank() == 0) { for (int i = 0; i < world.size(); ++i) { vector<int> vec(10, 12); in.push_back(vec); } }
try { mpi::scatter(world, in, out, 0); } catch (std::exception& ex) { std::cerr << ex.what() << std::endl; throw ex; }
cout << world.rank() << " : " << out.size() << endl; }
And the error is:
ar size: 4293462132 MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x0016F78C, count=-1505164, MPI_PACKED, dest=1, tag= 2147483647, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -1505164
This seems to happen in line 73 of boost/mpi/collectives/scatter.hpp . To see where exactly this optimization issue arises, could you please add a print statement
std::cerr << oa.size() << std::endl;
before line 73 to print the size of the archive there.
Matthias
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Great, so far all is correct. Could you now please add a similar print statement before lie 31 of libs/mpi/src/point_to_point.cpp ? Matthias On 27 Oct 2010, at 15:41, Nick Collier wrote:
ar.size(), as added below, returns 48 in both debug and release modes.
thanks,
Nick On Oct 26, 2010, at 4:33 PM, Matthias Troyer wrote:
On 26 Oct 2010, at 15:52, Nick Collier wrote:
I winnowed my own code down to a simple scatter call. I get the error under release mode but not under debug. Here's the code:
namespace mpi = boost::mpi; int main(int argc, char **argv) { mpi::environment env(argc, argv); mpi::communicator world;
vector<int> out; vector<vector<int> > in; if (world.rank() == 0) { for (int i = 0; i < world.size(); ++i) { vector<int> vec(10, 12); in.push_back(vec); } }
try { mpi::scatter(world, in, out, 0); } catch (std::exception& ex) { std::cerr << ex.what() << std::endl; throw ex; }
cout << world.rank() << " : " << out.size() << endl; }
And the error is:
ar size: 4293462132 MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x0016F78C, count=-1505164, MPI_PACKED, dest=1, tag= 2147483647, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -1505164
This seems to happen in line 73 of boost/mpi/collectives/scatter.hpp . To see where exactly this optimization issue arises, could you please add a print statement
std::cerr << oa.size() << std::endl;
before line 73 to print the size of the archive there.
Matthias
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
With that in place in Release mode, t 1st (in scatter.hpp) ar.size(): 48 2nd (before line 31 in point_to_point.cpp) ar.size(): 2292879725 In Debug mode, both are 48. thanks, Nick On Nov 1, 2010, at 6:46 AM, Matthias Troyer wrote:
Great, so far all is correct. Could you now please add a similar print statement before lie 31 of libs/mpi/src/point_to_point.cpp ?
Matthias
On 27 Oct 2010, at 15:41, Nick Collier wrote:
ar.size(), as added below, returns 48 in both debug and release modes.
thanks,
Nick On Oct 26, 2010, at 4:33 PM, Matthias Troyer wrote:
On 26 Oct 2010, at 15:52, Nick Collier wrote:
I winnowed my own code down to a simple scatter call. I get the error under release mode but not under debug. Here's the code:
namespace mpi = boost::mpi; int main(int argc, char **argv) { mpi::environment env(argc, argv); mpi::communicator world;
vector<int> out; vector<vector<int> > in; if (world.rank() == 0) { for (int i = 0; i < world.size(); ++i) { vector<int> vec(10, 12); in.push_back(vec); } }
try { mpi::scatter(world, in, out, 0); } catch (std::exception& ex) { std::cerr << ex.what() << std::endl; throw ex; }
cout << world.rank() << " : " << out.size() << endl; }
And the error is:
ar size: 4293462132 MPI_Send: Invalid count, error stack: MPI_Send(176): MPI_Send(buf=0x0016F78C, count=-1505164, MPI_PACKED, dest=1, tag= 2147483647, MPI_COMM_WORLD) failed MPI_Send(101): Negative count, value is -1505164
This seems to happen in line 73 of boost/mpi/collectives/scatter.hpp . To see where exactly this optimization issue arises, could you please add a print statement
std::cerr << oa.size() << std::endl;
before line 73 to print the size of the archive there.
Matthias
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 1 Nov 2010, at 15:41, Nick Collier wrote:
With that in place in Release mode, t
1st (in scatter.hpp) ar.size(): 48
the line after that is a call to: detail::packed_archive_send(comm, dest, tag, oa); and in that function: void packed_archive_send(MPI_Comm comm, int dest, int tag, const packed_oarchive& ar) you immediately print the strange number:
2nd (before line 31 in point_to_point.cpp) ar.size(): 2292879725
In Debug mode, both are 48.
Do you agree? If so, this is a clear optimizer error. Matthias
Yes, immediately before the call its normal, then in the function its the strange number. Nick On Nov 1, 2010, at 3:25 PM, Matthias Troyer wrote:
On 1 Nov 2010, at 15:41, Nick Collier wrote:
With that in place in Release mode, t
1st (in scatter.hpp) ar.size(): 48
the line after that is a call to:
detail::packed_archive_send(comm, dest, tag, oa);
and in that function:
void packed_archive_send(MPI_Comm comm, int dest, int tag, const packed_oarchive& ar)
you immediately print the strange number:
2nd (before line 31 in point_to_point.cpp) ar.size(): 2292879725
In Debug mode, both are 48.
Do you agree? If so, this is a clear optimizer error.
Matthias
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On 1 Nov 2010, at 20:41, Nick Collier wrote:
On Nov 1, 2010, at 3:25 PM, Matthias Troyer wrote:
On 1 Nov 2010, at 15:41, Nick Collier wrote:
With that in place in Release mode, t
1st (in scatter.hpp) ar.size(): 48
the line after that is a call to:
detail::packed_archive_send(comm, dest, tag, oa);
and in that function:
void packed_archive_send(MPI_Comm comm, int dest, int tag, const packed_oarchive& ar)
you immediately print the strange number:
2nd (before line 31 in point_to_point.cpp) ar.size(): 2292879725
In Debug mode, both are 48.
Do you agree? If so, this is a clear optimizer error.
Matthias
Yes, immediately before the call its normal, then in the function its the strange number.
Nick
One potential issue comes to my mind: have you compiled the Boost libraries with the same compiler flags as your code? Matthias
I'm not sure. I'll have to check. boost is obviously compiled with VS 2008 via bjam and my code directly in VS 2008. Note that I switched compilers to VS 2010 and everything now works as expected. More specifically, I recompile boost and my own code with VS 2010 and I no longer get any errors in debug or release modes. thanks, Nick On Nov 2, 2010, at 3:03 PM, Matthias Troyer wrote:
On 1 Nov 2010, at 20:41, Nick Collier wrote:
On Nov 1, 2010, at 3:25 PM, Matthias Troyer wrote:
On 1 Nov 2010, at 15:41, Nick Collier wrote:
With that in place in Release mode, t
1st (in scatter.hpp) ar.size(): 48
the line after that is a call to:
detail::packed_archive_send(comm, dest, tag, oa);
and in that function:
void packed_archive_send(MPI_Comm comm, int dest, int tag, const packed_oarchive& ar)
you immediately print the strange number:
2nd (before line 31 in point_to_point.cpp) ar.size(): 2292879725
In Debug mode, both are 48.
Do you agree? If so, this is a clear optimizer error.
Matthias
Yes, immediately before the call its normal, then in the function its the strange number.
Nick
One potential issue comes to my mind: have you compiled the Boost libraries with the same compiler flags as your code?
Matthias
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (5)
-
Bryce Lelbach -
Matthias Troyer -
Nick Collier -
Philipp Münzel -
Philipp Münzel -
Richard Webb