Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash when logging a subscripted None object and unhandled EPIPE exception on OS X #104

Closed
giampaolo opened this issue May 28, 2014 · 12 comments
Closed
Labels
bug Component-Library imported Priority-High Security

Comments

@giampaolo
Copy link
Owner

@giampaolo giampaolo commented May 28, 2014

From wentao....@gmail.com on April 01, 2009 15:32:16

I used pyftpdlib for a programming contest. The contestants uploaded their 
programs via FTP. 
There are about 100 contestants. And here is the output in standard error:

warning: unhandled connect event
warning: unhandled write event
warning: unhandled connect event
warning: unhandled write event
warning: unhandled connect event
warning: unhandled write event
Traceback (most recent call last):
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/asynchat.py", 
line 219, in initiate_send
    num_sent = self.send (self.ac_out_buffer[:obs])
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/asyncore.py", line 
331, in send
    result = self.socket.send(data)
error: (32, 'Broken pipe')

Traceback (most recent call last):
  File "./ftpd.py", line 44, in <module>
    ftpd.serve_forever()
  File "/Users/hanwentao/Documents/Work/thu-cs-gst-2009/ftp/ftpserver.py", line 3106, in 
serve_forever
    poll_fun(timeout, map)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/asyncore.py", line 
132, in poll
    read(obj)
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/asyncore.py", line 
72, in read
    obj.handle_error()
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/asyncore.py", line 
68, in read
    obj.handle_read_event()
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/asyncore.py", line 
384, in handle_read_event
    self.handle_accept()
  File "/Users/hanwentao/Documents/Work/thu-cs-gst-2009/ftp/ftpserver.py", line 3128, in 
handle_accept
    log("[]&#37;s:&#37;s Connected." &#37;addr[:2])
TypeError: 'NoneType' object is unsubscriptable

It seemed that the address accepted by the socket might be None sometimes. And 
this crashed 
the whole server.

I'm using Mac OS X 10.5.6 and Python 2.5.1.

Original issue: http://code.google.com/p/pyftpdlib/issues/detail?id=104

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From billiej...@gmail.com on April 01, 2009 07:24:09

Hi, 

> It seemed that the address accepted by the socket might be 
> None sometimes. And this crashed the whole server.

What pyftpdlib version are you using?
That "None" problem should have already been fixed in 0.5.1 version (see issue 91 ).

> Traceback (most recent call last):
>   File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
> /asynchat.py", 
> line 219, in initiate_send
>     num_sent = self.send (self.ac_out_buffer[:obs])
>   File 
> "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5
> /asyncore.py", line 
> 331, in send
>     result = self.socket.send(data)
> error: (32, 'Broken pipe')

This is strange. I've never seen EPIPE error thrown this way.

> warning: unhandled connect event
> warning: unhandled write event

Those warning messages should have all been suppressed in 0.5.1 version.
I suspect you're using an old version of pyftpdlib.
What worries me more is the EPIPE error. 
Could you please update to the latest version and tell me if EPIPE is still thrown?

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From wentao....@gmail.com on April 01, 2009 08:01:12

No, it's different from issue 91 . The place where the exception was thrown is a few
lines after that in issue 91 . I'm just using version 0.5.1.
According to my experience, the EPIPE error might be caused by the client 
closing the
socket channel improperly. It may be related to the server under heavy load. However,
a well-implemented client will redo the action when this error happens. So I don't
think it's that critical.

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From billiej...@gmail.com on April 01, 2009 09:59:21

Ok, I identified the problem.
It seems that for some strange reason socket.accept() sometimes return:

(sockobj, None)

...instead of:

(sockobj, (ip, port))

This can be reproduced, at least on OS X, by hammering the server with nmap, like this:

> COUNT=0; while [ $COUNT -lt 1000 ]; do nmap -sT -p 21 localhost;
COUNT=$(($COUNT+1)); done

Apparently it seems to be a problem related to OS X only, since I didn't manage to
reproduce this on Linux by using the same cmd line.
Plus, I've found this: https://bugs.launchpad.net/zodb/+bug/135108 Anyway, this 
is now fixed as r556 , so I would recommend you to use that version of
ftpserver.py as long as a new version will be released.


As for the EPIPE problem it would be cool if you could verify whether the problem
persists also after my last commit (I guess it should).

Status: Started
Labels: -OpSys-All OpSys-OSX Version-0.5.1 Milestone-0.5.2

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From billiej...@gmail.com on April 01, 2009 10:03:19

Almost forgot. The warning messages printed on the screen should be suppressed if you
use the latest revision.

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From billiej...@gmail.com on April 01, 2009 18:28:36

The EPIPE issue should be now fixed as r557 .
Since the problem is asyncore related I've also opened a report on the Python bug
tracker: http://bugs.python.org/issue5661

Summary: Crash when logging a subscripted None object and unhandled EPIPE exception on OS X
Status: Finished

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From billiej...@gmail.com on April 02, 2009 08:47:54

Labels: -Priority-Medium Priority-High

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From billiej...@gmail.com on April 02, 2009 08:58:26

Labels: Security

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From billiej...@gmail.com on April 04, 2009 06:42:45

Labels: Crash

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From billiej...@gmail.com on August 29, 2009 10:34:02

Status: FixedInSVN

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From billiej...@gmail.com on September 13, 2009 13:56:15

Status: Fixed

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From billiej...@gmail.com on September 13, 2009 14:01:52

This is now fixed and included as part of 0.5.2 version.

@giampaolo
Copy link
Owner Author

@giampaolo giampaolo commented May 28, 2014

From g.rodola on November 05, 2010 19:03:22

Added a test case which covers this but in r749 .

@giampaolo giampaolo closed this May 28, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Component-Library imported Priority-High Security
Projects
None yet
Development

No branches or pull requests

1 participant