socket woes

[Steve And Grace Bovy]

From: hercules-390@... [mailto:hercules-390@...] On
Behalf Of Ivan Warren
Sent: Sunday, June 28, 2009 4:23 AM
To: hercules-390@...
Subject: Re: [hercules-390] Re: socket woes





kerravon86 wrote:
> Warren, the error is on that connect above.
>
Ok.. (btw, Warren is my last name.. Call me Ivan.. please :) )
>
>> /usr/include/w32api/winerror.h:#define WSAEADDRNOTAVAIL 10049L
>>
>
> As per documentation:
>
> http://msdn.microsoft.com/en-us/library/ms737625
<http://msdn.microsoft.com/en-us/library/ms737625> (VS.85).aspx
>
> If the address member of the structure specified by the name parameter is
all zeroes, connect will return the error WSAEADDRNOTAVAIL.
>
>
> The reason it's zero, as per previous email, is
> the getsockname() function appears to be allowed
> to wipe out the address.
>
>
getsockname is suppose to fill the structure with the complete address
(IP address and port number) to which the socket is actually bound.

After the bind on 127.0.0.1 Port 0, the Ip address should still be
127.0.0.1 and the Port number should be one of the automatically usable
ports.


See these notes about BIND from MSDN  
 
Here is a note from BIND   >>
 
For TCP/IP, if the port is specified as zero, the service provider assigns a
unique port to the application with a value between 1024 and 5000. The
application can use
<blocked::http://msdn.microsoft.com/en-us/library/ms738543(VS.85).aspx>
getsockname after calling bind to learn the address and the port that has
been assigned to it. If the Internet address is equal to INADDR_ANY,
getsockname cannot necessarily supply the address until the socket is
connected, since several addresses can be valid if the host is multihomed.
Binding to a specific port number other than port 0 is discouraged for
client applications, since there is a danger of conflicting with another
socket already using that port number.
 


And WSAEADDRNOTAVAIL will be returned for other reasons than the whole
structure being zeroes !..

Could you do something like this when the error occurs ? :

unsigned char *lptr;
int i;

lptr=&localhost_addr;
for(i=0;i<len;i++)
{
if(i%16==0) {
if(i) printf("\n");
printf("%4.4X : ",i);
}
if(i%4==0) printf(" ");
printf("%2.2X",lptr[i]);
}
if(i%16) printf("\n");

--Ivan

[Non-text portions of this message have been removed]








[Non-text portions of this message have been removed]

[kerravon86]

--- In hercules-390@..., "Steve And Grace Bovy" <sg.bovy@...> wrote:
>
>> The fix has been marked as a workaround since we
>> haven't yet been able
>> to determine the actual root cause of the issue.
>
> Well, I think it is not a work-around (the root
> cause is ver clearly
> indicated by Pauls great debug efforts !!

Thanks, but I don't consider that to be "clear".
I consider that to be "quibbling". :-)

> Here is a note from BIND   >>
>  
> For TCP/IP, if the port is specified as zero, the service
> provider assigns a
> unique port to the application with a value between 1024 and 5000.

Right, that much is working.

> The
> application can use
> <http://msdn.microsoft.com/en-us/library/ms738543(VS.85).aspx>
> getsockname after calling bind to learn the address and the
> port that has been assigned to it.

An address was assigned? We provided the address!

> If the Internet address is equal to INADDR_ANY, getsockname

But it isn't! It's INADDR_LOOPBACK!

> cannot necessarily supply the address until the socket is
> connected, since several
> addresses can be valid if the host is multihomed.

It's certainly very unusual in computing to have
something returning random results between
invocations.

And then - what happens on other people's computers
when they ran that small test program?

BFN.  Paul.

[kerravon86]

--- In hercules-390@..., "kerravon86" <kerravon86@...> wrote:
>
> Thanks, but I don't consider that to be "clear".
> I consider that to be "quibbling". :-)

"ambiguous" perhaps.

> And then - what happens on other people's computers
> when they ran that small test program?

Here's a better one to run:

C:\devel\develop>gcc -o sockbug sockbug.c

C:\devel\develop>sockbug
attempt number 1
get rc 0, len 16, listening on 127.0.0.1:60353
attempt number 2
get rc 0, len 16, listening on 127.0.0.1:60354
attempt number 3
get rc 0, len 16, listening on 127.0.0.1:60355
attempt number 4
get rc 0, len 16, listening on 0.0.0.0:60356
address has changed!


#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <string.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int foo()
{
     int sock, len, rc;
     struct sockaddr_in addr, xxx;

     len = sizeof xxx;
     if((sock=socket(AF_INET, SOCK_STREAM, 0))<0)
     {
         exit(0);
     }

     memset(&addr, 0, sizeof(struct sockaddr_in));
     addr.sin_family = AF_INET;
     addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
     addr.sin_port = htons(0);

     if(bind(sock, (struct sockaddr *) &addr,
             sizeof(struct sockaddr_in))<0)
     {
         perror("bind");
         exit(0);
     }

     if(listen(sock, 5)<0)
     {
         perror("listen");
         exit(0);
     }

     rc = getsockname(sock, (struct sockaddr *) &xxx, &len);
     printf("get rc %d, len %d, listening on %s:%d\n",
            rc, len,
            inet_ntoa(xxx.sin_addr),
            ntohs(xxx.sin_port));
     if (atoi(inet_ntoa(xxx.sin_addr)) != atoi(inet_ntoa(addr.sin_addr)))
     {
         printf("address has changed!\n");
         exit(0);
     }

     close(sock);
     return 0;
}

int main(void)
{
    int x = 0;

    while (1)
    {
        x++;
        printf("attempt number %d\n", x);
        foo();
    }
    return (0);
}

[Steve And Grace Bovy]

--- In hercules-390@... <mailto:hercules-390%40yahoogroups.com>
, "kerravon86" <kerravon86@...> wrote:
>
> Thanks, but I don't consider that to be "clear".
> I consider that to be "quibbling". :-)

"ambiguous" perhaps.

> And then - what happens on other people's computers
> when they ran that small test program?

Here's a better one to run:

C:\devel\develop>gcc -o sockbug sockbug.c

C:\devel\develop>sockbug
attempt number 1
get rc 0, len 16, listening on 127.0.0.1:60353
attempt number 2
get rc 0, len 16, listening on 127.0.0.1:60354
attempt number 3
get rc 0, len 16, listening on 127.0.0.1:60355
attempt number 4
get rc 0, len 16, listening on 0.0.0.0:60356
address has changed!

#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <string.h>
#include <stdlib.h>
#include <netinet/in.h>
#include <arpa/inet.h>

int foo()
{
int sock, len, rc;
struct sockaddr_in addr, xxx;

len = sizeof xxx;
if((sock=socket(AF_INET, SOCK_STREAM, 0))<0)
{
exit(0);
}

memset(&addr, 0, sizeof(struct sockaddr_in));
addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl(INADDR_LOOPBACK);
addr.sin_port = htons(0);

if(bind(sock, (struct sockaddr *) &addr,
sizeof(struct sockaddr_in))<0)
{
perror("bind");
exit(0);
}

if(listen(sock, 5)<0)
{
perror("listen");
exit(0);
}

rc = getsockname(sock, (struct sockaddr *) &xxx, &len);
printf("get rc %d, len %d, listening on %s:%d\n",
rc, len,
inet_ntoa(xxx.sin_addr),
ntohs(xxx.sin_port));
if (atoi(inet_ntoa(xxx.sin_addr)) != atoi(inet_ntoa(addr.sin_addr)))
{
printf("address has changed!\n");
exit(0);
}

close(sock);
return 0;
}

int main(void)
{
int x = 0;

while (1)
{
x++;
printf("attempt number %d\n", x);
foo();
}
return (0);
}


************************************

I see you are testing with gcc.  Are you using cygwin, sfu/sua or ming ????

I thought this was a windows issue ???  Does this also occur on Linux
platforms ??

Shouldn't we be testing with the same windows compiler and library that is
used to build herc ???

The reason I ask is that the socket calls are after all library calls, if
the binary
Libraries you are using are not identical you could get different results.

The program you posted is not a windows oriented socket program.      

[kerravon86]

--- In hercules-390@..., "Steve And Grace Bovy" <sg.bovy@...> wrote:
>
> I see you are testing with gcc.  Are you using cygwin,
> sfu/sua or ming ????

Cygwin.

> I thought this was a windows issue ???  

Yep.

> Does this also occur on Linux platforms ??

I doubt it.

> Shouldn't we be testing with the same windows
> compiler and library that is used to build herc ???

I did that already. Then used a completely different
compiler and reproduced the problem, showing that it
is a Windows issue, not a compiler or library issue.

> The reason I ask is that the socket calls are after
> all library calls, if the binary
> Libraries you are using are not identical you could
> get different results.

I get random results, no matter which compiler I
use. So, the next obvious question is whether it is
just my Windows, or everyone's Windows.

What happens on your compiler on your Windows after
running for 20 minutes?

> The program you posted is not a windows oriented
> socket program.

Which assists in demonstrating that it's not a
Hercules unusual coding problem! "standard unix"
instead. I tried compiling that program with other
compilers. bcc32 compiled and linked but ran with
an error on the socket call. wcl386 failed to link.

I didn't see an option on either compiler saying
"don't give an error on the link", so left it at
that. sockets aren't my forte. :-)

BFN.  Paul.

[Mike Schwab]

Maybe that explain our network problem at work.  About every half
hour, a M$ product that uses a network file hangs for 5 minutes and
gradually hangs other netowrk programs and often the taskbar gets hung
up to where it wont switch to another program.  Eventually, something
on the network starts working again and everything takes off.

On Wed, Jul 1, 2009 at 7:14 AM, kerravon86<kerravon86@...> wrote:
> --- In hercules-390@..., "Steve And Grace Bovy" <sg.bovy@...> wrote:
<deleted>>

>
>> Shouldn't we be testing with the same windows
>> compiler and library that is used to build herc ???
>
> I did that already. Then used a completely different
> compiler and reproduced the problem, showing that it
> is a Windows issue, not a compiler or library issue.
>
>> The reason I ask is that the socket calls are after
>> all library calls, if the binary
>> Libraries you are using are not identical you could
>> get different results.
>
> I get random results, no matter which compiler I
> use. So, the next obvious question is whether it is
> just my Windows, or everyone's Windows.
>
> What happens on your compiler on your Windows after
> running for 20 minutes?
>
>> The program you posted is not a windows oriented
>> socket program.
>
> Which assists in demonstrating that it's not a
> Hercules unusual coding problem! "standard unix"
> instead. I tried compiling that program with other
> compilers. bcc32 compiled and linked but ran with
> an error on the socket call. wcl386 failed to link.
>
> I didn't see an option on either compiler saying
> "don't give an error on the link", so left it at
> that. sockets aren't my forte. :-)
>
> BFN.  Paul.

--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

[fish-8]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kerravon86 wrote:

[...]

> Here's a better one to run:
>
> C:\devel\develop>gcc -o sockbug sockbug.c
>
> C:\devel\develop>sockbug
> attempt number 1
> get rc 0, len 16, listening on 127.0.0.1:60353
> attempt number 2
> get rc 0, len 16, listening on 127.0.0.1:60354
> attempt number 3
> get rc 0, len 16, listening on 127.0.0.1:60355
> attempt number 4
> get rc 0, len 16, listening on 0.0.0.0:60356
> address has changed!
>
>
> #include <stdio.h>
> #include <sys/types.h>

[...]
> int foo()
> {
>      int sock, len, rc;
>      struct sockaddr_in addr, xxx;
>
>      len = sizeof xxx;
>      if((sock=socket(AF_INET, SOCK_STREAM, 0))<0)
>      {
[...]

> int main(void)
> {
>     int x = 0;
>
>     while (1)
>     {
>         x++;
>         printf("attempt number %d\n", x);
>         foo();
>     }
>     return (0);
> }

FYI:

  Your is likely cygwin (or mingw?) related.

  Using your test program (along with the changes needed for it to
build and run with VS2008 SP1; see below) runs without error.


<--------------------(cut here)-------------------->

#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0500
#endif

#include <stdio.h>
#include <tchar.h>

#include <winsock2.h>
#pragma comment( lib, "ws2_32" )


int sockerr( LPCTSTR func )
{
    int nWSALastError = WSAGetLastError();
    _tprintf( _T("%s: rc=%d (0x%08.8x)\n"), func, nWSALastError,
nWSALastError );
    return -1;
}

int sockinit()
{
    WORD wVersionRequested;
    WSADATA wsaData;
    int err;
//  wVersionRequested = MAKEWORD( 2, 0 );
    wVersionRequested = MAKEWORD( 1, 1 );
    err = WSAStartup( wVersionRequested, &wsaData );
    return ( err != 0 ) ? sockerr( _T("WSAStartup") ) : 0;
}

int foo()
{
    SOCKET sock;
    int len, rc;
    struct sockaddr_in  addr;
    struct sockaddr_in  xxx;

    len = sizeof xxx;

    if ((sock = socket( AF_INET, SOCK_STREAM, 0 )) == INVALID_SOCKET)
        return sockerr( _T("socket") );

    memset( &addr, 0, sizeof( struct sockaddr_in ) );

    addr.sin_family      = AF_INET;
    addr.sin_addr.s_addr = htonl( INADDR_LOOPBACK );
    addr.sin_port        = htons( 0 );

    if (bind( sock, (struct sockaddr*) &addr, sizeof( struct
sockaddr_in )) < 0)
        return sockerr( _T("bind") );

    if (listen( sock, 5 ) < 0)
        return sockerr( _T("listen") );

    rc = getsockname( sock, (struct sockaddr*) &xxx, &len );

    _tprintf
    (
        _T("getsockname: rc %d, len %d, listening on %hs:%d\n")

        ,rc
        ,len
        ,inet_ntoa( xxx.sin_addr )
        ,ntohs(     xxx.sin_port )
    );

    if (atoi( inet_ntoa(  xxx.sin_addr )) !=
        atoi( inet_ntoa( addr.sin_addr )))
    {
        _tprintf( _T("address has changed!\n") );
        return -1;
    }

    closesocket( sock );
    return 0;
}

int _tmain( int argc, _TCHAR* argv[] )
{
    if (sockinit() == 0)
    {
        int x = 0;
        do _tprintf( _T("attempt number %d: "), ++x );
        while( foo() == 0 );
    }

    return 0;
}

<--------------------(cut here)-------------------->


- - --
"Fish" (David B. Trout) - fish@...
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBSkvE4Ej11/TE7j4qEQL93ACguzFRE04NGGSelciD4FKQQHtRQvIAoNjA
WH9aXAcFXv0BIxPwsI0IA2W0
=5k5q
-----END PGP SIGNATURE-----

[kerravon86]

--- In hercules-390@..., "Fish" <fish@...> wrote:
>
>   Your is likely cygwin (or mingw?) related.

I spent most of the weekend debugging under MSVC!

Anyway, good news is that your version actually
compiles as a standalone executable using "cl",
unlike the other version. As such, I've just
uploaded it to the files area called "fishbug.exe".

Here's an example execution:

C:\devel\develop>fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:63097
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:63098
attempt number 3: getsockname: rc 0, len 16, listening on 0.0.0.0:63099
address has changed!

I'm running 32-bit Windows Vista. You?

>   Using your test program (along with the changes needed for it to
> build and run with VS2008 SP1; see below) runs without error.

I'm still using VS2005.

BFN.  Paul.

[Kevin Leonard-2]

> C:\devel\develop>fishbug
> attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:63097
> attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:63098
> attempt number 3: getsockname: rc 0, len 16, listening on 0.0.0.0:63099
> address has changed!
>
> I'm running 32-bit Windows Vista. You?

Maybe that has something to do with it.  When I run the
fishbug executable you built on a 32-bit Windows XP SP2+
system, it doesn't fail after more than 150,000 attempts:

[C:\Temp]fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:3474
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:3475
attempt number 3: getsockname: rc 0, len 16, listening on 127.0.0.1:3476
attempt number 4: getsockname: rc 0, len 16, listening on 127.0.0.1:3477
attempt number 5: getsockname: rc 0, len 16, listening on 127.0.0.1:3478
...
attempt number 161742: getsockname: rc 0, len 16, listening on 127.0.0.1:2363
attempt number 161743: getsockname: rc 0, len 16, listening on 127.0.0.1:2364
attempt number 161744: getsockname: rc 0, len 16, listening on 127.0.0.1:2365
attempt number 161745: getsockname: rc 0, len 16, listening on 127.0.0.1:2366
attempt number 161746: getsockname: rc 0, len 16, listening on 127.0.0.1:2367
attem ^C

I also built your non-MS version with gcc and got similar
results:

[C:\AppLocal\Testc]testc
attempt number 1: get rc 0, len 16, listening on 127.0.0.1:2480
attempt number 2: get rc 0, len 16, listening on 127.0.0.1:2481
attempt number 3: get rc 0, len 16, listening on 127.0.0.1:2482
attempt number 4: get rc 0, len 16, listening on 127.0.0.1:2483
attempt number 5: get rc 0, len 16, listening on 127.0.0.1:2484
...
attempt number 132132: get rc 0, len 16, listening on 127.0.0.1:3712
attempt number 132133: get rc 0, len 16, listening on 127.0.0.1:3713
attempt number 132134: get rc 0, len 16, listening on 127.0.0.1:3714
^C

For what it's worth, the port assigned under XP was
always in the range 1025 through 5000.

--
Kevin

[Steve And Grace Bovy]

> C:\devel\develop>fishbug
> attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:63097
> attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:63098
> attempt number 3: getsockname: rc 0, len 16, listening on 0.0.0.0:63099
> address has changed!
>
> I'm running 32-bit Windows Vista. You?

Maybe that has something to do with it. When I run the
fishbug executable you built on a 32-bit Windows XP SP2+
system, it doesn't fail after more than 150,000 attempts:

[C:\Temp]fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:3474
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:3475
attempt number 3: getsockname: rc 0, len 16, listening on 127.0.0.1:3476
attempt number 4: getsockname: rc 0, len 16, listening on 127.0.0.1:3477
attempt number 5: getsockname: rc 0, len 16, listening on 127.0.0.1:3478
...
attempt number 161742: getsockname: rc 0, len 16, listening on
127.0.0.1:2363
attempt number 161743: getsockname: rc 0, len 16, listening on
127.0.0.1:2364
attempt number 161744: getsockname: rc 0, len 16, listening on
127.0.0.1:2365
attempt number 161745: getsockname: rc 0, len 16, listening on
127.0.0.1:2366
attempt number 161746: getsockname: rc 0, len 16, listening on
127.0.0.1:2367
attem ^C

I also built your non-MS version with gcc and got similar
results:

[C:\AppLocal\Testc]testc
attempt number 1: get rc 0, len 16, listening on 127.0.0.1:2480
attempt number 2: get rc 0, len 16, listening on 127.0.0.1:2481
attempt number 3: get rc 0, len 16, listening on 127.0.0.1:2482
attempt number 4: get rc 0, len 16, listening on 127.0.0.1:2483
attempt number 5: get rc 0, len 16, listening on 127.0.0.1:2484
...
attempt number 132132: get rc 0, len 16, listening on 127.0.0.1:3712
attempt number 132133: get rc 0, len 16, listening on 127.0.0.1:3713
attempt number 132134: get rc 0, len 16, listening on 127.0.0.1:3714
^C

For what it's worth, the port assigned under XP was
always in the range 1025 through 5000.

--
Kevin

********************************************************

> I'm running 32-bit Windows Vista. You?

Maybe that has something to do with it. When I run the
fishbug executable you built on a 32-bit Windows XP SP2+
system, it doesn't fail after more than 150,000 attempts:

>> HMMMM  <<  

Vista uses ip6 >>>

So maybe we have an address transliteration problem with vista
Because of ip6 ?????  

[Steve And Grace Bovy]

> C:\devel\develop>fishbug
> attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:63097
> attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:63098
> attempt number 3: getsockname: rc 0, len 16, listening on 0.0.0.0:63099
> address has changed!
>
> I'm running 32-bit Windows Vista. You?

Maybe that has something to do with it. When I run the
fishbug executable you built on a 32-bit Windows XP SP2+
system, it doesn't fail after more than 150,000 attempts:

[C:\Temp]fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:3474
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:3475
attempt number 3: getsockname: rc 0, len 16, listening on 127.0.0.1:3476
attempt number 4: getsockname: rc 0, len 16, listening on 127.0.0.1:3477
attempt number 5: getsockname: rc 0, len 16, listening on 127.0.0.1:3478
...
attempt number 161742: getsockname: rc 0, len 16, listening on
127.0.0.1:2363
attempt number 161743: getsockname: rc 0, len 16, listening on
127.0.0.1:2364
attempt number 161744: getsockname: rc 0, len 16, listening on
127.0.0.1:2365
attempt number 161745: getsockname: rc 0, len 16, listening on
127.0.0.1:2366
attempt number 161746: getsockname: rc 0, len 16, listening on
127.0.0.1:2367
attem ^C

I also built your non-MS version with gcc and got similar
results:

[C:\AppLocal\Testc]testc
attempt number 1: get rc 0, len 16, listening on 127.0.0.1:2480
attempt number 2: get rc 0, len 16, listening on 127.0.0.1:2481
attempt number 3: get rc 0, len 16, listening on 127.0.0.1:2482
attempt number 4: get rc 0, len 16, listening on 127.0.0.1:2483
attempt number 5: get rc 0, len 16, listening on 127.0.0.1:2484
...
attempt number 132132: get rc 0, len 16, listening on 127.0.0.1:3712
attempt number 132133: get rc 0, len 16, listening on 127.0.0.1:3713
attempt number 132134: get rc 0, len 16, listening on 127.0.0.1:3714
^C

For what it's worth, the port assigned under XP was
always in the range 1025 through 5000.

--
Kevin

**********************

Paul, thanks for the test program !!

I just ran it on my XP SP3 system, and it works perfectly :)

I have two vista systems, I will try it on these systems shortly :)

[Steve And Grace Bovy]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kerravon86 wrote:

[...]

> Here's a better one to run:
>
> C:\devel\develop>gcc -o sockbug sockbug.c
>
> C:\devel\develop>sockbug
> attempt number 1
> get rc 0, len 16, listening on 127.0.0.1:60353
> attempt number 2
> get rc 0, len 16, listening on 127.0.0.1:60354
> attempt number 3
> get rc 0, len 16, listening on 127.0.0.1:60355
> attempt number 4
> get rc 0, len 16, listening on 0.0.0.0:60356
> address has changed!
>
>
> #include <stdio.h>
> #include <sys/types.h>

[...]
> int foo()
> {
> int sock, len, rc;
> struct sockaddr_in addr, xxx;
>
> len = sizeof xxx;
> if((sock=socket(AF_INET, SOCK_STREAM, 0))<0)
> {
[...]

> int main(void)
> {
> int x = 0;
>
> while (1)
> {
> x++;
> printf("attempt number %d\n", x);
> foo();
> }
> return (0);
> }

FYI:

Your is likely cygwin (or mingw?) related.

Using your test program (along with the changes needed for it to
build and run with VS2008 SP1; see below) runs without error.

<--------------------(cut here)-------------------->

#ifndef _WIN32_WINNT
#define _WIN32_WINNT 0x0500
#endif

#include <stdio.h>
#include <tchar.h>

#include <winsock2.h>
#pragma comment( lib, "ws2_32" )

int sockerr( LPCTSTR func )
{
int nWSALastError = WSAGetLastError();
_tprintf( _T("%s: rc=%d (0x%08.8x)\n"), func, nWSALastError,
nWSALastError );
return -1;
}

int sockinit()
{
WORD wVersionRequested;
WSADATA wsaData;
int err;
// wVersionRequested = MAKEWORD( 2, 0 );
wVersionRequested = MAKEWORD( 1, 1 );
err = WSAStartup( wVersionRequested, &wsaData );
return ( err != 0 ) ? sockerr( _T("WSAStartup") ) : 0;
}

int foo()
{
SOCKET sock;
int len, rc;
struct sockaddr_in addr;
struct sockaddr_in xxx;

len = sizeof xxx;

if ((sock = socket( AF_INET, SOCK_STREAM, 0 )) == INVALID_SOCKET)
return sockerr( _T("socket") );

memset( &addr, 0, sizeof( struct sockaddr_in ) );

addr.sin_family = AF_INET;
addr.sin_addr.s_addr = htonl( INADDR_LOOPBACK );
addr.sin_port = htons( 0 );

if (bind( sock, (struct sockaddr*) &addr, sizeof( struct
sockaddr_in )) < 0)
return sockerr( _T("bind") );

if (listen( sock, 5 ) < 0)
return sockerr( _T("listen") );

rc = getsockname( sock, (struct sockaddr*) &xxx, &len );

_tprintf
(
_T("getsockname: rc %d, len %d, listening on %hs:%d\n")

,rc
,len
,inet_ntoa( xxx.sin_addr )
,ntohs( xxx.sin_port )
);

if (atoi( inet_ntoa( xxx.sin_addr )) !=
atoi( inet_ntoa( addr.sin_addr )))
{
_tprintf( _T("address has changed!\n") );
return -1;
}

closesocket( sock );
return 0;
}

int _tmain( int argc, _TCHAR* argv[] )
{
if (sockinit() == 0)
{
int x = 0;
do _tprintf( _T("attempt number %d: "), ++x );
while( foo() == 0 );
}

return 0;
}

**************************

Fish, thanks for updating this test program :) :)

[Steve And Grace Bovy]

> C:\devel\develop>fishbug
> attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:63097
> attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:63098
> attempt number 3: getsockname: rc 0, len 16, listening on 0.0.0.0:63099
> address has changed!
>
> I'm running 32-bit Windows Vista. You?

Maybe that has something to do with it. When I run the
fishbug executable you built on a 32-bit Windows XP SP2+
system, it doesn't fail after more than 150,000 attempts:

[C:\Temp]fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:3474
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:3475
attempt number 3: getsockname: rc 0, len 16, listening on 127.0.0.1:3476
attempt number 4: getsockname: rc 0, len 16, listening on 127.0.0.1:3477
attempt number 5: getsockname: rc 0, len 16, listening on 127.0.0.1:3478
...
attempt number 161742: getsockname: rc 0, len 16, listening on
127.0.0.1:2363
attempt number 161743: getsockname: rc 0, len 16, listening on
127.0.0.1:2364
attempt number 161744: getsockname: rc 0, len 16, listening on
127.0.0.1:2365
attempt number 161745: getsockname: rc 0, len 16, listening on
127.0.0.1:2366
attempt number 161746: getsockname: rc 0, len 16, listening on
127.0.0.1:2367
attem ^C

I also built your non-MS version with gcc and got similar
results:

[C:\AppLocal\Testc]testc
attempt number 1: get rc 0, len 16, listening on 127.0.0.1:2480
attempt number 2: get rc 0, len 16, listening on 127.0.0.1:2481
attempt number 3: get rc 0, len 16, listening on 127.0.0.1:2482
attempt number 4: get rc 0, len 16, listening on 127.0.0.1:2483
attempt number 5: get rc 0, len 16, listening on 127.0.0.1:2484
...
attempt number 132132: get rc 0, len 16, listening on 127.0.0.1:3712
attempt number 132133: get rc 0, len 16, listening on 127.0.0.1:3713
attempt number 132134: get rc 0, len 16, listening on 127.0.0.1:3714
^C

For what it's worth, the port assigned under XP was
always in the range 1025 through 5000.

--
Kevin

***********************************

I just ran fishbug on vista ultimate x64 << no problemo >>>
I just ran fishbug on vista basic x32   <<  no problemo >>>>

[Steve And Grace Bovy]

> C:\devel\develop>fishbug
> attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:63097
> attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:63098
> attempt number 3: getsockname: rc 0, len 16, listening on 0.0.0.0:63099
> address has changed!
>
> I'm running 32-bit Windows Vista. You?

Maybe that has something to do with it. When I run the
fishbug executable you built on a 32-bit Windows XP SP2+
system, it doesn't fail after more than 150,000 attempts:

[C:\Temp]fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:3474
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:3475
attempt number 3: getsockname: rc 0, len 16, listening on 127.0.0.1:3476
attempt number 4: getsockname: rc 0, len 16, listening on 127.0.0.1:3477
attempt number 5: getsockname: rc 0, len 16, listening on 127.0.0.1:3478
...
attempt number 161742: getsockname: rc 0, len 16, listening on
127.0.0.1:2363
attempt number 161743: getsockname: rc 0, len 16, listening on
127.0.0.1:2364
attempt number 161744: getsockname: rc 0, len 16, listening on
127.0.0.1:2365
attempt number 161745: getsockname: rc 0, len 16, listening on
127.0.0.1:2366
attempt number 161746: getsockname: rc 0, len 16, listening on
127.0.0.1:2367
attem ^C

I also built your non-MS version with gcc and got similar
results:

[C:\AppLocal\Testc]testc
attempt number 1: get rc 0, len 16, listening on 127.0.0.1:2480
attempt number 2: get rc 0, len 16, listening on 127.0.0.1:2481
attempt number 3: get rc 0, len 16, listening on 127.0.0.1:2482
attempt number 4: get rc 0, len 16, listening on 127.0.0.1:2483
attempt number 5: get rc 0, len 16, listening on 127.0.0.1:2484
...
attempt number 132132: get rc 0, len 16, listening on 127.0.0.1:3712
attempt number 132133: get rc 0, len 16, listening on 127.0.0.1:3713
attempt number 132134: get rc 0, len 16, listening on 127.0.0.1:3714
^C

For what it's worth, the port assigned under XP was
always in the range 1025 through 5000.

--
Kevin

***********************************

I just ran fishbug on vista ultimate x64 << no problemo >>>
I just ran fishbug on vista basic x32 << no problemo >>>>

*****************************

Further thoughts

Is it possible we have a logic path where
A windows process thread is not initing the windows socket library ??

int sockinit()
{
WORD wVersionRequested;
WSADATA wsaData;
int err;
// wVersionRequested = MAKEWORD( 2, 0 );
wVersionRequested = MAKEWORD( 1, 1 );
err = WSAStartup( wVersionRequested, &wsaData );
return ( err != 0 ) ? sockerr( _T("WSAStartup") ) : 0;
}

[kerravon86]

--- In hercules-390@..., "Steve And Grace Bovy" <sg.bovy@...> wrote:
>
> I just ran fishbug on vista basic x32   <<  no problemo >>>>

Ok, that's what I'm using, so I went mad disabling
firewalls, disabling AVG, closing all apps. No
change except that I managed to get a lot more
successes before the first failure with a faster
system after closing all those windows.

I then switched off user access control, which
required a reboot. After the reboot, I was able
to do hundreds of thousands without any problem.

So I put things back to how they used to be, and
still didn't have a problem, but I'm not sure
the exact sequence. Until I closed Windows Mail.
Then fishbug stopped with the address change.
So I suspected it was something to do with either
the AVG free email scanner, or the OE Quotefix
program - the only email-related things I know
I have.

I tried rebooting and then running fishbug at
the first opportunity. It basically died as the
different compoentns (AVG, ICQ etc) started.

Finally I tried the following sequence:

Reboot.

Let jjdaemon (Telstra), AVG free, Yahoo, ICQ,
MSN, Skype start automatically.

Run fishbug.

Here's what I got:

...
attempt number 16255: getsockname: rc 0, len 16, listening on 127.0.0.1:65527
attempt number 16256: getsockname: rc 0, len 16, listening on 127.0.0.1:65528
attempt number 16257: getsockname: rc 0, len 16, listening on 127.0.0.1:65529
attempt number 16258: getsockname: rc 0, len 16, listening on 127.0.0.1:65530
attempt number 16259: getsockname: rc 0, len 16, listening on 127.0.0.1:65531
attempt number 16260: getsockname: rc 0, len 16, listening on 127.0.0.1:65532
attempt number 16261: getsockname: rc 0, len 16, listening on 127.0.0.1:65533
attempt number 16262: getsockname: rc 0, len 16, listening on 127.0.0.1:65534
attempt number 16263: getsockname: rc 0, len 16, listening on 127.0.0.1:49157
attempt number 16264: getsockname: rc 0, len 16, listening on 0.0.0.0:49158
address has changed!

So it looks like some low port numbers get used by
some of those apps, and when it cycles to them, if
they're still in use, they get reused and Windows
gets confused or something.

Anyway, let's see where we go from here. :-)

BFN.  Paul.

[somitcw-2]

--- In hercules-390@...,
 "kerravon86" <kerravon86@...> wrote:
- - - snipped - - -
> Anyway, let's see where we go from here. :-)
> BFN.  Paul.

   If the bug is sensitive to the load on the system,
is it possible that the number of processors matter?
Do you have a duo or quad core?

[fish-8]

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

kerravon86 wrote:

> --- In hercules-390@..., "Steve And Grace Bovy"
> <sg.bovy@...> wrote:
> >
> > I just ran fishbug on vista basic x32   <<  no problemo >>>>
>
> Ok, that's what I'm using,

So the problem is unique to your system (as well as maybe a few other
peoples' systems too?) and thus does NOT appear to be a Hercules
problem.

Thus our discussion of this issue is *technically* off-topic.

Suggestion: someone (not me) should create a new group (say,
'hercules-390-offtopic'??) where we could then pursue this issue
without cluttering the main hercules-390 list with our off-topic
Windows-specific issue. (Unless that is Jay and others don't mind?
Jay?)


[...]
> Until I closed Windows Mail. Then fishbug stopped
> with the address change. So I suspected it was
> something to do with either the AVG free email scanner,
> or the OE Quotefix program - the only email-related
> things I know I have.
[...]

> Anyway, let's see where we go from here. :-)

Did some Googling but couldn't find anything specifically related to
our specific issue, but I did come across the following post which
sounds interesting since it mentions LSP: [1]

  "socket() problem on a vista system: 10050"
  http://tinyurl.com/lxamz7


LSP (see footnote) is a frequent cause of networking issues since
it's tricky to do correctly (depending on what the hook is doing of
course). I know because I use it in my [obsolete] AdCruncher Proxy[2]
product to provide transparent proxying, and writing the program to
install/uninstall my LSP hook was a royal PITA.

While I have no way of knowing for sure (since I don't use AVG), I
wouldn't be surprised if AVG used it to provide networking protection
since it allows one to easily intercept (and possibly modify) any/all
socket requests and/or traffic. Google uses it in their Google
Desktop product as well (or is it their Google Toolbar product? I
forget which).

"Bad Guys(tm)" (i.e. malware writers) also like using it for the very
same reason.

So while it may be a long shot, but just for fun, open an elevated
("Administrative?") Command Prompt window and enter the following
command:

  netsh winsock show catalog | find "Protocol Chain Length"

The response you should get should be:

  Protocol Chain Length:              1
  Protocol Chain Length:              1
  Protocol Chain Length:              1
  [...etc...]

If, according to the above mentioned article, you see any entry whose
Protocol Chain Length is other than '1', then that *could* indicate a
problem.

Regardless of the outcome however, I would strongly suggest attacking
this issue systematically as follows:

Uninstall ALL of your network related products and then reinstall
them one by one, being sure to reboot afterwards each time (since LSP
doesn't become active until after a reboot (I think)), and then after
each install running fishbug to see if the problem has manifested
itself or not. That alone might be good enough to identify which
piece of software is causing your problem.

Just to be safe, you might also consider installing/running
RootkitRevealer too, just in case:

  RootkitRevealer:
  http://tinyurl.com/2gukvq

A Rootkit[3] is, IMHO, the ABSOLUTE WORST POSSIBLE piece of malware
you could possibly have on your system, and few (if any) antivirus
products detect or protect you from them. If you've been compromised
with a rootkit, the best course of action is to reformat your hard
drive and reinstall your operating system from scratch using the
original distribution media. Seriously. Don't risk trying to somehow
"uninstall" the rootkit. Once you've been rooted then *everything* is
suspect (any/all programs).

The issue could also conceivably be nothing more than a bug in
Microsoft's CRT (C Runtime DLLs). Make sure you're using the latest
and greatest:


  VS2005 SP1 Redistributables
  http://tinyurl.com/3akddh


  VS2008 SP1 Redistributables
  http://tinyurl.com/4dwx3d


(Note! Make sure they're the **>> SP1 <<** version!)

Since you're doing Visual Studio development too, make sure your copy
of Visual Studio is ALSO at the 'SP1' level. Earlier versions of
Visual Studio were buggy.

Finally, make sure you're current with all your patches. When
visiting Microsoft Update[4] be sure to ALWAYS do a "Custom" scan and
NEVER just an "Express" scan. An Express scan just scans for critical
security updates whereas a Custom scan will alert you to important
non-security-related updates as well.


Good luck!

Be sure to let us know how it goes.

- --
"Fish" (David B. Trout) - fish@...
Fight Spam! Join CAUCE! <http://www.cauce.org/>
7 reasons why HTML email is a bad thing
http://www.georgedillon.com/web/html_email_is_evil.shtml
PGP key fingerprints:
RSA: 6B37 7110 7201 9917 9B0D 99E3 55DB 5D58 FADE 4A52
DH/DSS: 9F9B BAB0 BA7F C458 1A89 FE26 48F5 D7F4 C4EE 3E2A

[1] Layered Service Provider:
    http://en.wikipedia.org/wiki/Layered_service_provider

[2] AdCruncher Proxy:
    http://www.softdevlabs.com/AdCruncher/ReadMe.html

[3] Root Kit:
    http://en.wikipedia.org/wiki/Root_kit

[4] Microsoft Update:
   
http://update.microsoft.com/microsoftupdate/v6/default.aspx?ln=en-us


-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBSkz24Ej11/TE7j4qEQIeyACfWjZqU+s7XaYUb3aVMaMs/GJSZWgAoIkq
pnS1ckKKXNkSzRJkD5k7PHpQ
=+7qC
-----END PGP SIGNATURE-----

[kerravon86]

--- In hercules-390@..., "somitcw" <somitcw@...> wrote:
>
> > Anyway, let's see where we go from here. :-)
>
>    If the bug is sensitive to the load on the system,
> is it possible that the number of processors matter?
> Do you have a duo or quad core?

No. I have a Celeron (single core).

BFN.  Paul.

[kerravon86]

--- In hercules-390@..., "Fish" <fish@...> wrote:
>
> > > I just ran fishbug on vista basic x32   <<  no problemo >>>>
> >
> > Ok, that's what I'm using,
>
> So the problem is unique to your system (as well as
> maybe a few other peoples' systems too?) and thus does
> NOT appear to be a Hercules problem.

Well, it depends on whether the Windows call
getsockname:

1. Is allowed to return a zero-address in the
circumstances in question.

2. Isn't allowed to, but there is a Windows bug that
rears its head in the right circumstances.

If number 1 is true, then Hercules is at fault, so
it's definitely on-topic.

If number 2 is true, then the Hercules developers
may wish to work around the "known Windows bug", and
thus it is on-topic also.

If you believe I have a virus on my machine, been
there undetected for months, which impacts
getsockname randomly, then it might be off-topic
I guess.

> Suggestion: someone (not me) should create a new group (say,
> 'hercules-390-offtopic'??) where we could then pursue this issue
> without cluttering the main hercules-390 list with our off-topic
> Windows-specific issue.

I'd prefer it if people with Ubuntu (wtf?) setup
issues were the ones who had to migrate. :-)

The fact that there are comments in the Hercules
code saying that there is a longstanding issue
with a -1 socket suggests that it has occurred
on other people's PCs before.  It would sure be
nice if I wasn't alone on this one. :-)

BFN.  Paul.

[kerravon86]

--- In hercules-390@..., "kerravon86" <kerravon86@...> wrote:

>
> --- In hercules-390@..., "Steve And Grace Bovy" <sg.bovy@> wrote:
> >
> > I just ran fishbug on vista basic x32   <<  no problemo >>>>
>
> Ok, that's what I'm using, so I went mad disabling
> firewalls, disabling AVG, closing all apps. No
> change except that I managed to get a lot more
> successes before the first failure with a faster
> system after closing all those windows.
>
> I then switched off user access control, which
> required a reboot. After the reboot, I was able
> to do hundreds of thousands without any problem.
>
> So I put things back to how they used to be, and
> still didn't have a problem, but I'm not sure
> the exact sequence. Until I closed Windows Mail.
> Then fishbug stopped with the address change.
> So I suspected it was something to do with either
> the AVG free email scanner, or the OE Quotefix
> program - the only email-related things I know
> I have.
>
> I tried rebooting and then running fishbug at
> the first opportunity. It basically died as the
> different compoentns (AVG, ICQ etc) started.
>
> Finally I tried the following sequence:
>
> Reboot.
>
> Let jjdaemon (Telstra), AVG free, Yahoo, ICQ,
> MSN, Skype start automatically.
>
> Run fishbug.
>
> Here's what I got:
>
> ...
> attempt number 16255: getsockname: rc 0, len 16, listening on 127.0.0.1:65527
> attempt number 16256: getsockname: rc 0, len 16, listening on 127.0.0.1:65528
> attempt number 16257: getsockname: rc 0, len 16, listening on 127.0.0.1:65529
> attempt number 16258: getsockname: rc 0, len 16, listening on 127.0.0.1:65530
> attempt number 16259: getsockname: rc 0, len 16, listening on 127.0.0.1:65531
> attempt number 16260: getsockname: rc 0, len 16, listening on 127.0.0.1:65532
> attempt number 16261: getsockname: rc 0, len 16, listening on 127.0.0.1:65533
> attempt number 16262: getsockname: rc 0, len 16, listening on 127.0.0.1:65534
> attempt number 16263: getsockname: rc 0, len 16, listening on 127.0.0.1:49157
> attempt number 16264: getsockname: rc 0, len 16, listening on 0.0.0.0:49158
> address has changed!

Tried again today and got the same thing:

attempt number 4232: getsockname: rc 0, len 16, listening on 127.0.0.1:65533
attempt number 4233: getsockname: rc 0, len 16, listening on 127.0.0.1:65534
attempt number 4234: getsockname: rc 0, len 16, listening on 127.0.0.1:49157
attempt number 4235: getsockname: rc 0, len 16, listening on 0.0.0.0:49158
address has changed!

although there were more errors along the way, but
4000 successes is not bad.


Then it got pretty ferocious:

attempt number 4233: getsockname: rc 0, len 16, listening on 127.0.0.1:65534
attempt number 4234: getsockname: rc 0, len 16, listening on 127.0.0.1:49157
attempt number 4235: getsockname: rc 0, len 16, listening on 0.0.0.0:49158
address has changed!

C:\devel\develop>fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 0.0.0.0:49185
address has changed!

C:\devel\develop>fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:49186
attempt number 2: getsockname: rc 0, len 16, listening on 0.0.0.0:49187
address has changed!

C:\devel\develop>fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:49189
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:49190
attempt number 3: getsockname: rc 0, len 16, listening on 0.0.0.0:49191
address has changed!

C:\devel\develop>fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:49192
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:49193
attempt number 3: getsockname: rc 0, len 16, listening on 0.0.0.0:49194
address has changed!


So I decided to put it into a batch file.

C:\devel\develop>goto ff

C:\devel\develop>fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:50933
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:50934
attempt number 3: getsockname: rc 0, len 16, listening on 127.0.0.1:50935
attempt number 4: getsockname: rc 0, len 16, listening on 0.0.0.0:50936
address has changed!

C:\devel\develop>goto ff

C:\devel\develop>fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:50937
attempt number 2: getsockname: rc 0, len 16, listening on 127.0.0.1:50938
attempt number 3: getsockname: rc 0, len 16, listening on 127.0.0.1:50939
attempt number 4: getsockname: rc 0, len 16, listening on 127.0.0.1:50940
attempt number 5: getsockname: rc 0, len 16, listening on 127.0.0.1:50941
attempt number 6: getsockname: rc 0, len 16, listening on 127.0.0.1:50942
attempt number 7: getsockname: rc 0, len 16, listening on 127.0.0.1:50943
...
attempt number 552: getsockname: rc 0, len 16, listening on 127.0.0.1:51489
attempt number 553: getsockname: rc 0, len 16, listening on 127.0.0.1:51490
attempt number 554: getsockname: rc 0, len 16, listening on 127.0.0.1:51491
attempt number 555: getsockname: rc 0, len 16, listening on 127.0.0.1:51492
attempt number 556: getsockname: rc 0, len 16, listening on 127.0.0.1:51493
attempt number 557: getsockname: rc 0, len 16, listening on 127.0.0.1:51494
attempt number 558: getsockname: rc 0, len 16, listening on 127.0.0.1:51495
attempt number 559: getsockname: rc 0, len 16, listening on 127.0.0.1:51496
attempt number 560: getsockname: rc 0, len 16, listening on 127.0.0.1:51497
^CTerminate batch job (Y/N)? y

So as you can see, once I got high enough, apparently
no-one else has screwed up those ports.

Kicking off again, and we get a nice run, again:

attempt number 4694: getsockname: rc 0, len 16, listening on 127.0.0.1:65530
attempt number 4695: getsockname: rc 0, len 16, listening on 127.0.0.1:65531
attempt number 4696: getsockname: rc 0, len 16, listening on 127.0.0.1:65532
attempt number 4697: getsockname: rc 0, len 16, listening on 127.0.0.1:65533
attempt number 4698: getsockname: rc 0, len 16, listening on 127.0.0.1:65534
attempt number 4699: getsockname: rc 0, len 16, listening on 127.0.0.1:49157
attempt number 4700: getsockname: rc 0, len 16, listening on 0.0.0.0:49158
address has changed!

C:\devel\develop>goto ff

C:\devel\develop>fishbug
attempt number 1: getsockname: rc 0, len 16, listening on 127.0.0.1:49159
attempt number 2: getsockname: rc 0, len 16, listening on 0.0.0.0:49160
address has changed!


Why do other people have low port numbers?

BFN.  Paul.