[GRASS-dev] Some progress on Win32 attribute deadlock problem

[Glynn Clements]

Benjamin Ducke wrote:

> Next, I put some attribute handling code back in bit by bit to see when
> the trouble would start again. It did not take long. Basically, managing
> SQL strings with db_init_string and db_set_string works fine, but as
> soon as the attribute database is queried (using db_open_select_cursor),
> the lockups come back in full number!
> 
> SUMMARY
> 
> * The problem does not originate in a specific DB driver (such as
> DBF.EXE), but is buried deep in the basic functions if the GRASS DBMI lib.
> 
> * The basic Vect_read_line and Vect_cat_get functions work fine on Win32
> by themselves. Trouble starts when there is interaction with DBMI calls.
> 
> * The function db_open_select_cursor is at least one of the possible
> culprits, but chances are that more functions are involved. In any case,
> lockups occur more frequently when calls to Vect_read_line are done
> often, suggesting that there is some unwholesome interaction or
> competition for resources between Vect and DBMI libs.
> 
> * For some reason, this problem does not show up in Linux.
> There is strong evidence that it is a system resource allocation problem
> (mem, file handlers???), because lockups occur less frequently on
> systems with more available RAM. The problem exists on both Windows 2000
> and Windows XP systems (Vista untested).
> 
> 
> 
> For today, I am giving up.
> At least now it seems to become clearer where to look for the culprit.
> If any of you have any bright ideas, I'd be grateful to hear about them.

My first guesses would be:

1. The "#ifdef __MINGW32__" portion of lib/db/dbmi_client/start.c
2. The Windows port of the RPC/XDR library.

If the behaviour is non-deterministic (i.e. you don't get exactly the
same behaviour from consecutive runs), I would suspect that it's
timing related. Checking that incomplete read/write operations are
correctly handled might be a good place to start.

-- 
Glynn Clements <glynn at gclements.plus.com>