Probably should have injected my earlier thoughts here. IMO, Brian is correct -
we do have a basic design problem, and it does need to be corrected.
It's a bigger discussion than just this commit, though, and we probably should
add it to the Tues telecon so we at least get some initial ideas on
On Aug 8, 2011, at 1:23 PM, Thomas Herault wrote:
> proc_get_epoch( proc );
> calls ORTE_NAME_PRINT(proc)
> when in debug mode.
>
> When this is the case, ORTE_NAME_PRINT prints all fields of proc, including
> epoch. So, proc->epoch = proc_get_epoch(proc) triggers the valgrind warning,
> becau
I will interject at this point in the thread. IMO, Brian has raised a valid
point. We are contorting around with the epoch values, as I commented in a
separate thread.
The problem really stems from something Wes mentioned a while back in a
different set of communications. When the epoch code wa
I see no problem with the latest code from Wesley. The warning is silenced, and
was not indicative of any buggy behavior. So for me the problem is closed.
Aurelien
Le 8 août 2011 à 15:30, Barrett, Brian W a écrit :
> 4) Don't design an interface where you're going to have the circular
> depe
4) Don't design an interface where you're going to have the circular
dependency. Perhaps it's a sign that the epoch is in the wrong place, or
handled in the wrong way, or the whole naming scheme is wrong. I'm not
sure. I've relented that it doesn't need to be fixed now (since it is
clearly bigge
proc_get_epoch( proc );
calls ORTE_NAME_PRINT(proc)
when in debug mode.
When this is the case, ORTE_NAME_PRINT prints all fields of proc, including
epoch. So, proc->epoch = proc_get_epoch(proc) triggers the valgrind warning,
because of the print, in debug mode.
This is the only reason why proc->
Ok, that makes some sense. It's a really weird way of doing
initialization, though. Some of it is probably how Ralph chose to share
nidpid map code, so perhaps it's unavoidable. But since the name isn't
use in proc_get_epoch() (or, better not be used in there), I'm not
entirely sure why that mad
It's not just copying the value from one to the other.
The value is initialized on the first line. The proc_name is passed into the
function where the jobid and vpid are used (not the epoch). The function
returns a new (the correct) value for the epoch based on the passed in jobid
and vpid which i
On 8/8/11 9:34 AM, "Jeff Squyres" wrote:
>On Aug 8, 2011, at 11:30 AM, Wesley Bland wrote:
>
>> The reason is because valgrind was complaining about uninitialized
>>values that were passed into proc_get_epoch. I saw the same warnings
>>from valgrind when I ran it. I added the code to initialize t
On Aug 8, 2011, at 11:30 AM, Wesley Bland wrote:
> The reason is because valgrind was complaining about uninitialized values
> that were passed into proc_get_epoch. I saw the same warnings from valgrind
> when I ran it. I added the code to initialize the values to what really
> should be the de
The reason is because valgrind was complaining about uninitialized values
that were passed into proc_get_epoch. I saw the same warnings from valgrind
when I ran it. I added the code to initialize the values to what really
should be the default value and the warnings went away. Since the
process_nam
FYI: Ralph's out today. He'll be back tomorrow.
I'm not really part of this ORTE discussion, but I am curious about a code
style that I see in this commit: assigning ORTE_EPOCH_INVALID to a field, and
then immediately overwriting that field with another value. E.g.:
> peer_name.jobid = O
12 matches
Mail list logo
