Re: socket woes

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

While wrapping up for the day/night/morning, I got
this variation:

02:50:39 console: DBG028: select: An operation was attempted on something that

Which points to a similar problem:

                        /* VERIFY that the file descriptor is valid.
                           If it's NOT, then IGNORE this console device
                           since it's thus obvious that SOMETHING has
                           gone wrong SOMEWHERE at some point! (some
                           sort of race condition SOMEWHERE, obviously)
                        */
                        if (dev->fd < 0)
                        {
                            // Ah-HA! We may have FINALLY found (or at
                            // least have gotten a little bit closer to
                            // finding) the ROOT CAUSE of our problematic
                            // "DBG028 select: Bad FIle Number" problem!
                            logmsg
                            (
                                "\n"
                                "*********** DBG028 CONSOLE BUG ***********\n"
                                "device %4.4X: 'connected', but dev->fd = -1\n"
                                "\n"

                                ,dev->devnum
                            );
                            dev->connected = 0;  // (since it's not connected!)
                        }


Once again, it's hitting similar code:

FD_ZERO ( &readset ); maxfd=INT_MIN;
FD_SET  ( lsock, &readset ); maxfd = lsock;
SUPPORT_WAKEUP_CONSOLE_SELECT_VIA_PIPE( maxfd, &readset );

However, my code didn't get hit:

       sysblk.sockrpipe=fds[0];
       if (sysblk.sockrpipe == -1)
       {
           fprintf(stderr, "gotcha\n");
           exit(0);
       }

on that occasion, nor a second run, but a third run,
it did:

Running on PAUL-LAPTOP Windows_NT-6.0 i686 UP
gotcha

Which basically points the finger back to socketpair,
which I still had debug info in for, which wasn't hit.

So either:

1. debug info (via logmsg) isn't working.

2. Check for INVALID_SOCKET isn't working.

3. the parameters were passed incorrectly.

I can see that the "VERIFY" macro does nothing.

I put in some intensive debug and got this:

fred1
fred2
fred3
fred4
fred5
fred5
fred6
HHCLG009S Syslog message pipe creation failed: No error

The freds were put in after I wasn't getting any
reported error at all, just the "gotcha". I suspect
that the errors are occurring before the logger
thread is ready, so my log debugging wasn't working.

Anyway, the logging error seems to show a general
problem my system has creating sockets. But a
message like the above, with an exit, should be
sufficient safeguard.

The problem is that socketpair is reporting that
sort of error by returning a negative return
code, but it is unchecked, so it's not until
much later that you start getting weird errors.

Solution? Change the VERIFY macro?

More debugging:

fred1
fred2
fred3
fred4
fred5
fred5
fred6
stage3
yaya3

    if (0
        || SOCKET_ERROR   == connect( socket_vector[1], (SOCKADDR*) &loca
        || INVALID_SOCKET == (SOCKET)( socket_vector[0] = accept( temp_li
    )
    {
        int nLastError = (int)WSAGetLastError();
        closesocket( socket_vector[1] );
                     socket_vector[1] = INVALID_SOCKET;
        closesocket( temp_listen_socket );
        errno = nLastError;
        logmsg("stage3\n");
        fprintf(stderr, "yaya3\n");
        exit(0);
        return -1;

Another run:

fred1
fred2
fred3
fred4
fred5
fred5
fred6
yaya3 No error

and you can see the log not working.

    if (0
        || SOCKET_ERROR   == connect( socket_vector[1], (SOCKADDR*) &loc
        || INVALID_SOCKET == (SOCKET)( socket_vector[0] = accept( temp_l
    )
    {
        int nLastError = (int)WSAGetLastError();
        closesocket( socket_vector[1] );
                     socket_vector[1] = INVALID_SOCKET;
        closesocket( temp_listen_socket );
        errno = nLastError;
        logmsg("stage3\n");
        fprintf(stderr, "yaya3 %s\n", strerror(errno));
        exit(0);
        return -1;
    }

More debug:

fred1
fred2
fred3
fred4
fred5
fred5
fred6
fred7
fred8
fred9
fred1
fred2
fred3
fred4
fred5
fred5
fred6
yaya2.5 No error
myflag 0
last 10049
yaya3 No error
        1 file(s) copied.

    if (0
        || SOCKET_ERROR   == connect( socket_vector[1], (SOCKADDR*) &localho
        || ((myflag = 7) != 7)
        || INVALID_SOCKET == (SOCKET)( socket_vector[0] = accept( temp_liste
    )
    {
        int nLastError;
        fprintf(stderr, "yaya2.5 %s\n", strerror(errno));
        fprintf(stderr, "myflag %d\n", myflag);
        nLastError = (int)WSAGetLastError();
        fprintf(stderr, "last %d\n", nLastError);
        closesocket( socket_vector[1] );
                     socket_vector[1] = INVALID_SOCKET;
        closesocket( temp_listen_socket );
        errno = nLastError;
        logmsg("stage3\n");
        fprintf(stderr, "yaya3 %s\n", strerror(errno));

showing that the error is on the connect, and it's
equal to 10049.

/usr/include/w32api/winerror.h:#define WSAEADDRNOTAVAIL 10049L

which according to this documentation I found online:

http://msdn.microsoft.com/en-us/library/ms737625(VS.85).aspx

is suggesting that the name is invalid.

I think it would be odd that my machine is randomly
not having an address available. Is another thread
responsible for creating that IP address?

But the address was available shortly before, right?

Could another thread be shutting it down?

More debugging info needed?

BFN.  Paul.