[Python-Dev] 2.3.1 is (almost) a go

[Tim Peters]

[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.

Running the original hammer.py under current CVS Python freezes in the same
way now.

I added this info to the bug report:

    http://www.python.org/sf/775414