[GRASS-dev] native WinGRASS and attribute data deadlock, next try

Benjamin Ducke benjamin.ducke at ufg.uni-kiel.de
Tue Jun 26 11:21:39 EDT 2007


Dear all,

I recently found some time to hunt for that stupid attribute table bug
in the MingW compiled version of GRASS 6.3.CVS. This is the setup I
used:

Windows 2000 SP4
QGIS 0.8.1
GDAL 1.4.1
GRASS 6.3.CVS June 18th 2007
MSYS 1.0.10
MingW 5.1.3
GNU Debug for MingW 6.3.1

The problem, as I described earlier: under native Win32 (MingW
binaries), GRASS modules that access attribute data in a vector
map frequently deadlock, i.e. they will just sleep and operations
never finish.

It's easy to verify this using the following dataset:

ftp://ftp.rz.uni-kiel.de/pub/ufg/qgis-test.zip

and this command line:

v.out.ogr.exe input=points at user type=point layer=1 format=ESRI_Shapefile
-c dsn=. olayer=test

After a while, v.out.ogr.exe will fall asleep, with 0% CPU usage.
In fact, out of 50 tries I made, only 3 resulted in a successful export!
The exact point at which v.out.ogr.exe deadlocks cannot be predicted.
The problem appears randomly. In most instances, when killing the
process, a "dbmi: Protocol error" will pop up.

Like Moritz did earlier, I tried debugging v.out.ogr.exe and dbf.exe
using GDB 6.3.1. And like him, I did not get very far because of missing
symbol information in the Windows binaries (I am just not much of a
Windows developer).

However, I suspect that the problem is NOT IN THE DBF DRIVER. Here is
why: I added sqlite support to the Win binaries and made a copy of the
sample vector map 'dgm' contained in qgis-test.zip. Before I did this,
I switched to the sqlite database driver, so the attribute data ended
up in an sqlite file instead of a DBF. I verified that this was indeed
the case. I then ran the command line above on the vector map connected
to the sqlite table and ran into the same problems!

As far as I can tell, the bug must be in a higher layer of the DBMI
lib, perhaps DBMI client or base?

Side note: I ran the same command with GRASS CVS sources from the same
day under Linux. I used Valgrind to detect any memory handling problems
but found nothing!

If any of you have more experience debugging Win32 binaries, please
post your hints. I am running out of ideas here ...

Best,

Benjamin



-- 
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg




More information about the grass-dev mailing list