467,925 Members | 1,886 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,925 developers. It's quick & easy.

Uncatchable socket.error in socket.py (?)

Hi,
I've written a very simple 'kill-server' to help me shut down
processes through Telnet or HTTP. The kill-server is a function and is
launched as a thread. I use the module socket.py on Python v2.3
(Windows)

I can use telnet host:port and enter the secret killword or
use a broser with http://host:port/secret_killword

The 'kill-server' validates the secret_killword and writes a file
to /tmp. The main process regularly checks for the existence of that
file, and ends the loop if it does exist.

It works well.

But most for the fun (because this will probably never be
exposed to the net, i think), I started to implement
som basic security.
For instance: I don't want ther server to be easily crashable.

So I've written some try/except blocks to handle irregularities,
but when trying to overflow the receive buffer, I get an exception
in the socket module itself

It says:
|---------------------->
Unhandled exception in thread started by <function spawn_killserver at
0x00B5EEB0>
Traceback (most recent call last):
File "X:\tmp\webcam.py", line 68, in spawn_killserver
connection.send("Nice try mister.")
File "G:\dev\python\lib\socket.py", line 143, in _dummy
raise error(EBADF, 'Bad file descriptor')
socket.error: (9, 'Bad file descriptor')
<----------------------|
Relevant code:
#init SOCKET
sock = socket(AF_INET, SOCK_STREAM)
sock.bind((host, killserver_port))
sock.listen(5)
(blah blah)

connection, address = sock.accept()

try:
buffer = connection.recv(16)
except:
connection.send("Nice try mister.")
connection.close()

So if I use a browser with this in the address field:

http://host:port/500_chars_long_string

I get the execption 'socket.error:'

But if I try to catch it with 'except socket.error:',
I generate a new exception:

AttributeError - _socketobject' has no attribute 'error'

I know I can make the receive buffer bigger, but the point
is to lock that door once and for all.

It seems to me that what happens is that the server crashes,
and that connection.send() no longer have any place to send to.

Now, enough words: What I wonder is: Can I catch that socket.error?

--rune
Jul 18 '05 #1
  • viewed: 5193
Share:
6 Replies
Rune wrote:
Now, enough words: What I wonder is: Can I catch that socket.error?


By not doing

from socket import *

but rather

import socket

(and prefixing your code with "socket." where it's needed).

The socket.error you tried to catch is coming from the socket
object that you placed in your namespace by doing the "from"
import. And the socket class doesn't have an "error" attribute ;)

--Irmen

Jul 18 '05 #2

Irmen de Jong wrote:
Rune wrote:
Now, enough words: What I wonder is: Can I catch that socket.error?


By not doing

from socket import *

but rather

import socket

(and prefixing your code with "socket." where it's needed).

The socket.error you tried to catch is coming from the socket
object that you placed in your namespace by doing the "from"
import. And the socket class doesn't have an "error" attribute ;)


Thanks Irmen, but the problem seems to be that the server is actually
crashed before I can catch the exception. There is no connection to
send output to. I have no idea how to avoid this.

Rune

Jul 18 '05 #3
Rune wrote:
Thanks Irmen, but the problem seems to be that the server is actually
crashed before I can catch the exception. There is no connection to
send output to. I have no idea how to avoid this.


If you catch the error, then the server won't have "crashed," and you'll
be able to recover however you like.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ The most exhausting thing in life is being insincere.
\__/ Anne Morrow Lindbergh
Jul 18 '05 #4
Erik Max Francis wrote:
Rune wrote:
Thanks Irmen, but the problem seems to be that the server is actually
crashed before I can catch the exception. There is no connection to
send output to. I have no idea how to avoid this.


If you catch the error, then the server won't have "crashed," and you'll
be able to recover however you like.


I am able to catch the exception, but thie connection object from
connection, address = sockobj.accept(), is lost.

I cannot connect to the server any longer and connection.send(data)
will generate a new socket.error: (9, 'Bad file descriptor')

I can't find a way out of this but to restart the server.

R

Jul 18 '05 #5
Rune wrote:
I cannot connect to the server any longer and connection.send(data)
will generate a new socket.error: (9, 'Bad file descriptor')


I see; it wasn't entirely clear to me what your complaint was from your
first message. If you're getting an exception when calling recv, the
connection has already dropped. You can't send the message because the
connection isn't there anymore. Catching or not catching an exception
won't change that.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
__ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
/ \ Peace with a cudgel in hand is war.
\__/ (a Portugese proverb)
Jul 18 '05 #6
> > I cannot connect to the server any longer and connection.send(data)
will generate a new socket.error: (9, 'Bad file descriptor')


I see; it wasn't entirely clear to me what your complaint was from your
first message. If you're getting an exception when calling recv, the
connection has already dropped. You can't send the message because the
connection isn't there anymore. Catching or not catching an exception
won't change that.


Guido handles this situation using timemachine exceptions:

try:
communicationcode()
unrecoverable_except socket.error:
alternatecode()

This works as expected. If the communciation code raises an
unrecoverable exception, then time is backed up to just before
the communication code was executed and the alternate code
is run instead.

I believe he intends to incorporate this feature in his next
language, Voyager, which is named after a Star Trek spin-off.
The idea is not really new; it is just an extension of commit/rollback
for socketlike objects where the state (uncrashed) is not easily
restored without access to timemachine hardware.
Raymond Hettinger
Jul 18 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Johannes Eble | last post: by
5 posts views Thread by kingofearth.com | last post: by
7 posts views Thread by | last post: by
2 posts views Thread by darthghandi | last post: by
reply views Thread by Jesper | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.