[tahoe-dev] [tahoe-lafs] #807: exceptions.OverflowError: join() result is too long for a Python string

[tahoe-lafs]

#807: exceptions.OverflowError: join() result is too long for a Python string
--------------------+-------------------------------------------------------
 Reporter:  zooko   |           Owner:  warner   
     Type:  defect  |          Status:  new      
 Priority:  major   |       Milestone:  undecided
Component:  code    |         Version:  1.3.0    
 Keywords:          |   Launchpad_bug:           
--------------------+-------------------------------------------------------
Changes (by zooko):

  * owner:  somebody => warner


Comment:

 http://svn.python.org/view/python/tags/r252/Objects/stringobject.c?revision=60915&view=markup

 Search in text for "join() result is too long for a Python string".  It is
 guarded by {{{if (sz < old_sz || sz > PY_SSIZE_T_MAX)}}}.
 {{{PY_SSIZE_T_MAX}}} is defined in
 http://svn.python.org/view/python/tags/r252/Include/pyport.h?revision=60915&view=markup
 to be {{{((size_t)-1)>>1}}} which would be {{{2,147,483,647}}} on that
 platform.  So, I guess we were trying to {{{.join()}}} together a string
 that would have been more than 2.1 billion bytes.

 I don't see how to investigate this, reproduce it, or determine if it has
 been fixed in newer versions of Tahoe-LAFS.  One of the reasons why not is
 that the exception raised by the selectreactor's {{{_doReadOrWrite()}}}
 apparently didn't get propagated to foolscap, because no accompanying
 incident report file was generated.

 Brian: am I interpreting that correctly?  Is there a way to make sure that
 all unhandled exceptions get registered with the foolscap logging system
 so that they can be reported as incidents?  Do you have any other ideas
 how to learn more about this issue, or should we just close it as
 "wontfix"?

-- 
Ticket URL: <http://allmydata.org/trac/tahoe/ticket/807#comment:2>
tahoe-lafs <http://allmydata.org>
secure decentralized file storage grid