wxGUI: vdigit crashes on a big map

[msieczka]

[ 1769.819888] python[5229]: segfault at 7fff4ae0f3e0 ip 7fe63598c343 sp 7fff4ae0f3e0 error 6 in _grass6_wxvdigit.so[7fe635968000+6c000]

Map details:

$ v.info neg_patch_poly -tg
north=90
south=-90
east=180
west=-180
top=0.000000
bottom=0.000000
nodes=180524
points=0
lines=180535
boundaries=0
centroids=0
areas=0
islands=0
faces=0
kernels=0
primitives=180535
map3d=0

Debian testing amd64, GRASS 6.4 SVN r34536.

[msieczka]

Discard "Map details" above - wrong map.

vdigit was able to open the map, but crashed and left it with topology missing. Now I have to wait 10 hours to rebuild it on a quite fast computer. Shoot. Working with big vector maps in GRASS is still a nightmare.

Anyway, here's the correct map info, copied from another source (a QGIS bug report where that map crashed Xorg when trying to display it, ​http://trac.osgeo.org/qgis/ticket/1430; interestingly the same map in GRASS X monitors crashes Xorg too, but not in wxGUI):

 $ v.info -tg neg_patch_poly_bnd_area
 north=90
 south=-90
 east=180
 west=-180
 top=0.000000
 bottom=0.000000
 nodes=361038
 points=0
 lines=0
 boundaries=180535
 centroids=180514
 areas=180514
 islands=180503
 faces=0
 kernels=0
 primitives=361049
 map3d=0

[hamish]

is there a way to count number of vertices? that is masked in the v.info -t output. So I'm not sure how it compares, but here I tried:

g.region rast=elevation.dem
r.to.vect in=elevation.dem out=elev_dem feature=area -s -v

v.info -t elev_dem
nodes=523820
points=0
lines=0
boundaries=523819
centroids=246961
areas=246961
islands=1
faces=0
kernels=0
primitives=770780
map3d=0

du -sh vector/elev_dem
50M

it was slow & used a huge amount of memory, but it didn't crash.

(g65, amd64, debian/lenny)

some wxVdigit notes:

• chosen map name box on left not wide enough
• digitize points and move vertex buttons remain depressed. after clicking on extra tools menu, that button stays depressed as well.
• memory from top: VIRT 1775m, RES 1.3g, SHR 28m python
• it is slow but functional when zoomed in. when zoomed to full extent of map it pegs my local eth0, CPU (Xorg + ssh) near 100% for 10 minutes (& counting) while it attempts to redraw. (session tunneled over ssh to the machine down the hall with 8gig RAM)

Hamish

[hamish]

Replying to hamish:

• digitize points and move vertex buttons remain depressed. after clicking on extra tools menu, that button stays depressed as well.

ie they do not act like radio buttons. pressing one does not release another.

I can select them all until every button is depressed except for the 3 on the right: undo config exit.

Hamish

[martinl]

Replying to hamish:

• digitize points and move vertex buttons remain depressed. after clicking on extra tools menu, that button stays depressed as well.

fixed in r40316. Martin

[hamish]

Replying to martinl:

Replying to hamish:

• digitize points and move vertex buttons remain depressed. after clicking on extra tools menu, that button stays

depressed as well.

fixed in r40316. Martin

excellent; thanks. I notice that the menu buttons on the right still stay depressed until you click something new instead of raising themselves as soon as the menu is gone. a minor thing, but a bit weird.

Hamish

[martinl]

Replying to hamish:

excellent; thanks. I notice that the menu buttons on the right still stay depressed until you click something new instead of raising themselves as soon as the menu is gone. a minor thing, but a bit weird.

I think it's desired features, it shows that some tool from additional tools is selected. Martin

[hamish]

Replying to martinl:

I think it's desired features, it shows that some tool from additional tools is selected.

good point.

[martinl]

Replying to hamish:

• chosen map name box on left not wide enough

enlarged r40320.

[mmetz]

Replying to hamish:

is there a way to count number of vertices? that is masked in the v.info -t output.

Only through v.build (XXX vertices registered) because the number of vertices is not stored in topo and every primitive must be read. So I'm not sure how it compares, but here I tried:

[snip]

it was slow & used a huge amount of memory, but it didn't crash.

It's partially slow and needs a huge amount of memory because topo keeps a list of updated features when opening a vector in update mode. This is unused and disabled in grass7, one effect is that vdigit in grass7 is a bit faster and uses less memory than in grass6.

Markus M

[hamish]

keeping open as it would be nice if vdigit closed a bit more gracefully if the map is too big, but downgrading severity as making things more memory efficient for really huge maps isn't quickly solvable or surprising.

Hamish