[GRASS-dev] v.digit crash

Markus_Neteler1 · May 2, 2007, 6:51pm

HI,

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

strace v.digit mystreams
....
write(8, "\3\30\2\0\313\0\0\4\16\0\2\0\313\0\0\4", 16) = 16
read(8, "\1\0\375\t\3\0\0\0!\0\0\0\1\0\1\1\377\377\377\377\0\0\0"..., 32) = 32
read(8, "\177\200\301\0\177\200\301\0\0\0\37\10", 12) = 12
read(8, "\1\30\376\t\0\0\0\0\242\0\0\0\4\0C\1a\256\26\0\0\0\0\0"..., 32) = 32
write(8, "\10\30\2\0\313\0\0\4>\0\7\0\303\0\0\4\277\0\0\4\177\0\0"..., 188) = 188
write(7, "\0", 1) = 1
futex(0x83b93e8, FUTEX_WAKE, 1) = 1
futex(0x8705388, FUTEX_WAKE, 1) = 1
futex(0x870538c, FUTEX_WAIT, 471, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x83b93e8, FUTEX_WAKE, 1) = 0
gettimeofday({1178131672, 506046}, {4294967176, 0}) = 0
ioctl(8, FIONREAD, [64]) = 0
read(8, "\17\360\377\t\313\0\0\4\1\2\0\0\337\2\0\0\377\177\0\0\223"..., 64) = 64
write(7, "\0", 1) = 1
futex(0x83b93e8, FUTEX_WAKE, 1) = 1
futex(0x8705388, FUTEX_WAKE, 1) = 1
futex(0x870538c, FUTEX_WAIT, 473, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x83b93e8, FUTEX_WAKE, 1) = 0
gettimeofday({1178131672, 507598}, {4294967176, 0}) = 0
write(8, "5\30\4\0\303\0\0\4\275\0\0\4\21\0\340\1F\0\5\0\303\0\0"..., 1424) = 1424
write(7, "\0", 1) = 1
futex(0x83b93e8, FUTEX_WAKE, 1) = 1
futex(0x8705388, FUTEX_WAKE, 1) = 1
futex(0x870538c, FUTEX_WAIT, 475, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x83b93e8, FUTEX_WAKE, 1) = 0
gettimeofday({1178131672, 509871}, {4294967176, 0}) = 0
ioctl(8, FIONREAD, [288]) = 0
read(8, "\0\v;\n\303\0\0\4\0\0005\0\0\0\0\0\20\0\0\0\235q\t\10\0"..., 288) = 288
open("/usr/share/X11/XErrorDB", O_RDONLY) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=37949, ...}) = 0
read(9, "! $Xorg: XErrorDB,v 1.3 2000/08/"..., 37949) = 37949
close(9) = 0
brk(0xbf45000) = 0xbf45000
write(2, "X Error of failed request: BadA"..., 78X Error of failed request: BadAlloc (insufficient resources for operation)
) = 78
write(2, "Major opcode of failed request: "..., 35Major opcode of failed request: 53) = 35
write(2, " (X_CreatePixmap)\n", 18 (X_CreatePixmap)
) = 18
write(2, " ", 2 ) = 2
write(2, "Serial number of failed request:"..., 38Serial number of failed request: 2619) = 38
write(2, "\n ", 3
) = 3
write(2, "Current serial number in output "..., 45Current serial number in output stream: 2627) = 45
write(2, "\n", 1
) = 1
exit_group(1) = ?
Process 26510 detached

I see that it tried to open the database table form then zap.

v.db.connect -p mystreams
Vector map <mystreams> is connected by:
layer <1> table <mystreams> in database </home/neteler/grassdata/nc_spm_04/sqlite/sqlite.db> through driver <sqlite> with key <cat>

Please suggest how to debug this one.

Markus

Markus_Neteler1 · May 2, 2007, 8:46pm

On Wed, May 02, 2007 at 08:51:32PM +0200, Markus Neteler wrote:

HI,

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

strace v.digit mystreams
....
write(8, "\3\30\2\0\313\0\0\4\16\0\2\0\313\0\0\4", 16) = 16
read(8, "\1\0\375\t\3\0\0\0!\0\0\0\1\0\1\1\377\377\377\377\0\0\0"..., 32) = 32
read(8, "\177\200\301\0\177\200\301\0\0\0\37\10", 12) = 12
read(8, "\1\30\376\t\0\0\0\0\242\0\0\0\4\0C\1a\256\26\0\0\0\0\0"..., 32) = 32
write(8, "\10\30\2\0\313\0\0\4>\0\7\0\303\0\0\4\277\0\0\4\177\0\0"..., 188) = 188
write(7, "\0", 1) = 1
futex(0x83b93e8, FUTEX_WAKE, 1) = 1
futex(0x8705388, FUTEX_WAKE, 1) = 1
futex(0x870538c, FUTEX_WAIT, 471, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x83b93e8, FUTEX_WAKE, 1) = 0
gettimeofday({1178131672, 506046}, {4294967176, 0}) = 0
ioctl(8, FIONREAD, [64]) = 0
read(8, "\17\360\377\t\313\0\0\4\1\2\0\0\337\2\0\0\377\177\0\0\223"..., 64) = 64
write(7, "\0", 1) = 1
futex(0x83b93e8, FUTEX_WAKE, 1) = 1
futex(0x8705388, FUTEX_WAKE, 1) = 1
futex(0x870538c, FUTEX_WAIT, 473, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x83b93e8, FUTEX_WAKE, 1) = 0
gettimeofday({1178131672, 507598}, {4294967176, 0}) = 0
write(8, "5\30\4\0\303\0\0\4\275\0\0\4\21\0\340\1F\0\5\0\303\0\0"..., 1424) = 1424
write(7, "\0", 1) = 1
futex(0x83b93e8, FUTEX_WAKE, 1) = 1
futex(0x8705388, FUTEX_WAKE, 1) = 1
futex(0x870538c, FUTEX_WAIT, 475, NULL) = -1 EAGAIN (Resource temporarily unavailable)
futex(0x83b93e8, FUTEX_WAKE, 1) = 0
gettimeofday({1178131672, 509871}, {4294967176, 0}) = 0
ioctl(8, FIONREAD, [288]) = 0
read(8, "\0\v;\n\303\0\0\4\0\0005\0\0\0\0\0\20\0\0\0\235q\t\10\0"..., 288) = 288
open("/usr/share/X11/XErrorDB", O_RDONLY) = 9
fstat64(9, {st_mode=S_IFREG|0644, st_size=37949, ...}) = 0
read(9, "! $Xorg: XErrorDB,v 1.3 2000/08/"..., 37949) = 37949
close(9) = 0
brk(0xbf45000) = 0xbf45000
write(2, "X Error of failed request: BadA"..., 78X Error of failed request: BadAlloc (insufficient resources for operation)
  ) = 78
write(2, "Major opcode of failed request: "..., 35Major opcode of failed request: 53) = 35
write(2, " (X_CreatePixmap)\n", 18 (X_CreatePixmap)
) = 18
write(2, " ", 2 ) = 2
write(2, "Serial number of failed request:"..., 38Serial number of failed request: 2619) = 38
write(2, "\n ", 3
  ) = 3
write(2, "Current serial number in output "..., 45Current serial number in output stream: 2627) = 45
write(2, "\n", 1
) = 1
exit_group(1) = ?
Process 26510 detached

I see that it tried to open the database table form then zap.

v.db.connect -p mystreams
Vector map <mystreams> is connected by:
layer <1> table <mystreams> in database </home/neteler/grassdata/nc_spm_04/sqlite/sqlite.db> through driver <sqlite> with key <cat>

Please suggest how to debug this one.

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

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.

Markus

Glynn_Clements1 · May 3, 2007, 12:16am

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.

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

Markus_Neteler1 · May 3, 2007, 12:39pm

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

(attachments)

sqlite.diff (803 Bytes)

Glynn_Clements1 · May 3, 2007, 4:11pm

Markus Neteler wrote:

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.

Seems okay.

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

Markus_Neteler1 · May 4, 2007, 9:51am

Glynn Clements wrote on 05/03/2007 06:11 PM:

Markus Neteler wrote:

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.

Seems okay.

Submitted and backported to 6.2-CVS.

Markus

------------------
ITC -> dall'1 marzo 2007 Fondazione Bruno Kessler
ITC -> since 1 March 2007 Fondazione Bruno Kessler
------------------