Context Navigation

← Previous Ticket
Next Ticket →

#1308 closed defect (fixed)

wingrass - dbf.exe-crash

Reported by:	hellik	Owned by:	grass-dev@…
Priority:	blocker	Milestone:	6.4.1
Component:	Default	Version:	svn-releasebranch64
Keywords:	wingrass, dbf.exe, d.vect	Cc:
CPU:	x86-32	Platform:	MSWindows Vista

Description

tested with nightly-build WinGRASS-6.4.SVN-r45623-1-Setup.exe (but IIRC sometimes also in earlier revisions) in nc-sample-dataset

(1) in the wxgui add vector layer (2) d.vect-gui pops up (3) choosing a layer (very interesting, it isn't always the same

existing layer and not always; I can't really give repeatable circumstances)

(4) dbf.exe crashes (5) after clicking away the crash-error-windows and closing the

d.vect-gui, the layer is added in the tree and the map display

some additional informations (delivered by DEUBUG=5 and windows-crash-informations:

D1/5: grass.script.core.start_command(): g.mlist -m type=vect
D1/5: grass.script.core.start_command(): v.db.connect -g map=lakes@PERMANENT fs=;
D1/5: grass.script.core.start_command(): db.describe -c table=lakes driver=dbf database=C:\gisdata\grassdata\nc_spm_08\PERMANENT\dbf\
GRASS 6.4> 
GRASS 6.4> D1/5: grass.script.core.start_command(): d.vect --q map=lakes@PERMANENT type=point,area,face,centroid,line,boundary
D1/5: grass.script.core.start_command(): g.pnmcomp opacity=1.0 mask=c:\users\syringia\appdata\local\temp\tmp5rhzes.pgm height=502 width=782 background=255:255:255:255 input=c:\users\syringia\appdata\local\temp\tmp5rhzes.ppm output=c:\users\syringia\appdata\local\temp\tmpo5cnsd.ppm
D1/5: grass.script.core.start_command(): g.findfile -n file=MASK element=cell

it seems the crash is nearby the v.db.connect- and db.describe-steps.

<?xml version="1.0" encoding="UTF-16"?>
<DATABASE>
<EXE NAME="dbf.exe" FILTER="GRABMI_FILTER_PRIVACY">
    <MATCHING_FILE NAME="dbf.exe" SIZE="553931" CHECKSUM="0x378861C9" MODULE_TYPE="WIN32" PE_CHECKSUM="0x93EF1" LINKER_VERSION="0x10000" LINK_DATE="03/11/2011 02:08:34" UPTO_LINK_DATE="03/11/2011 02:08:34" />
    <MATCHING_FILE NAME="odbc.exe" SIZE="475447" CHECKSUM="0xEEE2279C" MODULE_TYPE="WIN32" PE_CHECKSUM="0x77E51" LINKER_VERSION="0x10000" LINK_DATE="03/11/2011 02:08:39" UPTO_LINK_DATE="03/11/2011 02:08:39" />
    <MATCHING_FILE NAME="ogr.exe" SIZE="80297" CHECKSUM="0xC557406A" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1FDFB" LINKER_VERSION="0x10000" LINK_DATE="03/11/2011 02:08:45" UPTO_LINK_DATE="03/11/2011 02:08:45" />
    <MATCHING_FILE NAME="pg.exe" SIZE="101619" CHECKSUM="0x3C15C8C2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x209B9" LINKER_VERSION="0x10000" LINK_DATE="03/11/2011 02:08:42" UPTO_LINK_DATE="03/11/2011 02:08:42" />
    <MATCHING_FILE NAME="sqlite.exe" SIZE="95388" CHECKSUM="0x132FBDAF" MODULE_TYPE="WIN32" PE_CHECKSUM="0x1C709" LINKER_VERSION="0x10000" LINK_DATE="03/11/2011 02:08:44" UPTO_LINK_DATE="03/11/2011 02:08:44" />
</EXE>
<EXE NAME="ntdll.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
    <MATCHING_FILE NAME="ntdll.dll" SIZE="1205080" CHECKSUM="0x1C4D583" BIN_FILE_VERSION="6.0.6002.18327" BIN_PRODUCT_VERSION="6.0.6002.18327" PRODUCT_VERSION="6.0.6001.18000" FILE_DESCRIPTION="DLL für NT-Layer" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Betriebssystem Microsoft® Windows®" FILE_VERSION="6.0.6001.18000 (longhorn_rtm.080118-1840)" ORIGINAL_FILENAME="ntdll.dll.mui" INTERNAL_NAME="ntdll.dll" LEGAL_COPYRIGHT="© Microsoft Corporation. Alle Rechte vorbehalten." VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0x12F237" LINKER_VERSION="0x60000" UPTO_BIN_FILE_VERSION="6.0.6002.18327" UPTO_BIN_PRODUCT_VERSION="6.0.6002.18327" LINK_DATE="10/14/2010 16:47:50" UPTO_LINK_DATE="10/14/2010 16:47:50" EXPORT_NAME="ntdll.dll" VER_LANGUAGE="Deutsch (Deutschland) [0x407]" />
</EXE>
<EXE NAME="kernel32.dll" FILTER="GRABMI_FILTER_THISFILEONLY">
    <MATCHING_FILE NAME="kernel32.dll" SIZE="891392" CHECKSUM="0xF772C2F2" BIN_FILE_VERSION="6.0.6002.18005" BIN_PRODUCT_VERSION="6.0.6002.18005" PRODUCT_VERSION="6.0.6001.18000" FILE_DESCRIPTION="Client-DLL für Windows NT-Basis-API" COMPANY_NAME="Microsoft Corporation" PRODUCT_NAME="Betriebssystem Microsoft® Windows®" FILE_VERSION="6.0.6001.18000 (longhorn_rtm.080118-1840)" ORIGINAL_FILENAME="kernel32" INTERNAL_NAME="kernel32" LEGAL_COPYRIGHT="© Microsoft Corporation. Alle Rechte vorbehalten." VERDATEHI="0x0" VERDATELO="0x0" VERFILEOS="0x40004" VERFILETYPE="0x2" MODULE_TYPE="WIN32" PE_CHECKSUM="0xDBE01" LINKER_VERSION="0x60000" UPTO_BIN_FILE_VERSION="6.0.6002.18005" UPTO_BIN_PRODUCT_VERSION="6.0.6002.18005" LINK_DATE="04/11/2009 06:25:33" UPTO_LINK_DATE="04/11/2009 06:25:33" EXPORT_NAME="KERNEL32.dll" VER_LANGUAGE="Deutsch (Deutschland) [0x407]" />
</EXE>
</DATABASE>

Helmut

Attachments (1)

dbmi-45515.diff (7.1 KB ) - added by martinl 13 years ago.: revert 45515

Download all attachments as: .zip

Change History (20)

in reply to: description ; follow-up: 4 comment:1 by hellik, 13 years ago

Replying to hellik:

it seems the crash is nearby the v.db.connect- and db.describe-steps.

after finishing wingrass, in the windows task manager it seems there are still some db.describe.exe-instances running.

comment:2 by martinl, 13 years ago

Priority:	major → blocker

follow-up: 11 comment:3 by hellik, 13 years ago

seems related to #1298 (http://trac.osgeo.org/grass/ticket/1298), dbf.exe-crash with v.digit

in reply to: 1 ; follow-up: 5 comment:4 by martinl, 13 years ago

Replying to hellik:

Replying to hellik:

it seems the crash is nearby the v.db.connect- and db.describe-steps.

after finishing wingrass, in the windows task manager it seems there are still some db.describe.exe-instances running.

it's strange that it crashes only sometimes, it's probably unrelated but with r45652 I was not able to reproduce this bug. Can you test it?

in reply to: 4 ; follow-up: 6 comment:5 by martinl, 13 years ago

Replying to martinl:

Replying to hellik:

Replying to hellik:

it seems the crash is nearby the v.db.connect- and db.describe-steps.

after finishing wingrass, in the windows task manager it seems there are still some db.describe.exe-instances running.

it's strange that it crashes only sometimes, it's probably unrelated but with r45652 I was not able to reproduce this bug. Can you test it?

build available at http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r45652-1-Setup.exe

in reply to: 5 ; follow-up: 7 comment:6 by hellik, 13 years ago

Replying to martinl:

Replying to martinl:

Replying to hellik:

Replying to hellik:

it seems the crash is nearby the v.db.connect- and db.describe-steps.

after finishing wingrass, in the windows task manager it seems there are still some db.describe.exe-instances running.

it's strange that it crashes only sometimes, it's probably unrelated but with r45652 I was not able to reproduce this bug. Can you test it?

build available at http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r45652-1-Setup.exe

it's very strange. tested in following way with the nc-sample-dataset adding always geology, firestations, lakes and geonamesNC in the same order:

self compiled r45652 in the osgeo4w-stack:

(1) starting wingrass in the osgeo4w-windows-shell(command line):

first run adding -geology dbf.exe-crash

firestations dbf.exe-crash
lakes ok
geonames dbf.exe-crash

exit the grass-session and starting a new second one, all vector are loading normally

(2) starting wingrass in the osgeo4w-msys-shell:

-geology ok

firestations ok
lakes dbf.exe-crash
geonames ok

exit the grass-session and starting a new second one, all vector are loading normally

(3) testing

http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r45652-1-Setup.exe

all vectors added with the d.vect without any dbf.exe-crash.

Helmut

p.s. no dbf.exe-crash with create a new vector by v.digit in all 3 approaches

in reply to: 6 ; follow-up: 8 comment:7 by martinl, 13 years ago

Replying to hellik:

(3) testing

http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r45652-1-Setup.exe

all vectors added with the d.vect without any dbf.exe-crash.

I made some tests, unfortunately it's still sometimes crashing.

in reply to: 7 comment:8 by martinl, 13 years ago

Replying to martinl:

I made some tests, unfortunately it's still sometimes crashing.

it's really hard to hunt this bug, currently trying to reproduce dbf crash. Unfortunately not crashing here after some attempts. Can some post here full debug output?

g.debug set=DEBUG=5

in reply to: description ; follow-up: 10 comment:9 by martinl, 13 years ago

Replying to hellik:

some additional informations (delivered by DEUBUG=5 and windows-crash-informations:

> D1/5: grass.script.core.start_command(): g.mlist -m type=vect
> D1/5: grass.script.core.start_command(): v.db.connect -g map=lakes@PERMANENT fs=;
> D1/5: grass.script.core.start_command(): db.describe -c table=lakes driver=dbf database=C:\gisdata\grassdata\nc_spm_08\PERMANENT\dbf\
> GRASS 6.4> 
> GRASS 6.4> D1/5: grass.script.core.start_command(): d.vect --q map=lakes@PERMANENT type=point,area,face,centroid,line,boundary
> D1/5: grass.script.core.start_command(): g.pnmcomp opacity=1.0 mask=c:\users\syringia\appdata\local\temp\tmp5rhzes.pgm height=502 width=782 background=255:255:255:255 input=c:\users\syringia\appdata\local\temp\tmp5rhzes.ppm output=c:\users\syringia\appdata\local\temp\tmpo5cnsd.ppm
> D1/5: grass.script.core.start_command(): g.findfile -n file=MASK element=cell

it doesn't seem to be full debug output, I can see only debug messages produced by python library...

in reply to: 9 ; follow-up: 14 comment:10 by martinl, 13 years ago

Replying to martinl:

Replying to hellik:

some additional informations (delivered by DEUBUG=5 and windows-crash-informations:

> > D1/5: grass.script.core.start_command(): g.mlist -m type=vect
> > D1/5: grass.script.core.start_command(): v.db.connect -g map=lakes@PERMANENT fs=;
> > D1/5: grass.script.core.start_command(): db.describe -c table=lakes driver=dbf database=C:\gisdata\grassdata\nc_spm_08\PERMANENT\dbf\

here is missing completely debug info from db.describe, so it seems that it crashes before first debug message (?)

D2/5: dbDbmscap(): opendir [c:\Program Files (x86)\GRASS 6.4.SVN\driver\db\]

> > GRASS 6.4> 
> > GRASS 6.4> D1/5: grass.script.core.start_command(): d.vect --q map=lakes@PERMANENT type=point,area,face,centroid,line,boundary
> > D1/5: grass.script.core.start_command(): g.pnmcomp opacity=1.0 mask=c:\users\syringia\appdata\local\temp\tmp5rhzes.pgm height=502 width=782 background=255:255:255:255 input=c:\users\syringia\appdata\local\temp\tmp5rhzes.ppm output=c:\users\syringia\appdata\local\temp\tmpo5cnsd.ppm
> > D1/5: grass.script.core.start_command(): g.findfile -n file=MASK element=cell

in reply to: 3 ; follow-up: 12 comment:11 by martinl, 13 years ago

Replying to hellik:

seems related to #1298 (http://trac.osgeo.org/grass/ticket/1298), dbf.exe-crash with v.digit

these bugs have been reported recently, it's worth to review r45515 (lib/db/dbmi_base part). I can be that this bug has been accidentally introduced by this commit - just an idea...

by martinl, 13 years ago

Attachment:	dbmi-45515.diff added

revert 45515

in reply to: 11 ; follow-up: 13 comment:12 by martinl, 13 years ago

Replying to martinl:

Replying to hellik:

seems related to #1298 (http://trac.osgeo.org/grass/ticket/1298), dbf.exe-crash with v.digit

these bugs have been reported recently, it's worth to review r45515 (lib/db/dbmi_base part). I can be that this bug has been accidentally introduced by this commit - just an idea...

patch attached - dbmi-45515.diff

in reply to: 12 ; follow-up: 15 comment:13 by martinl, 13 years ago

Replying to martinl:

Replying to martinl:

Replying to hellik:

seems related to #1298 (http://trac.osgeo.org/grass/ticket/1298), dbf.exe-crash with v.digit

these bugs have been reported recently, it's worth to review r45515 (lib/db/dbmi_base part). I can be that this bug has been accidentally introduced by this commit - just an idea...

patch attached - dbmi-45515.diff

I found incorrect usage of db_free_string on variable char *, fixed in r45671. I am still unable to reproduce any crash...

in reply to: 10 comment:14 by hellik, 13 years ago

Replying to martinl:

> > D1/5: grass.script.core.start_command(): g.mlist -m type=vect
> > D1/5: grass.script.core.start_command(): v.db.connect -g map=lakes@PERMANENT fs=;
> > D1/5: grass.script.core.start_command(): db.describe -c table=lakes driver=dbf database=C:\gisdata\grassdata\nc_spm_08\PERMANENT\dbf\

here is missing completely debug info from db.describe, so it seems that it crashes before first debug message (?)

yes it seems so what I have also found in my testings Helmut

in reply to: 13 ; follow-up: 16 comment:15 by hellik, 13 years ago

Replying to martinl:

I found incorrect usage of db_free_string on variable char *, fixed in r45671. I am still unable to reproduce any crash...

no chance at the moment for compiling myself r45671. I'll test it when nightly build will be available.

Helmut

in reply to: 15 ; follow-up: 19 comment:16 by martinl, 13 years ago

Replying to hellik:

Replying to martinl:

I found incorrect usage of db_free_string on variable char *, fixed in r45671. I am still unable to reproduce any crash...

no chance at the moment for compiling myself r45671. I'll test it when nightly build will be available.

extra build available at http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r45671-1-Setup.exe

follow-up: 18 comment:17 by neteler, 13 years ago

I checked the patch r45671 and found another bug candidate:

in lib/db/dbmi_base/value.c (http://trac.osgeo.org/grass/changeset/45515#file16) -> G_free? I guess db_free()?

Then in lib/db/dbmi_driver/d_close_cur.c, checking the db_free_cursor(): /* ?? */ call (http://trac.osgeo.org/grass/changeset/45673#file2): looks ok to me since db_free_cursor() does not free cursor itself. Not sure, though.

in reply to: 17 comment:18 by martinl, 13 years ago

Replying to neteler:

I checked the patch r45671 and found another bug candidate:

in lib/db/dbmi_base/value.c (http://trac.osgeo.org/grass/changeset/45515#file16) -> G_free? I guess db_free()?

it's allocated by G_calloc , anyway it should be harmless, currently G_free() and db_free() are identical.

in reply to: 16 comment:19 by hellik, 13 years ago

Resolution:	→ fixed
Status:	new → closed

Replying to martinl:

Replying to hellik:

Replying to martinl:

I found incorrect usage of db_free_string on variable char *, fixed in r45671. I am still unable to reproduce any crash...

no chance at the moment for compiling myself r45671. I'll test it when nightly build will be available.

extra build available at http://josef.fsv.cvut.cz/wingrass/grass64/WinGRASS-6.4.SVN-r45671-1-Setup.exe

I've tested it a little with above build in different modes (GRASS 6.4.SVN,GRASS 6.4.SVN with MSYS, GRASS Old TclTk GUI, GRASS Command Line and g.gui wxpython) with a random set of nc-sample-vectors in about 30 sessions. I can't reproduce this anymore.

from the dev-ML http://lists.osgeo.org/pipermail/grass-dev/2011-March/053825.html

Hi,

2011/3/16 Markus Neteler <neteler at osgeo.org>:
>>  it's allocated by
>>  [source:grass/branches/releasebranch_6_4/lib/db/dbmi_base/value.c#L374
>>  G_calloc], anyway it should be harmless, currently `G_free()` and
>>  `db_free()` are identical.
>
> Ok, I was just remembering
> http://trac.osgeo.org/grass/ticket/468#comment:2
>
> (were  they came from different DLLs, hence the problem)

right, I overlooked this issue. Anyway now it should OK.

Martin

I see there was some code review for this issue, therefore I'll close this ticket. please reopen if needed.

Helmut

Note: See TracTickets for help on using tickets.

Download in other formats: