if buffer_starting: for subdata in data: print u'DEBUG: reading 2nd subdata' self.account.shelf.set_friend(subdata) print u'DEBUG: deleting 2nd data[:]' del data[:]
The first time del data[:] is called, it works. data is a list as expected in that case. The second time contents of data becomes a dict and we get:
This is always reproducible. I tried adding try/except around del
dict[:] and removing del dict[:] altogether, but then another error
appears at same position:
Had some discussion about this behavior on #python, folks there pondered
on why threads are being used for a twitter client and concluded it's
some kind of race condition. Will be able to help fix this issue as I
have a reproducible test case.
Pasting comment 16 here, it's not available anymore at that link:
Tried properly debugging this time with some tracing:
Around this /bazaar. launchpad. net/~consciousu ser/polly/ unstable/ view/head: /src/polly/ twitter/ realtime. py#L421
https:/
if buffer_starting:
for subdata in data:
print u'DEBUG: reading 2nd subdata'
self. account. shelf.set_ friend( subdata)
print u'DEBUG: deleting 2nd data[:]'
del data[:]
The first time del data[:] is called, it works. data is a list as expected in that case. The second time contents of data becomes a dict and we get:
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: deleting 2nd data[:] <-------------- first call successful
DEBUG: k4rtik connected successfully
DEBUG: reading 2nd subdata python2. 7/threading. py", line 811, in __bootstrap_inner python2. 7/site- packages/ polly/_ _init__ .py", line 241, in run callback( *self.args) python2. 7/site- packages/ polly/twitter/ realtime. py", line 423, in _buffer_loop
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: deleting 2nd data[:] <-------------- second call error
Exception in thread Thread-13:
Traceback (most recent call last):
File "/usr/lib64/
self.run()
File "/usr/lib/
self.
File "/usr/lib/
del data[:]
TypeError: unhashable type
This is always reproducible. I tried adding try/except around del
dict[:] and removing del dict[:] altogether, but then another error
appears at same position:
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: k4rtik connected successfully
DEBUG: reading 2nd subdata python2. 7/threading. py", line 811, in __bootstrap_inner python2. 7/site- packages/ polly/_ _init__ .py", line 241, in run callback( *self.args) python2. 7/site- packages/ polly/twitter/ realtime. py", line 427, in _buffer_loop account. backend. release_ connecting( ) python2. 7/site- packages/ polly/twitter/ account. py", line 1361, in release_connecting connecting_ lock.release( )
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
DEBUG: reading 2nd subdata
Exception in thread Thread-13:
Traceback (most recent call last):
File "/usr/lib64/
self.run()
File "/usr/lib/
self.
File "/usr/lib/
self.
File "/usr/lib/
self.
error: release unlocked lock
Had some discussion about this behavior on #python, folks there pondered
on why threads are being used for a twitter client and concluded it's
some kind of race condition. Will be able to help fix this issue as I
have a reproducible test case.