Charm++ parallel programming system

[Gengbin Zheng <zhenggb AT gmail.com>]

I wrote a simple test program passing either thishandle, or CProxy, it
seems to work both ways.
I think it would be best if you can write a simple standalone program
that can reproduce your problem and send to us for investigation.

Gengbin

On Thu, May 27, 2010 at 8:51 AM, Christian Perez
<christian.perez AT inria.fr>
 wrote:
> 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
>>>
>>>
>
>