Charm++ parallel programming system

[Christian Perez <christian.perez AT inria.fr>]

But, why does it work if I use the parameter 'psi'?

If I remove the 'sync', there is a synchronization issue :(

Christian

On 05/26/2010 09:54 PM, Gengbin Zheng wrote:
> remove [sync] from your ci file. Calling sync will block the caller,
> which in your case is not a threaded entry method.
>
> Gengbin
>
> On Wed, May 26, 2010 at 10:29 AM, Christian Perez
> <christian.perez AT inria.fr>
>   wrote:
>    
> > On 05/26/2010 05:00 PM, Gengbin Zheng wrote:
> >      
> > > On Wed, May 26, 2010 at 6:37 AM, Christian Perez
> > > <christian.perez AT inria.fr>
> > >     wrote:
> > >
> > >        
> > > > On 05/25/2010 07:22 PM, Gengbin Zheng wrote:
> > > >
> > > >          
> > > > > Is the caller of connect() a thread (I mean is connect() a threaded
> > > > > entry function)?
> > > > >
> > > > >
> > > > >            
> > > > It is not a threaded charm method: when I tried to turn it into a
> > > > [threaded]
> > > > entry
> > > > method it I've got an error when invoking JNI method from this chare. I
> > > > shall investigate it later.
> > > >
> > > >          
> > > > > another way of doing this without using thread is to send component_B
> > > > > proxy to component_A, and let component_A directly send its proxy to
> > > > > component_B.
> > > > >
> > > > >
> > > > >            
> > > > That is the alternative solution: the good news is that it works(*),
> > > > the not-so-good news is that it make the mapping between components
> > > > and charm objects a litte more complex.
> > > >
> > > > (*) I need to use a hack that seems weird to me:
> > > >
> > > > Chare component_A : SimpleInterface {
> > > >   void set_s(CProxy_SetSimpleInterface&    pssi, CProxy_SimpleInterface&
> > > >   psi) {
> > > >      pssi.set_si(psi);
> > > >   }
> > > >
> > > > works while the following version does not work (psi is changed to
> > > > thishandle)
> > > >
> > > >
> > > > Chare component_A : SimpleInterface {
> > > >   void set_s(CProxy_SetSimpleInterface&    pssi, CProxy_SimpleInterface&
> > > >   psi) {
> > > >      pssi.set_si(thishandle);
> > > >   }
> > > >
> > > > psi is obtained from a call to CProxy_component_A::ckNew.
> > > >
> > > > Question: how can I create a Proxy from within a chare?
> > > >
> > > > I tried
> > > >
> > > >      pssi.set_si(CProxy_SimpleInterface(thishandle));
> > > >
> > > > but it fails with the same error :
> > > >
> > > > [0] Assertion "n<len" failed in file cklists.h line 221.
> > > > ------------- Processor 0 Exiting: Called CmiAbort ------------
> > > > Reason:
> > > > [0] Stack Traceback:
> > > >   [0:0] CmiAbort+0x89  [0x506ff2]
> > > >   [0:1] __cmi_assert+0x4b  [0x514a0c]
> > > >   [0:2] _ZN5CkVecIPvEixEm+0x36  [0x49c7a8]
> > > >   [0:3] /opt/usr/stow/ULCMi/libexec/Charm-launcher [0x4966f9]
> > > >   [0:4] _Z15_processHandlerPvP11CkCoreState+0x30d  [0x49712e]
> > > >   [0:5] CmiHandleMessage+0x84  [0x50f5f1]
> > > >   [0:6] CsdSchedulePoll+0x96  [0x50fb5f]
> > > >   [0:7] CsdScheduler+0x23  [0x50f8bf]
> > > >   [0:8] CthStandinCode+0xe  [0x50fc5a]
> > > >   [0:9] CthStartThread+0x59  [0x4830b7]
> > > >   [0:10] /lib/libc.so.6 [0x7f98d9aaf370]
> > > > Fatal error on PE 0>
> > > >
> > > > Thanks for your help!
> > > >
> > > >
> > > >          
> > > It is hard to eyeball errors from segmented code.
> > > What is in set_si?
> > >
> > >        
> > I produce this bug with this piece of code, with only one process.
> >
> > ci file:
> >     chare SingleProvider : SimpleInterface {
> >         ...
> >         entry [sync] void provider_set_s(CProxy_SetSimpleInterface&  pssi,
> > CProxy_SimpleInterface&  psi, int n, char name[n]);
> >         ...
> >     }
> >
> > C file:
> >
> >     class SingleProvider : virtual public CBase_SingleProvider {
> >         ...
> >
> >      void provider_set_s(CProxy_SetSimpleInterface&  pssi,
> > CProxy_SimpleInterface&  psi, int n, char* name) {
> >          pssi.ulcmi_set_si(CProxy_SimpleInterface(thishandle), n, name);
> >   }
> >
> >
> > It also fails if I use thishandle instead of
> > CProxy_SimpleInterface(thishandle).
> > It works fine if I use pssi (which as been with ckNew of
> > CProxy_SingleProvider).
> >
> > | Can you build your program with -g, when it crashes again, get stack trace
> > like:
> >
> > Here the output within gdb:
> >
> > [0] Assertion "n<len" failed in file cklists.h line 221.
> > ------------- Processor 0 Exiting: Called CmiAbort ------------
> > Reason:
> > [0] Stack Traceback:
> >   [0:0] CmiAbort+0x89  [0x506f02]
> >   [0:1] __cmi_assert+0x4b  [0x51491c]
> >   [0:2] _ZN5CkVecIPvEixEm+0x36  [0x49c6b8]
> >   [0:3] /opt/usr/stow/ULCMi/libexec/Charm-launcher [0x496609]
> >   [0:4] _Z15_processHandlerPvP11CkCoreState+0x30d  [0x49703e]
> >   [0:5] CmiHandleMessage+0x84  [0x50f501]
> >   [0:6] CsdSchedulePoll+0x96  [0x50fa6f]
> >   [0:7] CsdScheduler+0x23  [0x50f7cf]
> >   [0:8] CthStandinCode+0xe  [0x50fb6a]
> >   [0:9] CthStartThread+0x59  [0x482fc7]
> >   [0:10] /lib/libc.so.6 [0x7ffff5729370]
> > CHARM++ FATAL ERROR:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x0000000000506f31 in CmiAbort (message=0x53d785 "") at machine.c:612
> > 612         *(int *)NULL = 0; /*Write to null, causing bus error*/
> > (gdb) bt
> > #0  0x0000000000506f31 in CmiAbort (message=0x53d785 "") at machine.c:612
> > #1  0x000000000051491c in __cmi_assert (expr=0x534e87 "n<len",
> >     file=0x534e7d "cklists.h", line=221) at convcore.c:3399
> > #2  0x000000000049c6b8 in CkVec<void*>::operator[] (this=0x7ffff0067aa0,
> >     n=140737226103192) at cklists.h:221
> > #3  0x0000000000496609 in _processForPlainChareMsg (ck=0x7ffff006c640,
> >     env=0x7ffff007e3e8) at ck.C:844
> > #4  0x000000000049703e in _processHandler (converseMsg=0x7ffff007e3e8,
> >     ck=0x7ffff006c640) at ck.C:1117
> > #5  0x000000000050f501 in CmiHandleMessage (msg=0x7ffff007e3e8)
> >     at convcore.c:1393
> > #6  0x000000000050fa6f in CsdSchedulePoll () at convcore.c:1610
> > #7  0x000000000050f7cf in CsdScheduler (maxmsgs=0) at convcore.c:1491
> > #8  0x000000000050fb6a in CthStandinCode () at convcore.c:1674
> > #9  0x0000000000482fc7 in CthStartThread (fn1=0, fn2=5307228, arg1=0,
> > arg2=0)
> >     at threads.c:1579
> > #10 0x00007ffff5729370 in ?? () from /lib/libc.so.6
> > #11 0x0000000000000000 in ?? ()
> >
> >
> >      
> > > addr2line -e ./your_binay   0x4966f9
> > >
> > >        
> >      
> > > Can you send me the output of that for lines:
> > >
> > >   [0:2] _ZN5CkVecIPvEixEm+0x36  [0x49c7a8]
> > >   [0:3] /opt/usr/stow/ULCMi/libexec/Charm-launcher [0x4966f9]
> > >
> > >        
> > addr2line -e /opt/usr/stow/ULCMi/libexec/Charm-launcher 0x49c6b8
> > /home/cperez/Research/charm-6.2.0/net-linux-x86_64-smp/tmp/cklists.h:222
> >
> > addr2line -e /opt/usr/stow/ULCMi/libexec/Charm-launcher  0x496609
> > /home/cperez/Research/charm-6.2.0/net-linux-x86_64-smp/tmp/ck.C:844
> >
> >      
> > > btw, did you ever run megatest (in charm/tests/charm++/megatest)
> > > successfully? Just wanted to make sure charm threaded entry method
> > > indeed works on your system.
> > >
> > >
> > >        
> > I run it up to "++p 16" and it works fine.
> > My system is a linux box (Intel(R) Core(TM)2 Duo CPU) running
> > debian/unstable (gcc (Debian 4.4.4-2) 4.4.4).
> >
> > Thank you
> >
> > Christian
> >
> >