Opened 13 years ago

Last modified 13 years ago

#3648 new bug

Qgis 1.6/trunk, osgeo4w/standalone hangs/crashes when adding GRASS vectors in a QGIS project

Reported by: lutra Owned by: rblazek
Priority: critical: causes crash or data corruption Milestone: Version 1.7.0
Component: GRASS Version: 1.6.0
Keywords: Cc: pcav, jef, neteler, jdenisgiguere, timlinux, martinl
Must Fix for Release: Yes Platform: Windows
Platform Version: Awaiting user input: no

Description

I spent the afternoon testing after Paolo told me that the last week he had many problems with GRASS vectors under Windows.

I can confirm, under both XP and Seven 32bit, QGIS crashes when it comes to simply operations with vectors such as:

*) importing a vector (shapefile) with v.in.ogr

*) adding an imported vector by clicking "view output" or using the proper button in the GRASS (toolbox) toolbar or using the QGIS GRASS toolbar

*) sometimes adding a vector qgis does not crash, but adding a second time it does

*) it seems to happen more with lines and polygons than with points and with vectors that are "big" (I'll attach a 13mb shapefile, in epsg 3003, that can be used to replicate easily the crashes).

All it seems pretty unpredictable and it does NOT happens under qgis 1.5 standalone, like #3646

http://rapidshare.com/files/453528319/freguesias_shp.zip

Attachments (1)

USER-PC.7z (83.4 KB ) - added by billywill 13 years ago.
debug

Download all attachments as: .zip

Change History (23)

comment:1 by lutra, 13 years ago

This is very frustrating... because the bug it is pretty unpredictable, but definitely there. It seems to happen more on osgeo4w than in the standalone version.

comment:2 by lutra, 13 years ago

it does not seems to be related to size/complexity of vectors, it just happened with a very small line vector (3 lines).

comment:3 by lutra, 13 years ago

Cc: neteler added

I am pretty sure that at the beginning of February this wasn't a issue with both trunk/1.6 from osgeo4w. Since then it changed the GRASS version? Any backport to 1.6?

comment:4 by lutra, 13 years ago

a downgrade to the previous GRASS release available in osgeo4w proven ineffective. On standalone 1.5 it seems to really work as expected.

in reply to:  description ; comment:5 by hellik, 13 years ago

tested with osgeo4w-qgis-trunk (1.7.0-100) and the attached shapefile.

*) importing a vector (shapefile) with v.in.ogr

I've imported freguesias.shp several times by v.in.ogr in the same qgis-grass-session and several times in different qgis-grass-sessions. the import worked all the time without any qgis-crash. the only thing is that I thought the first time that the import has already finished (just too impatient ;-)), but it wasn't.

*) adding an imported vector by clicking "view output" or using the proper button in the GRASS (toolbox) toolbar or using the QGIS GRASS toolbar

tried this in several qgis-grass-sessions, adding the vector sometimes but not always crashes in an unreproducable way (maybe some memory issues?)

*) sometimes adding a vector qgis does not crash, but adding a second time it does

confirmed.

*) it seems to happen more with lines and polygons than with points and with vectors that are "big" (I'll attach a 13mb shapefile, in epsg 3003, that can be used to replicate easily the crashes).

All it seems pretty unpredictable and it does NOT happens under qgis 1.5 standalone, like #3646

if the attribute table is opened, by scrolling in the attribute entries, sometimes the attribute table freezes for a very short time

in reply to:  5 ; comment:6 by lutra, 13 years ago

I've imported freguesias.shp several times by v.in.ogr in the same qgis-grass-session and several times in different qgis-grass-sessions. the import worked all the time without any qgis-crash. the only thing is that I thought the first time that the import has already finished (just too impatient ;-)), but it wasn't.

really weird. I have also updated qgis-trunk to 1.7.0-100 and now it seems that this problem become really rare. I can also import now the attached vector over and over almost without any problem. I got a crash but it was one among tens of attempts...

*) adding an imported vector by clicking "view output" or using the proper button in the GRASS (toolbox) toolbar or using the QGIS GRASS toolbar

tried this in several qgis-grass-sessions, adding the vector sometimes but not always crashes in an unreproducable way (maybe some memory issues?)

as above, now it works almost without problems. Crashes doing this operation become rare. More common when adding more then one vector at the same time

*) sometimes adding a vector qgis does not crash, but adding a second time it does

confirmed.

see above.

*) it seems to happen more with lines and polygons than with points and with vectors that are "big" (I'll attach a 13mb shapefile, in epsg 3003, that can be used to replicate easily the crashes).

All it seems pretty unpredictable and it does NOT happens under qgis 1.5 standalone, like #3646

after the first tests it become clear that there is (was?) no pattern.

if the attribute table is opened, by scrolling in the attribute entries, sometimes the attribute table freezes for a very short time

yes, VERY slow to scroll the attributes table. I don't see "short time freezes", if the table has just hundreds of records it freezes for many seconds.

in reply to:  6 ; comment:7 by lutra, 13 years ago

really weird. I have also updated qgis-trunk to 1.7.0-100 and now it seems that this problem become really rare. I can also import now the attached vector over and over almost without any problem. I got a crash but it was one among tens of attempts...

but yet it seems fragile. After having imported the attached vector it crashed the first time I attempted a dissolve operation with v.dissolve. I made further attempts and no crashes.

By the way as for v.in.ogr when it crashes it does after having completed correctly the operation.

comment:8 by lutra, 13 years ago

it is really unpredictable. Sometimes seems to work overall in a acceptable way, other times is very unstable/fragile and freezes crashes when importing/adding/removing (from qgis TOC) a vector that seemed to work fine minutes before. You may also want to try the vectors attached to #3650 and/or merge the two tickets, they seems related to me.

I'll appreciate if someone other than me and hellik can give it a try.

I'm using QGIS trunk/osgeo4w under Seven 32/64 bit.

in reply to:  7 ; comment:9 by marisn, 13 years ago

Replying to lutra:

By the way as for v.in.ogr when it crashes it does after having completed correctly the operation.

Hm. Sounds familiar. It's a known issue when v.in.ogr runs on Windows. There where some cleanups in DBF area, that was a source of such crashes. Please test with current SVN.

in reply to:  9 ; comment:10 by hamish, 13 years ago

Replying to marisn:

There where some cleanups in DBF area, that was a source of such crashes. Please test with current SVN.

and/or, to test that theory, try using db.connect to swap to SQLite as the DB backend instead of DBF.

Hamish

in reply to:  10 comment:11 by lutra, 13 years ago

and/or, to test that theory, try using db.connect to swap to SQLite as the DB backend instead of DBF.

test done using sqlite as backend. Proven ineffective, as the crashes and general instability are confirmed.

in reply to:  9 ; comment:12 by lutra, 13 years ago

There where some cleanups in DBF area, that was a source of such crashes. Please test with current SVN.

the fixes were backported to grass 6.4 or are just available in svn (grass 6.5?)?

in reply to:  12 ; comment:13 by hamish, 13 years ago

Replying to marisn:

There where some cleanups in DBF area, that was a source of such crashes.

Please test with current SVN.

Replying to lutra:

the fixes were backported to grass 6.4 or are just available in svn (grass 6.5?)?

They've been backported to the 6.4 branch and are in 6.4.1rc2.

AFAICT there were two issues: 1) .dlls do not like to free() memory which was allocated by another function in another dll. the result is a crash even if the alloc history is kosher & correct. the work around seems to be to clone pass-through wrappers around free() in each library, and to use the library-specific free()-wrapper instead of the normal one. jef supplied a large patch tending to many of those, and Martin applied that patch.

2) https://trac.osgeo.org/grass/changeset/45652 Smells like a work-around. I'm not sure what component is not robust enough to deal with the altered dirsep. If it's a GRASS component I'd like to fix it to be more "read sloppy, write exact", if it's a Microsoft component, not much we can do about it. MS support for / as the dirsep seems to be about 80% and dates back to first QD-DOS. I'm a bit fuzzy on all the Windows voodoo, but I think system() was an important unsupported fn for the alternate dirsep. But we've now replaced almost all of the system() calls in GRASS with more robust alternatives. Maybe the dbf driver in GRASS 6.x still uses one?

anyway, please try against GRASS 6.4.1rc2, and,

Replying to hamish:

to test that theory, try using db.connect to swap to SQLite as the DB backend

instead of DBF.

use the db.connect module to do that, see the man page for instructions. Variable path names used by that command do not need to be expanded by the user or the shell (so you can move the data without having to edit the database path links).

Hamish

comment:14 by pcav, 13 years ago

I used db.connect, moving to SQLite, but I no joy

comment:15 by aghisla, 13 years ago

Cc: jdenisgiguere added

Merged with #3364.

comment:16 by lutra, 13 years ago

It is probable that this has been solved in GRASS 6.4.1

Waiting for the new version to enter osgeo4w to confirm it.

comment:17 by lutra, 13 years ago

Well... after a few days it is possible to try QGIS with GRASS 6.4.1 (not yet qgis trunk, as it seems there is a packaging problem that causes qgis show warnings when adding vectors and crashes when adding rasters).

The overall feeling is that it works slightly better that 6.4.0, but the problems described here are still replicable.

Just use the QGIS sample dataset or the GRASS dataset: importing vectors with v.in.ogr works most of the times, but sometime it freezes qgis. The freeze happens always after the window "c:\windows\system32\cmd.exe" pops out.

The problems are not of one particular vector and regardless the complexity/geometries: it happens to import one and it goes everything fine and importing it a second time freezes qgis.

The same happens when adding already imported vectors: most of the times it works ok but sometimes it causes qgis to freeze.

If this problems will be confirmed in qgis 1.7 I would say that it is not possible to close this ticket and that this remain as a major issue as it will make almost impossible to use GRASS in QGIS/Windows.

comment:18 by lutra, 13 years ago

Summary: Qgis 1.6/trunk, osgeo4w/standalone crashes when importing vectors in a GRASS mapset or when adding them to the projectQgis 1.6/trunk, osgeo4w/standalone hangs/crashes when adding GRASS vectors in a QGIS project

Hi all,

I finally made further tests, using qgis/osgeo4w (both 1.6 and trunk) and trunk/standalone created with creatensis.pl

Used a *clean* Windows Seven environment

Results

A) qgis 1.6 osgeo4w and 1.7 standalone:

adding a GRASS vector to the qgis canvas (via the GRASS browser or using the "view output" button, for example after having imported a vector) *usually* works, but at some point it will happen that adding a new vector qgis will hang and you will need to take it down.

After many hours of testing I realized that it is absolutely random: it doesn't depend on the vector, or the kind of geometry or the complexity/size or its projection. It is simply random. It can happen when adding the first vector in a project or after 20 tries. Sooner or later qgis will choke.

B) qgis trunk/osgeo4w:

qgis immediately crashes (not hangs as before) when adding a GRASS vector in a qgis project.

Forget about the vector I attched to this ticket, if you want to replicate the issue just use the QGIS sample dataset,

comment:19 by pcav, 13 years ago

Cc: timlinux added

I think this is really blocking for release, as it makes half of GRASS unusable.

in reply to:  18 comment:20 by jef, 13 years ago

Replying to lutra:

adding a GRASS vector to the qgis canvas (via the GRASS browser or using the "view output" button, for example after having imported a vector) *usually* works, but at some point it will happen that adding a new vector qgis will hang and you will need to take it down.

dbgview output?

B) qgis trunk/osgeo4w:

qgis immediately crashes (not hangs as before) when adding a GRASS vector in a qgis project.

Not reproducable here.

in reply to:  13 comment:21 by jef, 13 years ago

Cc: martinl added

Replying to hamish:

2) https://trac.osgeo.org/grass/changeset/45652 Smells like a work-around.

And shouldn't that be '
' instead of '\' at the very least?

by billywill, 13 years ago

Attachment: USER-PC.7z added

debug

comment:22 by billywill, 13 years ago

Me too on Win7, although I have had other versions of GRASS on this machine. QGIS 1.8.0.2 from the osgeo install.

Note: See TracTickets for help on using tickets.