Re: test_socket.py failure

2005-02-15 Thread x2164
[EMAIL PROTECTED] wrote:

>  hi all,

>  Linux 2.4.28
>  Glibc 2.2.5
>  gcc   2.95.3


>  I'm new to Python.

>  I've compiled Python 2.4 from tar file.

>  When running 'make test' i'm getting a failure
>  in test_socket.

>  Running './python Lib/test/test_socket.py' yields:


> ==
> ERROR: testGetServBy (__main__.GeneralModuleTests)
> --
> Traceback (most recent call last):
>   File "Lib/test/test_socket.py", line 330, in testGetServBy
> port2 = socket.getservbyname(service)
> error: service/proto not found

> --
> Ran 58 tests in 3.826s



>  The value of 'service' was "daytime".

>  After much hand wringing, editing, and use of 'print'
>  statements i commented out line 330,
>  '# port2 = socket.getservbyname(service)' and replaced it
>  with the line 'port2 = port'.

>  Running './python Lib/test/test_socket.py' now yields:


> testGetServBy (__main__.GeneralModuleTests) ... ok
>.
>.
>.
> --
> Ran 58 tests in 5.181s

> OK

>  
>  Located the code for 'socket_getservbyname' in 
>  'Modules/socketmodule.c' where the call to the glibc
>  function 'getservbyname' is made: 

>  Py_BEGIN_ALLOW_THREADS
>  sp = getservbyname(name, proto);
>  Py_END_ALLOW_THREADS
>  if (sp == NULL) {
>  PyErr_SetString(socket_error, "service/proto not found");
>  return NULL;
>  }

>  
>  The only call of socket.getservbyname that failed was when
>  it was passed the single argument.  Since the error message
>  "service/proto not found" seems to only be generated upon
>  failure of gibc's 'getservbyname' could it be that 
>  'PyArg_ParseTuple(args, "s|s:getservbyname", &name, &proto)'
>  generates values for 'name' and/or 'proto' that cause the
>  failure?

>  My search for prior reports of failure at line 330 found
>  a mention of problems at line 331.

>  Well, at any rate, if someone could point me down the 
>  correct path on this i would appreciate it.


>  pete jordan
>  x2164 -> mailcity.com
>  -> equals at symbol



>
> http://www.die.net/doc/linux/man/man3/getservbyname.3.html
>

 The above link was provide by Nick Coghlan. 

 Thanks Nick.

 Well if the man page says it, then it must be so.

 By way of follow up i wanted to let you know that i think
 i've found the reason why i was getting the getservbyname
 behaviour that i described.

 In my /etc/nsswitch.conf file the original line for
 scanning the /etc/services file was:

 services:   nisplus [NOTFOUND=return] db files

 The nisplus module was being used first to scan the file
 and it apparently returns 'NOTFOUND' when proto is NULL.
 '[NOTFOUND=return]' then stops any of the other two
 services, 'db' and 'files', from being used to scan 
 the 'services' file.  I changed the 'services:' line to:

 services:   nisplus db files

 and now if proto is NULL the first line in the 'services' 
 file, matching the service argument passed to 
 getservbyname, is passed back.  This seems to be consistent 
 behaviour with the man page link above.

 I'm not sure removing '[NOTFOUND=return] ' is 100% 
 correct but from information in the libc info page i 
 think it will do.

 Later i'll post this as a followup to comp.lang.python 
 thread in case someone else might have the problem.

 Thanks for the help.


 pete jordan
 x2164 AT mailcity com



-- 
http://mail.python.org/mailman/listinfo/python-list


Re: test_socket.py failure

2005-02-04 Thread x2164
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >  Marc, it is possible that there was a change between 
> >  glibc-2.2.4 and 2.2.5 that would account for the 
> >  difference in behaviour.  I think i'll write a little
> >  test program in C to check out getservbyname's return
> >  values in a little more controled environment.  I'll
> >  post the results tomorrow.

> The other question is which C library Python is actually
> using on your system. 
> Maybe it's picking up whatever installed the funky man page
> which doesn't 
> mention NULL proto arguments.

> So, find your Python 2.4 binary and run "ldd python24" to
> see which shared C 
> library it is linking to.

> For me, it's /lib/tls/libc.so.6. Running that library directly
> prints out the 
> message about GNU C library 2.3.3.


 hey Nick,


 The man pages are probably from orignal system installation
 so i used your ldd technique which says that the python
 executable was compiled against glibc-2.2.5.

 I'm going to check the diff for 2.2.4-2.2.5 and look for
 anything getservbyname related.

 Below i'm including the source code for a little
 program to exercise getservbyname.  On this system
 if 'NULL' is passed as the protocal then 'NULL' is
 returned.

 I wonder if writing some code around the call to
 getservbyname in Modules/socketmodule.c to test
 for a call with the NULL argument would be
 appropriate.  Could you show the output from my
 included program when NULL is passed as
 an argument?  Probably would be good to know
 what the call returns on your system before
 trying to get mine to mimic it.


 Ok, back to grep'ing.


 pete jordan
 x2164 mailcity com






/*
 *This program just test what happens when getservbyname
 *is passed a NULL pointer argument for the name and proto
 *paramenters.
 * 
 *The compilation line i used:
 *
 *gcc getserv.c -o getserv
 *
 *and just type 'getserv' at a prompt.
 *
 *Just pass 'service name, protocol name' to
 *'get_print' to check if combination is found.
 */


#include 
#include 
#include 


void get_print( const char *, const char * );

int main()
{
get_print( "daytime", "tcp" );
get_print( "daytime", "udp" );
get_print( "daytime", NULL );
get_print( NULL, "tcp" );
get_print( NULL, NULL );
get_print( "ithkl", "tcp" );
get_print( "echo", "ddp" );

return ;
}



void get_print( const char *name, const char *proto )
{
struct servent*result = NULL ;

result = getservbyname( name, proto );

printf( "\n  getservbyname call:  getservbyname( %s , %s ) \n",
 name, proto ); 

printf("  getservbyname returned:\n");

if ( result == NULL )
   printf("\t\t\t   NULL - end of 'services' file reached or\n"
  "\t\t\t  error occured.\n\n");
   else
 {
   printf( "\t\t\t   s_name = %s \n", result->s_name );
   printf( "\t\t\t   s_port = %d \n", ntohs(result->s_port) );
   printf( "\t\t\t   s_proto = %s \n", result->s_proto );
   printf( "\n" );
  }

}

-- 
http://mail.python.org/mailman/listinfo/python-list


Re: test_socket.py failure

2005-02-03 Thread Nick Coghlan
[EMAIL PROTECTED] wrote:
 Marc, it is possible that there was a change between 
 glibc-2.2.4 and 2.2.5 that would account for the 
 difference in behaviour.  I think i'll write a little
 test program in C to check out getservbyname's return
 values in a little more controled environment.  I'll
 post the results tomorrow.
The other question is which C library Python is actually using on your system. 
Maybe it's picking up whatever installed the funky man page which doesn't 
mention NULL proto arguments.

So, find your Python 2.4 binary and run "ldd python24" to see which shared C 
library it is linking to.

For me, it's /lib/tls/libc.so.6. Running that library directly prints out the 
message about GNU C library 2.3.3.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list


Re: test_socket.py failure

2005-02-02 Thread x2164
Marc Christiansen <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Nick Coghlan <[EMAIL PROTECTED]> wrote:
> >> Hmm, when the second argument is omitted, the system call looks like:
> >> 
> >> getservbyname("daytime", NULL);
> >> 
> >> Based on "man getservbyname" on my Linux PC, that should give
> >> the behaviour we 
> >> want - any protocol will match.
> >> 
> >> However:
> >> 
> >> Linux 2.6.4-52-default (Suse 9.1)
> >> Glibc 2.3.3
> >> gcc   3.3.3
> >> 
> >> So it may be that your older platform doesn't have this
> >> behaviour - I'd be very 
> >> interested in what 'man getservbyname' has to say.
> > 
> >Just took a look at the man page for getservbyname on this
> >system and it doesn't mention passing NULL as the second
> >argument.  The pertinents: ;-)
> > 
> >Linux kernel 2.6.10
> >Glibc 2.2.5
> >gcc   2.95.3

> Just to confuse the matter more, on my system the man page mentions
> passing NULL as the second argument and it works. Alas:
> SuSE 7.3
> Kernel 2.4.29 (vanilla)
> Glibc  2.2.4 (older than yours)
> gcc2.95.3

> >I'd say your probably right about there being a difference
> >in the behaviour of getservbyname between libc 2.2.5 and 
> >and libc-2.3.3 given the differences in man pages and 
> >observed return values. I'll try and compare the libcs'
> >getservbyname codes and let you know a little later in 
> >the day.
> > 
> >I wonder if the developers wanted to tie the python source
> >code so closely to a glibc version and possibly gnu-libc
> >specific?

> Perhaps SuSE did patch the glibc...

> Saluton
>   Marc



 hey Marc


 Oh man, not another problem that's just happening to
 me, again. :-)

 We all are still talking about python 2.4 aren't we?  I'm
 really running out of options on this.

 My manual page for getservbyname is dated "22 April 1996"
 and i think that it wasn't installed by glibc-2.2.5.  The
 info page for getservbyname which was installed by 2.2.5
 doesn't mention being able to pass NULL as a 'PROTO'
 argument.

 As for my saying above that i would take a look at the
 libcs' code for getservbyname, well, let's just say
 i won't be bantering about that idea so readily anytime
 soon. :-)

 What i believe happens in glibc-2.3.3 is that getservbyname
 is generated by two files: inet/getsrvbynm.c which contains
 a number of '#define's that then '#include's the file 
 nss/getXXbyYY.c which is sort of a template function that
 the '#define's fill out.  If your use to reading it
 nss/getXXbyYY.c probably is easy reading, but, for ego's sake,
 let's just say that i'm not use to reading it.  There's
 also  getsrvbynm_r.c and getXXbyYY_r.c for the reentrant
 versions of getservbyname plus some references to nss and
 nis versions of getservbyname.  Of course its also possilble
 that where i said "What i believe happens" at the beginning
 of this paragraph could be read as "I'm confused about what
 happens" and i don't mean that as critic of glibc.

 Marc, it is possible that there was a change between 
 glibc-2.2.4 and 2.2.5 that would account for the 
 difference in behaviour.  I think i'll write a little
 test program in C to check out getservbyname's return
 values in a little more controled environment.  I'll
 post the results tomorrow.

 
 pete jordan
 x2164   mailcity com


 

-- 


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: test_socket.py failure

2005-02-02 Thread Marc Christiansen
[EMAIL PROTECTED] wrote:
> Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> Hmm, when the second argument is omitted, the system call looks like:
>> 
>> getservbyname("daytime", NULL);
>> 
>> Based on "man getservbyname" on my Linux PC, that should give
>> the behaviour we 
>> want - any protocol will match.
>> 
>> However:
>> 
>> Linux 2.6.4-52-default (Suse 9.1)
>> Glibc 2.3.3
>> gcc   3.3.3
>> 
>> So it may be that your older platform doesn't have this
>> behaviour - I'd be very 
>> interested in what 'man getservbyname' has to say.
> 
>Just took a look at the man page for getservbyname on this
>system and it doesn't mention passing NULL as the second
>argument.  The pertinents: ;-)
> 
>Linux kernel 2.6.10
>Glibc 2.2.5
>gcc   2.95.3

Just to confuse the matter more, on my system the man page mentions
passing NULL as the second argument and it works. Alas:
SuSE 7.3
Kernel 2.4.29 (vanilla)
Glibc  2.2.4 (older than yours)
gcc2.95.3

>I'd say your probably right about there being a difference
>in the behaviour of getservbyname between libc 2.2.5 and 
>and libc-2.3.3 given the differences in man pages and 
>observed return values. I'll try and compare the libcs'
>getservbyname codes and let you know a little later in 
>the day.
> 
>I wonder if the developers wanted to tie the python source
>code so closely to a glibc version and possibly gnu-libc
>specific?

Perhaps SuSE did patch the glibc...

Saluton
  Marc
-- 
http://mail.python.org/mailman/listinfo/python-list


Re: test_socket.py failure

2005-02-02 Thread x2164
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >  At the interactive python prompt i did/got the following:
> > 
> >   bash-2.04$ ./python 
> >   Python 2.4 (#1, Jan 29 2005, 10:31:35) 
> >   [GCC 2.95.3 20010315 (release)] on linux2
> >   Type "help", "copyright", "credits" or "license" for 
> >  more information.
> >   >>> import socket
> >   >>> socket.getservbyname('daytime', 'tcp')
> >   13
> >   
> ># The 13 looks ok but look what happen 
> ># when i asked only for the service, like
> ># the line that fails in test_socket.
> >   
> >   >>> socket.getservbyname('daytime')   
> >   Traceback (most recent call last):
> > File "", line 1, in ?
> >   socket.error: service/proto not found
> >   >>>

> Hmm, when the second argument is omitted, the system call looks like:

> getservbyname("daytime", NULL);

> Based on "man getservbyname" on my Linux PC, that should give
> the behaviour we 
> want - any protocol will match.

> However:

> Linux 2.6.4-52-default (Suse 9.1)
> Glibc 2.3.3
> gcc   3.3.3

> So it may be that your older platform doesn't have this
> behaviour - I'd be very 
> interested in what 'man getservbyname' has to say.

> Cheers,
> Nick.

> -- 
> Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
> ---
>  http://boredomandlaziness.skystorm.net

hey Nick,

Just took a look at the man page for getservbyname on this
system and it doesn't mention passing NULL as the second
argument.  The pertinents: ;-)

Linux kernel 2.6.10
Glibc 2.2.5
gcc   2.95.3

I'd say your probably right about there being a difference
in the behaviour of getservbyname between libc 2.2.5 and 
and libc-2.3.3 given the differences in man pages and 
observed return values. I'll try and compare the libcs'
getservbyname codes and let you know a little later in 
the day.

I wonder if the developers wanted to tie the python source
code so closely to a glibc version and possibly gnu-libc
specific?

   
pete jordan
x2164 at mailcityDOTcom
miami, florida


-- 


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: test_socket.py failure

2005-02-01 Thread Nick Coghlan
[EMAIL PROTECTED] wrote:
 At the interactive python prompt i did/got the following:
	bash-2.04$ ./python 
	Python 2.4 (#1, Jan 29 2005, 10:31:35) 
	[GCC 2.95.3 20010315 (release)] on linux2
	Type "help", "copyright", "credits" or "license" for 
	   more information.
	>>> import socket
	>>> socket.getservbyname('daytime', 'tcp')
	13
	
	 # The 13 looks ok but look what happen 
	 # when i asked only for the service, like
	 # the line that fails in test_socket.
	
	>>> socket.getservbyname('daytime')   
	Traceback (most recent call last):
	  File "", line 1, in ?
	socket.error: service/proto not found
	>>>
Hmm, when the second argument is omitted, the system call looks like:
getservbyname("daytime", NULL);
Based on "man getservbyname" on my Linux PC, that should give the behaviour we 
want - any protocol will match.

However:
Linux 2.6.4-52-default (Suse 9.1)
Glibc 2.3.3
gcc   3.3.3
So it may be that your older platform doesn't have this behaviour - I'd be very 
interested in what 'man getservbyname' has to say.

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list


Re: test_socket.py failure

2005-01-31 Thread x2164
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >  hi all,
> > 
> >  Linux 2.4.28
> >  Glibc 2.2.5
> >  gcc   2.95.3
> > 
> > 
> >  I'm new to Python.
> > 
> >  I've compiled Python 2.4 from tar file.
> > 
> >  When running 'make test' i'm getting a failure
> >  in test_socket.
> > 

> Two questions. First, what does the following code give 
> when you run it at the 
> interactive prompt?:

> Py> import socket
> Py> socket.getservbyname('daytime')
> 13

> Second, is there an entry for 'daytime' in /etc/services?

> Cheers,
> Nick.

> -- 
> Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
> ---
>  http://boredomandlaziness.skystorm.net



 hi Nick,


 At the interactive python prompt i did/got the following:

bash-2.04$ ./python 
Python 2.4 (#1, Jan 29 2005, 10:31:35) 
[GCC 2.95.3 20010315 (release)] on linux2
Type "help", "copyright", "credits" or "license" for 
   more information.
>>> import socket
>>> socket.getservbyname('daytime', 'tcp')
13

 # The 13 looks ok but look what happen 
 # when i asked only for the service, like
 # the line that fails in test_socket.

>>> socket.getservbyname('daytime')   
Traceback (most recent call last):
  File "", line 1, in ?
socket.error: service/proto not found
>>>

 From my /etc/services file:

daytime 13/tcp
daytime 13/udp


I was trying to use gdb to watch the function 
socket_getservbyname, from Modules/socketmodule.c, 
execute but i'm not sure how to set the gdb 'break' for 
a function in a module that isn't imported at the time 
i start python in gdb.

Hints welcome. ;-)


pete jordan
x2164 at
mail.city


-- 


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: test_socket.py failure

2005-01-31 Thread Nick Coghlan
[EMAIL PROTECTED] wrote:
 hi all,
 Linux 2.4.28
 Glibc 2.2.5
 gcc   2.95.3
 I'm new to Python.
 I've compiled Python 2.4 from tar file.
 When running 'make test' i'm getting a failure
 in test_socket.
Two questions. First, what does the following code give when you run it at the 
interactive prompt?:

Py> import socket
Py> socket.getservbyname('daytime')
13
Second, is there an entry for 'daytime' in /etc/services?
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list


Re: test_socket.py failure

2005-01-30 Thread x2164
Steve Holden <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> >  hi all,
> > 
> >  Linux 2.4.28
> >  Glibc 2.2.5
> >  gcc   2.95.3
> > 
> > 
> >  I'm new to Python.
> > 
> >  I've compiled Python 2.4 from tar file.
> > 
> >  When running 'make test' i'm getting a failure
> >  in test_socket.
> > 
> >  Running './python Lib/test/test_socket.py' yields:
> > 
> > 
> > ==
> > ERROR: testGetServBy (__main__.GeneralModuleTests)
> > --
> > Traceback (most recent call last):
> >   File "Lib/test/test_socket.py", line 330, in testGetServBy
> > port2 = socket.getservbyname(service)
> > error: service/proto not found
> > 
> > --
> > Ran 58 tests in 3.826s
> > 
> > 
> > 
> >  The value of 'service' was "daytime".
> > 
> >  After much hand wringing, editing, and use of 'print'
> >  statements i commented out line 330,
> >  '# port2 = socket.getservbyname(service)' and replaced it
> >  with the line 'port2 = port'.
> > 
> >  Running './python Lib/test/test_socket.py' now yields:
> > 
> > 
> > testGetServBy (__main__.GeneralModuleTests) ... ok
> >.
> >.
> >.
> > --
> > Ran 58 tests in 5.181s
> > 
> > OK
> > 
> >  
> >  Located the code for 'socket_getservbyname' in 
> >  'Modules/socketmodule.c' where the call to the glibc
> >  function 'getservbyname' is made: 
> > 
> >  Py_BEGIN_ALLOW_THREADS
> >  sp = getservbyname(name, proto);
> >  Py_END_ALLOW_THREADS
> >  if (sp == NULL) {
> >PyErr_SetString(socket_error, "service/proto not found");
> >return NULL;
> >  }
> > 
> >  
> >  The only call of socket.getservbyname that failed was when
> >  it was passed the single argument.  Since the error message
> >  "service/proto not found" seems to only be generated upon
> >  failure of gibc's 'getservbyname' could it be that 
> >  'PyArg_ParseTuple(args, "s|s:getservbyname", &name, &proto)'
> >  generates values for 'name' and/or 'proto' that cause the
> >  failure?
> > 
> >  My search for prior reports of failure at line 330 found
> >  a mention of problems at line 331.
> > 
> >  Well, at any rate, if someone could point me down the 
> >  correct path on this i would appreciate it.
> > 
> Compiling from source requires you to indicate the features that you 
> want compiled in. Without thread support, sockets din't work, so it 
> looks like you need to configure threads in. IIRC you do this by editing 
> the Modules.? file.

> regards
>   Steve

hi Steve,

Here's a cut down version of the compilation line for
socketmodule.c which contains the 'socket_getservbyname'
code:

 gcc -pthread -DNDEBUG ... 
 -c /usr/src/Python-2.4/Modules/socketmodule.c
 -o build/temp.linux-i686-2.4/socketmodule.o

Is '-pthread' the type of thread i need?

I'm still curious why only the call with one argument to
'socket.getservbyname' fails while the two other calls
which pass two arguments don't fail.

Any ideas?


pete jordan
x2164 at
mailcity com



-- 


-- 
http://mail.python.org/mailman/listinfo/python-list


Re: test_socket.py failure

2005-01-30 Thread Steve Holden
[EMAIL PROTECTED] wrote:
 hi all,
 Linux 2.4.28
 Glibc 2.2.5
 gcc   2.95.3
 I'm new to Python.
 I've compiled Python 2.4 from tar file.
 When running 'make test' i'm getting a failure
 in test_socket.
 Running './python Lib/test/test_socket.py' yields:
==
ERROR: testGetServBy (__main__.GeneralModuleTests)
--
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 330, in testGetServBy
port2 = socket.getservbyname(service)
error: service/proto not found
--
Ran 58 tests in 3.826s

 The value of 'service' was "daytime".
 After much hand wringing, editing, and use of 'print'
 statements i commented out line 330,
 '# port2 = socket.getservbyname(service)' and replaced it
 with the line 'port2 = port'.
 Running './python Lib/test/test_socket.py' now yields:
testGetServBy (__main__.GeneralModuleTests) ... ok
   .
   .
   .
--
Ran 58 tests in 5.181s
OK
 
 Located the code for 'socket_getservbyname' in 
 'Modules/socketmodule.c' where the call to the glibc
 function 'getservbyname' is made: 

 Py_BEGIN_ALLOW_THREADS
 sp = getservbyname(name, proto);
 Py_END_ALLOW_THREADS
 if (sp == NULL) {
 PyErr_SetString(socket_error, "service/proto not found");
 return NULL;
 }
 
 The only call of socket.getservbyname that failed was when
 it was passed the single argument.  Since the error message
 "service/proto not found" seems to only be generated upon
 failure of gibc's 'getservbyname' could it be that 
 'PyArg_ParseTuple(args, "s|s:getservbyname", &name, &proto)'
 generates values for 'name' and/or 'proto' that cause the
 failure?

 My search for prior reports of failure at line 330 found
 a mention of problems at line 331.
 Well, at any rate, if someone could point me down the 
 correct path on this i would appreciate it.

Compiling from source requires you to indicate the features that you 
want compiled in. Without thread support, sockets din't work, so it 
looks like you need to configure threads in. IIRC you do this by editing 
the Modules.? file.

regards
 Steve
--
http://mail.python.org/mailman/listinfo/python-list


test_socket.py failure

2005-01-30 Thread x2164

 hi all,

 Linux 2.4.28
 Glibc 2.2.5
 gcc   2.95.3


 I'm new to Python.

 I've compiled Python 2.4 from tar file.

 When running 'make test' i'm getting a failure
 in test_socket.

 Running './python Lib/test/test_socket.py' yields:


==
ERROR: testGetServBy (__main__.GeneralModuleTests)
--
Traceback (most recent call last):
  File "Lib/test/test_socket.py", line 330, in testGetServBy
port2 = socket.getservbyname(service)
error: service/proto not found

--
Ran 58 tests in 3.826s



 The value of 'service' was "daytime".

 After much hand wringing, editing, and use of 'print'
 statements i commented out line 330,
 '# port2 = socket.getservbyname(service)' and replaced it
 with the line 'port2 = port'.

 Running './python Lib/test/test_socket.py' now yields:


testGetServBy (__main__.GeneralModuleTests) ... ok
   .
   .
   .
--
Ran 58 tests in 5.181s

OK

 
 Located the code for 'socket_getservbyname' in 
 'Modules/socketmodule.c' where the call to the glibc
 function 'getservbyname' is made: 

 Py_BEGIN_ALLOW_THREADS
 sp = getservbyname(name, proto);
 Py_END_ALLOW_THREADS
 if (sp == NULL) {
 PyErr_SetString(socket_error, "service/proto not found");
 return NULL;
 }

 
 The only call of socket.getservbyname that failed was when
 it was passed the single argument.  Since the error message
 "service/proto not found" seems to only be generated upon
 failure of gibc's 'getservbyname' could it be that 
 'PyArg_ParseTuple(args, "s|s:getservbyname", &name, &proto)'
 generates values for 'name' and/or 'proto' that cause the
 failure?

 My search for prior reports of failure at line 330 found
 a mention of problems at line 331.

 Well, at any rate, if someone could point me down the 
 correct path on this i would appreciate it.


 pete jordan
 x2164 -> mailcity.com
 -> equals at symbol




-- 


-- 
http://mail.python.org/mailman/listinfo/python-list