[GRASS-dev] v.digit crash

[Markus Neteler]

On Thu, May 03, 2007 at 01:16:01AM +0100, Glynn Clements wrote:
> 
> Markus Neteler wrote:
> 
> > > I managed to crash the new v.digit by editing the "streams"
> > > map of the new NC dataset. I tried to insert a new point
> > > (outlet), then
> > > 
> > > g.copy vect=streams,mystreams
> > > v.digit mystreams
> > > X Error of failed request:  BadAlloc (insufficient resources for operation)
> > >   Major opcode of failed request:  53 (X_CreatePixmap)
> > >   Serial number of failed request:  4353
> > >   Current serial number in output stream:  4361
> 
> > Digging further into this, I found out that it doesn't crash with the DBF
> > driver. So it is related to the SQLite driver.
> > 
> > Here some more debugging stuff:
> > http://mpa.itc.it/markus/tmp/vdigit_settings_sqlite.png
> > (how the table definition looks like in v.digit - all 99999 lengths!)
> > 
> > DEBUG=2 output, put here to not make the mail too long:
> > http://mpa.itc.it/markus/tmp/vdigit_settings_sqlite.txt
> 
> > <INPUT type=text size=99999 name=FTYPE value="">
> 
> That will translate into a Tk entry widget with "-width 99999", which
> could be nasty.
> 
> > There are various size=99999 there which come from
> > db/drivers/sqlite/describe.c
> > 
> >    113          fsize = 99999; /* sqlite doesn't care, it must be long enough to
> >    114                            satisfy tests in GRASS */
> > 
> > Last year I changes fsize from -1 to 99999 for v.in.ascii:
> > 
> > 2006-07-04 11:24  markus
> >         * describe.c: define sufficient length to make v.in.ascii functional
> > 
> > So far it worked. The trick seems to be to get it fixed for the form in
> > v.digit.
> 
> The same issue could apply to code using the form library, as that
> uses the same HTML library.
> 
> The main question is where to fix it; in the HTML library, in the code
> which generates the form, or in the database driver.

Probably the database driver would be best:

(db/drivers/sqlite/describe.c)

since only SQLITE_INTEGER, SQLITE_TEXT, and SQLITE_FLOAT are
supported, we could define the typical length for these fields
(based on what the DBF driver does or the PostgreSQL driver).

Attached a patch which cures the problem. If ok, I will submit.

Markus
-------------- next part --------------
Index: describe.c
===================================================================
RCS file: /home/grass/grassrepository/grass6/db/drivers/sqlite/describe.c,v
retrieving revision 1.8
diff -u -r1.8 describe.c
--- describe.c	19 Mar 2007 14:01:44 -0000	1.8
+++ describe.c	3 May 2007 12:39:04 -0000
@@ -138,8 +138,23 @@
 	    continue;
 	}
 
-        fsize = 99999; /* sqlite doesn't care, it must be long enough to
+	switch ( litetype) {
+	case SQLITE_INTEGER:
+	    fsize = 20;
+	    break;
+
+	case SQLITE_TEXT:
+	    fsize = 255;
+	    break;
+	    
+	case SQLITE_FLOAT:
+	    fsize = 20;
+	    break;
+	    
+	default:
+	    fsize = 99999; /* sqlite doesn't care, it must be long enough to
                           satisfy tests in GRASS */
+	}
 
 	column = db_get_table_column(*table, nkcols);