Anamoly with ioctl() in cygwin 1.7.10

Anamoly with ioctl() in cygwin 1.7.10

[Lee Collier]

Hello,

I'm new to cygwin and ran into an anamoly with calling ioctl() that
I've not experienced on Linux. It appears that ioctl() behaves as
expected when it is called from the main thread; however, it does not
when called from a thread created by the main thread. Is this expected
behavior when using cygwin?

I've added a sample program to demonstrate the anomaly. The call to
listInterfaces() from main() will function properly. The call to
listInterfaces() from handlePackets() will fail at ioctl(sck,
SIOCGIFCONF, &ifc); however, the errno result reported by perror is
"No error".

Regards,
LC

#include <sys/ioctl.h>
#include <net/if.h>
#include <netinet/in.h>
#include <stdio.h>
#include <arpa/inet.h>
#include <pthread.h>

int listInterfaces(void);
void* handlePackets (void* data);

int main(void)
{
   pthread_t pktHandlerThreadId;
   pthread_mutex_t pktMutex;

   printf("Result from main thread:\n");
   listInterfaces();
   pthread_mutex_lock(&pktMutex);
   pthread_create(&pktHandlerThreadId, NULL, &handlePackets, &pktMutex);
   pthread_mutex_unlock(&pktMutex);
   pthread_join(pktHandlerThreadId, NULL); //Wait until Event Handler
thread exits..
   printf("\nProgram is exiting.\n");
   return 0;
}


void * handlePackets(void* data)
{
  	pthread_mutex_t *pktMutex;
  	pktMutex = (pthread_mutex_t *)data;
  	pthread_mutex_lock(pktMutex);
  	printf("\nResult from packet handler thread:\n");
  	pktMutex = (pthread_mutex_t *)data;
    listInterfaces();
  	pthread_mutex_unlock(pktMutex);
    return NULL;
}

int listInterfaces(void)
{
	int retVal =0;
    /*
      Example code to obtain IP and MAC for all available interfaces on Linux.
      by Adam Pierce <adam@doctort.org>

    http://www.doctort.org/adam/
    */
    char          buf[1024];
    struct ifconf ifc;
    struct ifreq *ifr;
    int           sck;
    int           nInterfaces;
    int           i;

    /* Get a socket handle. */
    sck = socket(AF_INET, SOCK_DGRAM, 0);
    if(sck < 0)
    {
    	perror("socket");
    	return -1;
    }

    /* Query available interfaces. */
    ifc.ifc_len = sizeof(buf);
    ifc.ifc_buf = buf;
    if(ioctl(sck, SIOCGIFCONF, &ifc) < 0)
    {
    	perror("ioctl(SIOCGIFCONF)");
		return -1;
    }

    /* Iterate through the list of interfaces. */
    ifr         = ifc.ifc_req;
    nInterfaces = ifc.ifc_len / sizeof(struct ifreq);
    for(i = 0; i < nInterfaces; i++)
    {
    	struct ifreq *item = &ifr[i];
		/* Show the device name and IP address */
		printf("%s: IP %s",
			   item->ifr_name,
			   inet_ntoa(((struct sockaddr_in *)&item->ifr_addr)->sin_addr));

		/* Get the MAC address */
		if(ioctl(sck, SIOCGIFHWADDR, item) < 0)
		{
			perror("ioctl(SIOCGIFHWADDR)");
			return -1;
		}

		/* Get the broadcast address (added by Eric) */
		if(ioctl(sck, SIOCGIFBRDADDR, item) >= 0)
				printf(", BROADCAST %s", inet_ntoa(((struct sockaddr_in
*)&item->ifr_broadaddr)->sin_addr));
		printf("\n");
    }
	return retVal;
}

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Anamoly with ioctl() in cygwin 1.7.10

[Jon Clugston]

On Wed, Mar 7, 2012 at 1:51 PM, Lee Collier wrote:
> Hello,
>
> I'm new to cygwin and ran into an anamoly with calling ioctl() that
> I've not experienced on Linux. It appears that ioctl() behaves as
> expected when it is called from the main thread; however, it does not
> when called from a thread created by the main thread. Is this expected
> behavior when using cygwin?
>
> I've added a sample program to demonstrate the anomaly. The call to
> listInterfaces() from main() will function properly. The call to
> listInterfaces() from handlePackets() will fail at ioctl(sck,
> SIOCGIFCONF, &ifc); however, the errno result reported by perror is
> "No error".
>
> Regards,
> LC
>
> #include <sys/ioctl.h>
> #include <net/if.h>
> #include <netinet/in.h>
> #include <stdio.h>
> #include <arpa/inet.h>
> #include <pthread.h>
>
> int listInterfaces(void);
> void* handlePackets (void* data);
>
> int main(void)
> {
>   pthread_t pktHandlerThreadId;
>   pthread_mutex_t pktMutex;
>
>   printf("Result from main thread:\n");
>   listInterfaces();
>   pthread_mutex_lock(&pktMutex);

Don't know if it will fix your problem, but you cannot just create a
mutex on the stack and call "lock" on it.  You must initialize it with
"pthread_mutex_init()".



Jon

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Anamoly with ioctl() in cygwin 1.7.10

[Lee Collier]

Jon Clugston <jon.clugston <at> gmail.com> writes:
> 
> Don't know if it will fix your problem, but you cannot just create a
> mutex on the stack and call "lock" on it.  You must initialize it with
> "pthread_mutex_init()".
> 
> Jon
> 
> 
Good catch. I missed that in my haste to scrounge a sample pgm together. With or 
w/out initializing the mutex the anomaly still occurs.

LC




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Anamoly with ioctl() in cygwin 1.7.10

[Corinna Vinschen]

On Mar  8 01:35, Lee Collier wrote:
> Jon Clugston <jon.clugston <at> gmail.com> writes:
> > 
> > Don't know if it will fix your problem, but you cannot just create a
> > mutex on the stack and call "lock" on it.  You must initialize it with
> > "pthread_mutex_init()".
> > 
> > Jon
> > 
> > 
> Good catch. I missed that in my haste to scrounge a sample pgm together. With or 
> w/out initializing the mutex the anomaly still occurs.

You're trying this on a 64 bit machine, right?  Call `peflags -l0' on
your executable and try again.  It should work.

This is terribly annoying.  While the executables are large address aware,
the operating system apparently is not!

What happens is that the function GetAdaptersAddresses fails, because
it's running on a thread stack in the large address area.  It doesn't
matter if the addresses given to the function are in the large address
area or not.  It's sufficent that the stack is there.  I'm not holy
myself, but this is really, really bad programming.  Grrr.

But that doesn't help, of course.  I'll try to come up with a solution.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Anamoly with ioctl() in cygwin 1.7.10

[Corinna Vinschen]

On Mar  8 11:33, Corinna Vinschen wrote:
> On Mar  8 01:35, Lee Collier wrote:
> > Jon Clugston <jon.clugston <at> gmail.com> writes:
> > > 
> > > Don't know if it will fix your problem, but you cannot just create a
> > > mutex on the stack and call "lock" on it.  You must initialize it with
> > > "pthread_mutex_init()".
> > > 
> > > Jon
> > > 
> > > 
> > Good catch. I missed that in my haste to scrounge a sample pgm together. With or 
> > w/out initializing the mutex the anomaly still occurs.
> 
> You're trying this on a 64 bit machine, right?  Call `peflags -l0' on
> your executable and try again.  It should work.
> 
> This is terribly annoying.  While the executables are large address aware,
> the operating system apparently is not!
> 
> What happens is that the function GetAdaptersAddresses fails, because
> it's running on a thread stack in the large address area.  It doesn't
> matter if the addresses given to the function are in the large address
> area or not.  It's sufficent that the stack is there.  I'm not holy
> myself, but this is really, really bad programming.  Grrr.
> 
> But that doesn't help, of course.  I'll try to come up with a solution.

Well, I think I have a solution now.  I applied a patch to CVS and
I'm just generating a new developer snapshot.  Please give the today's
snapshot from http://cygwin.com/snapshots/ a try.

Oh, and, thanks for the report and the testcase.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Anamoly with ioctl() in cygwin 1.7.10

[Lee Collier]

Corinna Vinschen <corinna-cygwin <at> cygwin.com> writes:

> 
> On Mar  8 11:33, Corinna Vinschen wrote: 
> > You're trying this on a 64 bit machine, right?  Call `peflags -l0' on
> > your executable and try again.  It should work.
>
> 
> Well, I think I have a solution now.  I applied a patch to CVS and
> I'm just generating a new developer snapshot.  Please give the today's
> snapshot from http://cygwin.com/snapshots/ a try.
> 
> Oh, and, thanks for the report and the testcase.
> 
> Corinna
> 

No problem. Thanks for your assistance. I am using a 64-bit machine and your 
'peflags -l0' suggestion fixed the problem. I'll give the snapshot a try as well 
and report back.

LC





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Anamoly with ioctl() in cygwin 1.7.10

[Lee Collier]

The problem is resolved in the snapshot as well. Thanks again.
LC





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple