Charm++ parallel programming system

[Phil Miller <mille121 AT illinois.edu>]

Could you please post the full stack trace? The error likely lies
further up the stack than the functions you named.

On Tue, Feb 17, 2015 at 8:31 PM, Hrushit Parikh
<parikhhrushit AT hotmail.com>
 wrote:
> Hi,
> Thank you, upgrading to charm-6.6.1 worked. I am able to link the UTS code
> with projections and generate analysis data.
>
> However, when I tried to run UTS with -tracemode projections and my modified
> cldb.workstealing.c "seed balancer" I run into a segmentation fault. I have
> been trying to do a stack backtrace analysis and debug it since couple of
> days. Here is what I have:
>
> The CopyMsg function in machine-common-core.c throws an error (address out
> of bounds) while doing a memcpy:
>
> ************************************************
> /* Utiltiy functions */
> static char *CopyMsg(char *msg, int len) {
>     char *copy = (char *)CmiAlloc(len);
> #if CMK_ERROR_CHECKING
>     if (!copy) {
>         CmiAbort("Error: out of memory in machine layer\n");
>     }
> #endif
>     memcpy(copy, msg, len);
>     return copy;
> }
>
> The values of copy, msg and len are:
>
> copy: 0x2aaac0ce0020""
> len: 50331728
> msg: 0xe25940""
>
> *************************************************
>
> Seeing the length it is most likely that we are trying to ask for too big a
> chunk of memory. I tracked back the  char *msg in the above code to envelope
> *env in function CkCreateGroup(...) in file ck.C
>
> What parameters is env storing that it has a length of 50331728 ? What data
> from the converse run time system, especially the seed balancer does it take
> which could be causing this error, because my changes are primarily in the
> workstealing seed balancer.
>
> Thank you in advance.
>
> PS: My seed balancer works fine if I do not link projections to the UTS
> code.
>
>> From: 
>> mille121 AT illinois.edu
>> Date: Sun, 15 Feb 2015 19:52:36 -0600
>> Subject: Re: [charm] Unable to run UTS with projections
>> To: 
>> parikhhrushit AT hotmail.com
>> CC: 
>> charm AT cs.uiuc.edu
>>
>> Hi Hrushit,
>>
>> The first recommendation I would give is to use the current stable
>> release of Charm++, 6.6.1:
>> http://charm.cs.illinois.edu/distrib/charm-6.6.1.tar.gz
>>
>> Numerous bug-fixes and improvements have been made since version 6.5.1
>> came out, and it's often unproductive to try to diagnose an error
>> that's already been fixed.
>>
>> Thanks,
>>
>> Phil Miller
>>
>> On Sun, Feb 15, 2015 at 7:18 PM, Hrushit Parikh
>> <parikhhrushit AT hotmail.com>
>>  wrote:
>> > Hi,
>> > I am trying to get projections analysis on the UTS benchmark (Tree T1L)
>> > in
>> > charm++ using the "-tracemode projections" option. I use the
>> > workstealing
>> > seed balancer.
>> >
>> > I am using charm-6.5.1 version on the UT Austin Stampede cluster. The
>> > stampede cluster uses ibrun to launch the executable. I have compiled
>> > charm
>> > using ./build charm++ mpi-linux-x86_64 mpicxx -j16.
>> >
>> > With 256 Processors, the T1L run takes only 0.3 seconds when I compile
>> > charm
>> > with the "--with-production" option (to disable traces). However, with
>> > traces enabled the execution time exceeds 15 minutes and I have to kill
>> > the
>> > program.
>> >
>> > I tried running NQueens with the same workstealing balancer on 256
>> > Processors with traces enabled. For queens upto 19 (grainsize=3) it runs
>> > fine and projections data is generated, but with 20 queens it takes
>> > forever.
>> >
>> > Any ideas why UTS takes forever with traces enabled or am I missing
>> > something?
>> >
>> > Thank you,
>> > Hrushit
>> >
>> > _______________________________________________
>> > charm mailing list
>> > charm AT cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/charm
>> >
>
> _______________________________________________
> charm mailing list
> charm AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/charm
>