Charm++ parallel programming system

[Gengbin Zheng <gzheng AT illinois.edu>]

Ok, looks like there are two issues

1.  in your test code, you have a pup to the multicast message:

  void pup(PUP::er &p){
    CkMcastBaseMsg::pup(p);
    CMessage_MapMsg::pup(p);
    p|key;
    p|n;
    p|cb;
    p|a;
  }

    here, CMessage_MapMsg::pup(p); will actually pup the whole message
byte-by-byte, including envelope.
    This is not a big deal though, but you probably don't want that.


2. there is a subtle bug in ckmulticast when using packing functions.
    Some local variable was assigned as a reference to a field in the
arriving message, which after packing (in CkCopyMsg), can be free'ed,
resulting to an invalid reference.

    I  checked in a fix, so now it should work with pack/unpack functions.


Gengbin


On Thu, Mar 29, 2012 at 10:28 PM, Jetley, Pritish 
<pjetley2 AT illinois.edu>
 wrote:
> Hi Gengbin,
>
> Sorry for taking long to get back to you. I've been unwell.
>
> I've checked in a test program to git:
>
> git clone charmgit:users/jetley/mcast_test
>
> Try the program without -DPACK_MSG added to OPTS (in the makefile) and with
> it. The first case will work, since it uses varsize arrays to pack the
> pupable object into the MapMsg. The second one seems to segfault while doing
> findNonInline().
>
> $ ./test 23
> Charm++: standalone mode (not using charmrun)
> Converse/Charm++ Commit ID: v6.4.0-beta1-42-g9206373
> Charm++> scheduler running in netpoll mode.
> CharmLB> Load balancer assumes all CPUs are same.
> Charm++> Running on 1 unique compute nodes (2-way SMP).
> Charm++> cpu topology info is gathered in 0.001 seconds.
> [0] redistribute 23 a 80 90
> [0] g a: 5 10
> [0] g a: 5 10
> [0] g a: 5 10
> [0] g a: 5 10
> [0] g a: 5 10
> [0] redistribute 11 a 80 90
> [0] g a: 5 10
> [0] g a: 5 10
> Segmentation fault
>
>
> GDB tells me that fails in a constructor, probably running out of memory:
>
> #0  0x08112a71 in TableEntry (this=0xb7ffff54, ignored=0) at init.h:21
> #1  0x08122dcd in GroupIdxArray<TableEntry>::nonInlineFind (this=0x82b9070,
> n=...) at init.h:58
> #2  0x0812242d in GroupIdxArray<TableEntry>::find (this=0x82b9070, n=...) at
> init.h:95
> #3  0x08117aa9 in _localBranch (gID=...) at init.h:151
> #4  0x0811a84a in CkLocalBranch (gID=...) at ck.C:505
> #5  0x08101dd1 in CkArrayID::CkLocalBranch (id=...) at
> ../../../../bin/../include/charm++.h:217
>
> I tried to find the reason for this, but couldn't. I can only guess that the
> message header was corrupted somehow.Thanks for having a look.
>
> Pritish
>
>
> On Thu, Mar 29, 2012 at 6:31 PM, Gengbin Zheng 
> <gzheng AT illinois.edu>
>  wrote:
>>
>> I am not sure about this. There is a field in envelope for the packing
>> and unpacking states. The message should be pack/unpacked when needed
>> by checking the flag.
>> I don't see the following explains.
>> Do you have a small test program that can show the bug?
>>
>> Gengbin
>>
>>
>> On Thu, Mar 29, 2012 at 1:24 PM, Venkataraman, Ramprasad
>> <ramv AT illinois.edu>
>>  wrote:
>> > I just spoke to Pritish about this, but am also replying just to
>> > archive the findings.
>> >
>> > CkMulticast cannot support packed messages the way you describe the
>> > usage below. This is because the multicast manager actually needs the
>> > information present in the CkMcastBaseMsg at each intermediate point
>> > along the tree while transmitting a multicast. Since it has no way of
>> > distinguishing packed messages, it cannot unpack (pup) it to retrieve
>> > this metadata.
>> >
>> > Hence instead of packing (pupping) a CkMcastBaseMsg* directly, a
>> > solution that works currently will be to size the PUP::able data,
>> > allocate a varsize msg that inherits from CkMcastBaseMsg and has
>> > enough space for the above data and then PUP the data into the msg.
>> > This will allow CkMulticast to transmit a PUP::able type without
>> > issues. All this machinery could be encapsulated behind a factory
>> > method that created the message given a PUP::able.
>> >
>> > Of course, this issue can be avoided if we supported efficient
>> > parameter-marshalled multicasts. This is a feature currently under
>> > development.
>> >
>> > Ram
>> >
>> > On Wed, Mar 28, 2012 at 15:07, Pritish Jetley 
>> > <pjetley2 AT illinois.edu>
>> > wrote:
>> >> Hi all,
>> >>
>> >> I have a question about using packed messages with CkMulticast. I have
>> >> a
>> >> user-defined, packed message type, MapMsg, which has integer members,
>> >> as
>> >> well as a pointer to a PUPable class:
>> >>
>> >> struct MapMsg : public CkMcastBaseMsg, public CMessage_MapMsg {
>> >>   int x,y;
>> >>   MyPupableClass *ptr;
>> >>
>> >>   static void *pack(MapMsg *in);
>> >>   static MapMsg *unpack(void *buf);
>> >>   void pup(PUP::er &p);
>> >> }
>> >>
>> >> When I send out a MapMsg, I would like the PUPable object to which
>> >> 'ptr'
>> >> points, to be packed into it. Therefore, I have defined the pack() and
>> >> unpack() methods for the MapMsg class:
>> >>
>> >> void *MapMsg::pack(MapMsg *inm){
>> >>   PUP::sizer psz;
>> >>   inm->pup(psz);
>> >>
>> >>   void *buf = (void *)CkAllocBuffer(inm,psz.size());
>> >>   PUP::toMem pmem(buf);
>> >>   inm->pup(pmem);
>> >>
>> >>   delete inm;
>> >>   return buf;
>> >> }
>> >>
>> >> MapMsg *MapMsg::unpack(void *inbuf){
>> >>   MapMsg *m = (MapMsg *)CkAllocBuffer(inbuf,sizeof(MapMsg));
>> >>   m->a = NULL;
>> >>   PUP::fromMem pmem(inbuf);
>> >>   m->pup(pmem);
>> >>
>> >>   CkFreeMsg(inbuf);
>> >>   return m;
>> >> }
>> >>
>> >> That is, I call pup() on the message to size and pack/unpack its
>> >> contents.
>> >> The pup() method for MapMsg is as follows:
>> >>
>> >>   void MapMsg::pup(PUP::er &p){
>> >>     CkMcastBaseMsg::pup(p);
>> >>     CMessage_MapMsg::pup(p);
>> >>     p|x;
>> >>     p|y;
>> >>     p|ptr;
>> >>   }
>> >>
>> >> I defined CkMcastBaseMsg::pup() myself, to pup the values of the
>> >> CkMulticast
>> >> cookie, magic number and ep index:
>> >>
>> >> void CkMcastBaseMsg::pup(PUP::er &p){
>> >>   p|_cookie;
>> >>   p|magic;
>> >>   p|ep;
>> >> }
>> >>
>> >> However, the code segfaults when the message is being sent, which leads
>> >> me
>> >> to believe that I'm forgetting to pack something. Can anyone see
>> >> something
>> >> that is wrong with the code above?
>> >>
>> >> Thanks,
>> >> Pritish
>> >>
>> >> --
>> >> Pritish Jetley
>> >> Doctoral Candidate, Computer Science
>> >> University of Illinois at Urbana-Champaign
>> >>
>> >> _______________________________________________
>> >> charm mailing list
>> >> charm AT cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/charm
>> >>
>> >> _______________________________________________
>> >> ppl mailing list
>> >> ppl AT cs.uiuc.edu
>> >> http://lists.cs.uiuc.edu/mailman/listinfo/ppl
>> >>
>> >
>> >
>> >
>> > --
>> > Ramprasad Venkataraman
>> > Parallel Programming Lab
>> > Univ. of Illinois
>> >
>> > _______________________________________________
>> > charm mailing list
>> > charm AT cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/charm
>> >
>> > _______________________________________________
>> > ppl mailing list
>> > ppl AT cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/ppl
>
>
>
>
> --
> Pritish Jetley
> Doctoral Candidate, Computer Science
> University of Illinois at Urbana-Champaign