Yes - but Marco said he was going to look into it. I meant that I would fix
the problem George identified, although it doesn't fix the problem Marco
hit.
Sorry for the confusion
On Wed, Mar 5, 2014 at 2:48 PM, Paul Hargrove <phhargr...@lbl.gov> wrote:
> Wait a second...
>
> Unless I am missing something Marco's error means that Cygwin *did* return
> INADDR_ANY.
> According to George's research that shouldn't happen (unless on XP or
> older and host is an empty string).
>
> So, changing the code to check for INADDR_NONE just ignores what should be
> an impossible return, right?
> I agree that the change makes the code check for what it was meant to
> check for, but doesn't Marco's result *still* point at a problem with host
> resolution under Cygwin?
>
> -Paul
>
>
> On Wed, Mar 5, 2014 at 2:35 PM, Ralph Castain <r...@open-mpi.org> wrote:
>
>> Cool - I'll make the correction. Thx!
>>
>>
>>
>> On Wed, Mar 5, 2014 at 2:08 PM, George Bosilca <bosi...@icl.utk.edu>wrote:
>>
>>> I'm afraid the snippet pointed by Ralph is incorrect, as INADDR_ANY
>>> should not be a valid return for inet_addr. Here is a quick check on
>>> different OSes.
>>>
>>> On Linux, the man Page states:
>>>
>>> If the input is invalid, INADDR_NONE (usually -1) is returned.
>>>
>>>
>>> On Mac OS X:
>>>
>>> The constant INADDR_NONE is returned by inet_addr() and inet_network()
>>> for malformed requests.
>>>
>>>
>>> On Windows things are slightly more complicated:
>>>
>>> On Windows Server 2003 and later if the string in the cp parameter is an
>>> empty string, then inet_addr returns the value INADDR_NONE. If NULL is
>>> passed in the cp parameter, then inet_addrreturns the value INADDR_NONE.
>>> On Windows XP and earlier if the string in the cp parameter is an empty
>>> string, then inet_addr returns the value INADDR_ANY. If NULL is passed in
>>> the cp parameter, then inet_addr returns the value INADDR_NONE.
>>>
>>>
>>> Thus, we should compare with INADDR_NONE and not with INADDR_ANY.
>>>
>>> George.
>>>
>>> On Mar 4, 2014, at 22:06 , Ralph Castain <r...@open-mpi.org> wrote:
>>>
>>> The code generating the error is here:
>>>
>>> in->sin_addr.s_addr = inet_addr(host);
>>> if (in->sin_addr.s_addr == INADDR_ANY) {
>>> return ORTE_ERR_BAD_PARAM;
>>> }
>>>
>>>
>>> The address is resolving to INADDR_ANY instead of a regular address.
>>> Does cygwin require some other method for resolving a hostname to an IP
>>> address?
>>>
>>> Ralph
>>>
>>>
>>>
>>> On Tue, Mar 4, 2014 at 3:19 PM, Marco Atzeri <marco.atz...@gmail.com>wrote:
>>>
>>>> noted on cygwin with 1.7.4 and on 1.7.5rc1
>>>>
>>>> $ mpirun -n 4 ./hello_c.exe
>>>> [MATZERI:06212] [[62628,1],0] ORTE_ERROR_LOG: Bad parameter in file
>>>> /pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/orte/mca/oob/tcp/oob_tcp.c
>>>> at line 292
>>>> [MATZERI:05620] [[62628,1],1] ORTE_ERROR_LOG: Bad parameter in file
>>>> /pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/orte/mca/oob/tcp/oob_tcp.c
>>>> at line 292
>>>> [MATZERI:06892] [[62628,1],2] ORTE_ERROR_LOG: Bad parameter in file
>>>> /pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/orte/mca/oob/tcp/oob_tcp.c
>>>> at line 292
>>>> [MATZERI:03908] [[62628,1],3] ORTE_ERROR_LOG: Bad parameter in file
>>>> /pub/devel/openmpi/openmpi-1.7.5rc1-1/src/openmpi-1.7.5rc1/orte/mca/oob/tcp/oob_tcp.c
>>>> at line 292
>>>> Hello, world, I am 1 of 4, (Open MPI v1.7.5rc1, package: Open MPI
>>>> marco@MATZERI Distribution, ident: 1.7.5rc1, Mar 01, 2014, 102)
>>>> Hello, world, I am 2 of 4, (Open MPI v1.7.5rc1, package: Open MPI
>>>> marco@MATZERI Distribution, ident: 1.7.5rc1, Mar 01, 2014, 102)
>>>> Hello, world, I am 3 of 4, (Open MPI v1.7.5rc1, package: Open MPI
>>>> marco@MATZERI Distribution, ident: 1.7.5rc1, Mar 01, 2014, 102)
>>>> Hello, world, I am 0 of 4, (Open MPI v1.7.5rc1, package: Open MPI
>>>> marco@MATZERI Distribution, ident: 1.7.5rc1, Mar 01, 2014, 102)
>>>>
>>>> any idea what could be the cause ?
>>>>
>>>> I don't remember it in previous 1.7.x releases
>>>>
>>>> the relevant code is:
>>>>
>>>> if ((rc = parse_uri(pop->af_family, pop->net, pop->port, (struct
>>>> sockaddr*) &inaddr)) != ORTE_SUCCESS) {
>>>> ORTE_ERROR_LOG(rc);
>>>>
>>>> Regards
>>>> Marco
>>>> _______________________________________________
>>>> devel mailing list
>>>> de...@open-mpi.org
>>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>>> Searchable archives: http://www.open-mpi.org/
>>>> community/lists/devel/2014/03/index.php
>>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> de...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Searchable archives:
>>> http://www.open-mpi.org/community/lists/devel/2014/03/index.php
>>>
>>>
>>>
>>> _______________________________________________
>>> devel mailing list
>>> de...@open-mpi.org
>>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>>> Link to this post:
>>> http://www.open-mpi.org/community/lists/devel/2014/03/14301.php
>>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> de...@open-mpi.org
>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
>> Link to this post:
>> http://www.open-mpi.org/community/lists/devel/2014/03/14302.php
>>
>
>
>
> --
> Paul H. Hargrove phhargr...@lbl.gov
> Future Technologies Group
> Computer and Data Sciences Department Tel: +1-510-495-2352
> Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
>
> _______________________________________________
> devel mailing list
> de...@open-mpi.org
> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel
> Link to this post:
> http://www.open-mpi.org/community/lists/devel/2014/03/14303.php
>
