Infinite invocations of singleton chare constructors

[epmikida]

If a singleton chare contains a constructor, where the only argument to that constructor is a proxy to the same type of singleton chare, it may get end up getting called infinitely.

The following program should be able to reproduce the bug every time. As long as the constructor with the single proxy argument is included, and at least one constructor taking a proxy is called, the bug will occur. If the single proxy constructor is removed, then the other constructor can be called just fine and will behave as expected.

test.zip

[epmikida]

Another way to reproduce is to add entry Fib(CProxy_Fib f) and Fib(CProxy_Fib f) { CkPrintf("Error\n"); } to fib.ci and fib.C in the fibonacci example in the repository.

[jszaday]

Still working on debugging this but wanted to quickly share that, interestingly, this is actually generating new messages for each new invocation.

[jszaday]

This recurrence is due to a Charmxi code-gen'd method overriding the copy constructor of the CProxy_[...] class.

For an as-yet-unknown reason, a call to a singleton chare's CProxy_[...]::CProxy_[...](args) actually creates a new chare when the args matches one of the chare's constructors. In my opinion, this behavior is problematic. For maximum clarity, chare creation should only occur through ckNew (or insert, create[here|home], etc.).

In the below, the recurrence occurs at (5), which is defined as CProxy_Fib::CProxy_Fib(const CProxy_Fib &parent, int impl_onPE, const CkEntryOptions *impl_e_opts) (with default args). This function is essentially equivalent to ckNew; it goes out and calls CkCreateChare.

#0  CmiAlloc (size=size@entry=112) at /home/szaday2/workspace/charm/src/conv-core/convcore.C:3207
#1  0x00005555556f6585 in envelope::alloc (incEvent=true, groupDepNumRequest=..., prio=0, size=<optimized out>, type=4 '\004') at /home/szaday2/workspace/charm/src/ck-core/envelope.h:308
#2  _allocEnv (groupDepNum=..., prio=0, size=<optimized out>, msgtype=4) at /home/szaday2/workspace/charm/src/ck-core/envelope.h:478
#3  CkAllocMsg (msgIdx=7, msgBytes=<optimized out>, prioBits=0, groupDepNum=...) at /home/szaday2/workspace/charm/src/ck-core/msgalloc.C:37
#4  0x00005555556351fe in CkAllocateMarshallMsg (size=16, opts=0x0) at /home/szaday2/workspace/charm/include/ckmarshall.h:17
#5  0x0000555555631ee0 in CProxy_Fib::CProxy_Fib (this=0x5555558fd3d0, parent=..., impl_onPE=-1, impl_e_opts=0x0) at fib.def.h:327
#6  0x0000555555635c73 in Fib::Fib (this=0x5555558fd380, parent_=..., __in_chrg=<optimized out>, __vtt_parm=<optimized out>) at fib.C:19
#7  0x00005555556320e6 in CkIndex_Fib::_call_Fib_marshall2 (impl_msg=0x5555558fd570, impl_obj_void=0x5555558fd380) at fib.def.h:360
#8  0x0000555555645d93 in CkDeliverMessageFree (epIdx=147, msg=0x5555558fd570, obj=<optimized out>) at /home/szaday2/workspace/charm/netlrts-linux-x86_64-gcc/include/cklists.h:225
#9  0x0000555555645e88 in _invokeEntryNoTrace (epIdx=147, env=0x5555558fd520, obj=0x5555558fd380) at /home/szaday2/workspace/charm/src/ck-core/ck.C:598
#10 0x000055555564bf1c in _invokeEntry (obj=0x5555558fd380, env=<optimized out>, epIdx=<optimized out>) at /home/szaday2/workspace/charm/src/ck-core/ck.C:616
#11 _processNewVChareMsg (env=<optimized out>, ck=<optimized out>) at /home/szaday2/workspace/charm/src/ck-core/ck.C:945
#12 _processHandler (converseMsg=<optimized out>, ck=<optimized out>) at /home/szaday2/workspace/charm/src/ck-core/ck.C:1282
#13 0x000055555577ad0e in CmiHandleMessage (msg=<optimized out>) at /home/szaday2/workspace/charm/src/conv-core/convcore.C:1696
#14 CsdScheduleForever () at /home/szaday2/workspace/charm/src/conv-core/convcore.C:1943
#15 0x000055555577b2c5 in CsdScheduler (maxmsgs=maxmsgs@entry=-1) at /home/szaday2/workspace/charm/src/conv-core/convcore.C:1882
#16 0x00005555557b0152 in ConverseRunPE (everReturn=0) at /home/szaday2/workspace/charm/src/arch/util/machine-common-core.C:1609
#17 ConverseInit (argc=<optimized out>, argv=<optimized out>, fn=fn@entry=0x5555556f1be0 <_initCharm(int, char**)>, usched=usched@entry=0, initret=initret@entry=0) at /home/szaday2/workspace/charm/src/arch/util/machine-common-core.C:1524
#18 0x00005555556f157d in charm_main (argc=<optimized out>, argv=<optimized out>) at /home/szaday2/workspace/charm/src/ck-core/init.C:1739
#19 0x00007ffff78850b3 in __libc_start_main (main=0x5555556300e0 <main(int, char**)>, argc=2, argv=0x7fffffffd7c8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd7b8) at ../csu/libc-start.c:308
#20 0x0000555555630bee in _start () at /home/szaday2/workspace/charm/src/ck-core/ck.C:32

NOTE: This can be confirmed by avoiding copying CProxy_[...]. If you do not copy a CProxy_[...] (at any point) in your code, you will not observe this infinite creation cycle.