test_socket.py failure

[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

 

[Steve Holden]

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

 

[x2164]

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

 

[Nick Coghlan]

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.

 

[x2164]

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?

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 "<stdin>", 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

 

[Nick Coghlan]

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 "<stdin>", 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.

 

[x2164]

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):

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.

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.

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

 

[Marc Christiansen]

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)
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?

Perhaps SuSE did patch the glibc...

Saluton
Marc

 

[x2164]

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)
gcc 2.95.3

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

 

[Nick Coghlan]

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.

 

[x2164]

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 <stdio.h>
#include <netdb.h>
#include <netinet/in.h>


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" );
}

}

 

[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


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