homepage

Logged In: YES 
user_id=31435
About studly_hammer.py:
[Skip Montanaro]
> ...
> Attached is a modified version of the hammer.py script 
which seems to
> not fail for me on either Windows run from IDLE (Python 
2.3, BDB
> 4.1.6) or Mac OS X (Python CVS, BDB 4.2.1). The original 
script
> failed for me on Windows but not Mac OS X. Can some 
other people for
> whom the original script fails please try it? (I also attached 
it to
> bug #775414.) 
On Win98SE with current Python 2.3.1, it doesn't fail, but it 
never seemed to finish for me either. Staring at WinTop 
showed that the Python process stopped accumulating 
cycles. Can't be killed with Ctrl+C (no visible effect). Can be 
killed with Ctrl+Break.
Dumping
 print "%s %s" % (thread.get_ident(), i)
at the top of the hammer loop showed that the threads get 
through several hundred iterations, then all printing stops.
Attaching to a debug-build Python from the debugger when a 
freeze occurs isn't terribly illuminating. One thread's stack 
shows
_BSDDB_D! __db_win32_mutex_lock + 134 bytes
_BSDDB_D! __lock_get + 2264 bytes
_BSDDB_D! __lock_get + 197 bytes
_BSDDB_D! __ham_get_meta + 120 bytes
_BSDDB_D! __ham_c_dup + 4201 bytes
_BSDDB_D! __db_c_put + 2544 bytes
_BSDDB_D! __db_put + 507 bytes
_DB_put(DBObject * 0x016cff88, __db_txn * 0x016d0000, 
__db_dbt * 0x016cc000, __db_dbt * 0x50d751fe, int 0) line 
562 + 35 bytes
The main thread's stack shows
_BSDDB_D! __db_win32_mutex_lock + 134 bytes
_BSDDB_D! __lock_get + 2264 bytes
_BSDDB_D! __lock_get + 197 bytes
_BSDDB_D! __db_lget + 365 bytes
_BSDDB_D! __ham_lock_bucket + 105 bytes
_BSDDB_D! __ham_get_cpage + 195 bytes
_BSDDB_D! __ham_item_next + 25 bytes
_BSDDB_D! __ham_call_hash + 2479 bytes
_BSDDB_D! __ham_c_dup + 4307 bytes
_BSDDB_D! __db_c_put + 2544 bytes
_BSDDB_D! __db_put + 507 bytes
_DB_put(DBObject * 0x008fe2e8, __db_txn * 0x00000000, 
__db_dbt * 0x0062f230, __db_dbt * 0x0062f248, int 0) line 
562 + 35 bytes
DB_ass_sub(DBObject * 0x008fe2e8, _object * 0x00b83178, 
_object * 0x00b83370) line 2330 + 23 bytes
PyObject_SetItem(_object * 0x008fe2e8, _object * 
0x00b83178, _object * 0x00b83370) line 123 + 18 bytes
eval_frame(_frame * 0x00984948) line 1448 + 17 bytes
...
The other threads are somewhere in the OS kernel and don't 
have useful tracebacks. This varies from run to run, but all 
threads with a useful stack are always stuck at the same 
place in __db_win32_mutex_lock.
All in all, looks like it's simply deadlocked.