> I am seeing this error on Cray-KNL machine compiled with the intel
> compiler in release mode (but not in debug mode). (The problem does not
> change/go away when I modify the avx flags passed to the compiler, which
> can change alignment apparently)
>
> A parcel is serialized with size 0x8d bytes and transmitted, but when
> deserialized, it tries to read 0x96 bytes from the stream and throws the
> exception " {what}: archive data bstream is too short:
> HPX(serialization_error)"
>
> Ideas on how to track down the problem are welcome.
What data types is it trying to (de-)serialize?
Does the same happen if you modify the serialization test to use the same
data types (see
https://github.com/STEllAR-GROUP/hpx/blob/master/tests/performance/local/ser
ialization_overhead.cpp)?
Are arrays involved? Does the problem go away if you disable array
optimizations (--hpx:ini=hpx.parcel.array_optimization=0)?
Is zero-copy serialization happening? Does the problem go away when you
disable it (--hpx:ini=hpx.parcel.zero_copy_serialization=0)?
Needless to say, I assume you're using the same compiler flags for both ends
of the pipe.
Regards Hartmut
---------------
http://boost-spirit.com
http://stellar.cct.lsu.edu
>
> JB
>
>
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:hpx-users-
> [email protected]] On Behalf Of Thomas Heller
> Sent: 12 December 2016 10:27
> To: [email protected]
> Subject: Re: [hpx-users] archive data bstream data chunk size mismatch:
> HPX(serialization_error)
>
> On Montag, 12. Dezember 2016 10:12:11 CET Tim Biedert wrote:
> > Thank you for the feedback! Unfortunately, this hasn't solved the
> > deserialization error. However, I'm sure this has made the code more
> > robust! ;-)
> >
> > What do you suggest to localize the deserialization error? Is it
> > possible to determine which action would have been called with the
> > deserialized data?
>
> Yes, it is. start your application with --hpx:attach-debugger=exception.
>
> Eventually you'll get a message that an exception has occured and the PID
> as well as the host where the exception occurred. Once you attached your
> debugger, for example gdb, you have to figure out which thread threw the
> exception (info threads). The thread that sits in the sleep function is
> the one you are looking for. Switch to it, and inspect the backtrace.
>
> Does this help?
>
> >
> > Best,
> >
> > Tim
> >
> > On 12/09/2016 04:20 PM, Hartmut Kaiser wrote:
> > > Tim,
> > >
> > > Sorry, this should have been:
> > > hpx::apply_cb<server::Block::receiveImage_action>(
> > >
> > > recipient,
> > > [this](boost::system::error_code const&,
> > > hpx::parcelset::parcel
> > >
> > > const&) mutable
> > >
> > > { delete this; },
> > >
> > > this->image);
> > >
> > > I.e. the callback needs to conform to this prototype:
> > > void callback(
> > >
> > > boost::system::error_code const&,
> > > hpx::parcelset::parcel const&);
> > >
> > > HTH
> > > Regards Hartmut
> > > ---------------
> > > http://boost-spirit.com
> > > http://stellar.cct.lsu.edu
> > >
> > >> -----Original Message-----
> > >> From: Hartmut Kaiser [mailto:[email protected]]
> > >> Sent: Friday, December 9, 2016 9:09 AM
> > >> To: '[email protected]' <[email protected]>
> > >> Subject: RE: [hpx-users] archive data bstream data chunk size
> mismatch:
> > >> HPX(serialization_error)
> > >>
> > >> Tim,
> > >>
> > >>> could the following two lines cause the issue?
> > >>>
> > >>> hpx::apply<server::Block::receiveImage_action>(recipient,
> > >>> this->image);
> > >>>
> > >>> delete this;
> > >>>
> > >>> Basically, we're invoking a fire and forget action with a member
> > >>> variable (which will be serialized) as parameter. Afterwards, the
> > >>> instance is directly deleted. I guess the serialization/parameter
> > >>> transmission of the action does not happen right away and we're
> > >>> deleting the send buffer too early.
> > >>>
> > >>> How can we know - without using async() and waiting for the future
> > >>> - that the "fire part" of fire and forget has been completed and
> > >>> we can delete the send buffer?
> > >>
> > >> You might want to do this instead:
> > >> hpx::apply_cb<server::Block::receiveImage_action>(
> > >>
> > >> recipient,
> > >> [this]() mutable { delete this; }
> > >> this->image);
> > >>
> > >> instead.
> > >>
> > >> hpx::apply_cb calls the supplied function whenever it's safe to
> > >> release the data.
> > >>
> > >> Regards Hartmut
> > >> ---------------
> > >> http://boost-spirit.com
> > >> http://stellar.cct.lsu.edu
> > >
> > > _______________________________________________
> > > hpx-users mailing list
> > > [email protected]
> > > https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
>
>
> _______________________________________________
> hpx-users mailing list
> [email protected]
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
> _______________________________________________
> hpx-users mailing list
> [email protected]
> https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
_______________________________________________
hpx-users mailing list
[email protected]
https://mail.cct.lsu.edu/mailman/listinfo/hpx-users
