digitizer crashes, leaves vector broken

[harrikoo]

I have yet to build a case where this manifests consistently, but it has appeared several times. I describe some features of the defect:

1. Usually happens when crossing lines and boundaries: moving vertices around so that existing lines cross, thus creating new lines/areas. But not always; I haven't found a regular pattern yet.

2. digitizer crashes immeadiately, as does wxgui

3. topology is not built. After v.build, the coordinate file is larger than it should be, and v.build reports that the vector contains lots of incorrect boundaries. v.build is unable to fix these, and using v.clean does not seem to help either.

4. the vector cannot be opened in the digitizer, as the digitizer crashes immediately upon opening the corrupted vector.

5. the data in the vector can be salvaged with a judicious used of 'v.edit tool=delete' or by using 'v.extract' with right criteria to move the correct features to a new vector.

I can send a coor file of a vector demonstrating the results of this bug to someone interested in seeing it.

[mlennert]

This seems to be a rebirth of #2439 and #2476.

I've just tested on trunk and on 7.0.3RC1 and I can confirm the following behaviours of g.gui.vdigit:

1.

• Digitize one straight line.
• Digitize a second straight line that crosses the first
• Hit undo

=> Segmentation fault

• Digitize an area with the last line crossing the first
• Undo

=> Segmentation fault

3.

• Digitize one straight line
• Undo
• Redo

=> Segmentation fault

I also again can see the same issue discussed in #2439 concerning the dotted guiding line for digitization disappearing.

I don't know when this all reappeared, but at the time I'd done some extensive testing and MarkusM's fixes worked for me. No idea why the issue is back.

Declaring this as a blocker for 7.0.3 as this should just work, but could others test and confirm ?

[annakrat]

Replying to mlennert:

This seems to be a rebirth of #2439 and #2476.

I've just tested on trunk and on 7.0.3RC1 and I can confirm the following behaviours of g.gui.vdigit:

I can confirm it.

There were no related changes in wxpython/vdigit since the fixes, it could be caused by changes in the library too, but I can't assess that. You could try to isolate the issue by updating svn tree to some previous versions. However, segmentation faults don't have to occur every time which makes it difficult to find.

[mlennert]

Replying to annakrat:

You could try to isolate the issue by updating svn tree to some previous versions. However, segmentation faults don't have to occur every time which makes it difficult to find.

In my case the segfaults are systematic, so it's not that difficult.

I've been able to narrow down the range to somewhere between r64187 and r64221, but have to stop now. MarkusM has done quite some work on the vector libs during the time. Probably something in that is the culprit.

[mlennert]

Replying to mlennert:

Replying to annakrat:

You could try to isolate the issue by updating svn tree to some previous versions. However, segmentation faults don't have to occur every time which makes it difficult to find.

In my case the segfaults are systematic, so it's not that difficult.

I've been able to narrow down the range to somewhere between r64187 and r64221, but have to stop now. MarkusM has done quite some work on the vector libs during the time. Probably something in that is the culprit.

Found the change at fault: r64214. Now we need to identify what in that change causes the segfault.

[neteler]

Replying to mlennert:

Found the change at fault: r64214. Now we need to identify what in that change causes the segfault.

Cannot you run it all through "gdb" for a backtrace?

[martinl]

Replying to neteler:

Replying to mlennert:

Found the change at fault: r64214. Now we need to identify what in that change causes the segfault.

Cannot you run it all through "gdb" for a backtrace?

r64214 broke restore_line logic, I am working on this issue (unfortunately too much busy today). Hopefully tomorrow I will be able to provide a tested patch.

[martinl]

Replying to mlennert:

1.

• Digitize one straight line.
• Digitize a second straight line that crosses the first
• Hit undo

=> Segmentation fault

• Digitize an area with the last line crossing the first
• Undo

=> Segmentation fault

3.

• Digitize one straight line
• Undo
• Redo

=> Segmentation fault

1. and 3. should be fixed in r67508. I don't understand 2. (what does mean "an area with the last line crossing the first"?)

[mlennert]

Replying to martinl:

Replying to mlennert:

1.

• Digitize one straight line.
• Digitize a second straight line that crosses the first
• Hit undo

=> Segmentation fault

• Digitize an area with the last line crossing the first
• Undo

=> Segmentation fault

3.

• Digitize one straight line
• Undo
• Redo

=> Segmentation fault

1. and 3. should be fixed in r67508. I don't understand 2. (what does mean "an area with the last line crossing the first"?)

2. means: digitize an area, but instead of closing the area correctly, you draw the last (closing) line in a way that it intersects the first (or actually any of the other lines making up your area) and then you undo. It's just another case of intersecting lines causing problems with undo...

Everything works great now. Thanks a lot for this fix !

Could others help testing if they can find any bad side effects of this change ?

If not, and unless someone (MarkusM ?) has any special reason to delay this, I would suggest to backport this to release70

Moritz

[mlennert]

Replying to neteler:

Replying to mlennert:

Found the change at fault: r64214. Now we need to identify what in that change causes the segfault.

Cannot you run it all through "gdb" for a backtrace?

Well, I've never managed to debug GUI issues via gdb, notably since g.gui.vdigit is a Python script, not a C-module. Do you have tips on how to debug such issues with gdb ?

[annakrat]

Replying to mlennert:

Replying to neteler:

Replying to mlennert:

Found the change at fault: r64214. Now we need to identify what in that change causes the segfault.

Cannot you run it all through "gdb" for a backtrace?

Well, I've never managed to debug GUI issues via gdb, notably since g.gui.vdigit is a Python script, not a C-module. Do you have tips on how to debug such issues with gdb ?

For this case I use gdb trough QtCreator, you can attach external process - the gui and if gui crashes, it will show where in the c code it happened. This is quite easy, there is a wiki on using QtCreator with GRASS​here

[annakrat]

Replying to mlennert:

Could others help testing if they can find any bad side effects of this change ?

The test cases work now for me as well.

[mlennert]

Replying to annakrat:

Replying to mlennert:

Could others help testing if they can find any bad side effects of this change ?

The test cases work now for me as well.

Thanks for testing (and thanks for the tips on QtCreator).

AFAICS, the functions that were changed are only used in the wx digitizer, so I don't have the feeling that there is much to be expected in terms of unwanted side effects. I, therefore, think that we can backport.

Martin, will you do that, or should I (I don't know how much the code of the digitizer has changed between trunk and release70) ?

[martinl]

Replying to mlennert:

Martin, will you do that, or should I (I don't know how much the code of the digitizer has changed between trunk and release70) ?

done in r67517

[martinl]

Replying to harrikoo:

I have yet to build a case where this manifests consistently, but it has appeared several times. I describe some features of the defect:

1. Usually happens when crossing lines and boundaries: moving vertices around so that existing lines cross, thus creating new lines/areas. But not always; I haven't found a regular pattern yet.

2. digitizer crashes immeadiately, as does wxgui

I am not sure of originally reported issue is fixed (there is no undo mentioned)

[mlennert]

Replying to martinl:

Replying to harrikoo:

I have yet to build a case where this manifests consistently, but it has appeared several times. I describe some features of the defect:

1. Usually happens when crossing lines and boundaries: moving vertices around so that existing lines cross, thus creating new lines/areas. But not always; I haven't found a regular pattern yet.

2. digitizer crashes immeadiately, as does wxgui

I am not sure of originally reported issue is fixed (there is no undo mentioned)

I've tried to reproduce, but can't. We would need a reproducible example...

[harrikoo]

Replying to mlennert:

Replying to martinl:

I am not sure of originally reported issue is fixed (there is no undo mentioned)

I've tried to reproduce, but can't. We would need a reproducible example...

I have followed this discussion with interest. I could reproduce the bugs discovered by mlennert, but the results were actually not the same. In my original case, the resulting vector was so corrupted, that it could not be fixed, nor opened again with g.gui.vdigit; in mlennert's bugs the vectors could be opened with g.gui.vdigit after rebuilding the topology. And it is true, that in my case, undo never played any part.

So my statement would be, that the bug in my original report is not fixed; but since I cannot figure out how to reproduce it, I would also say, that the blocker status might be a bit too strong for this one.

But it was good to have other bugs fixed. (I did have the feeling that the undo/redo-buttons should not be touched.) I'll try to figure out if there is a consistent way to reproduce my bug.

[martinl]

Replying to harrikoo:

But it was good to have other bugs fixed. (I did have the feeling that the undo/redo-buttons should not be touched.) I'll try to figure out if there is a consistent way to reproduce my bug.

OK, I took liberty to downgrade the priority.

[harrikoo]

Now it just happened again! I was drawing a test vector and crossing lines and boundaries, breaking them and merging them, and then in the end, deleting extra lines; immediately after the deletion of one line (select with left, confirm with right) the digitizer crashed. This was not the first line I deleted, perhaps the 20th, so it was something particular about that line.

V.build reports errors in the file:

GRASS 7.0.2RC2 (Nemi):~/grass/Nemi/terracewall > v.build test
WARNING: Coor file of vector map <test@terracewall> is larger than it
         should be (5326 bytes excess)
Building topology for vector map <test@terracewall>...
Registering primitives...
35 primitives registered
80 vertices registered
Building areas...
 100%
4 areas built
2 isles built
Attaching islands...
 100%
Attaching centroids...
 100%
Number of nodes: 25
Number of primitives: 35
Number of points: 0
Number of lines: 8
Number of boundaries: 20
Number of centroids: 7
Number of areas: 4
Number of isles: 2
WARNING: Number of centroids exceeds number of areas: 7 > 4
WARNING: Number of incorrect boundaries: 14
WARNING: Number of centroids outside area: 3
WARNING: Number of duplicate centroids: 1

Especially the number of incorrect boundaries is way too high. Otherwise the figures seem ok.

The line I was deleting was at one end sharing a vertex with an area.

And then, g.gui.vdigit crashes with this message:

Coor file of vector map <test@terracewall> is larger than it should be (5326 bytes excess)
Current region rows: 300, cols: 450
G_malloc: unable to allocate 18446744073709551608 bytes of memory at lib/vector/vedit/render.c:312

Looking at the file with v.info shows wrong extents:

WARNING: Coor file of vector map <test@terracewall> is larger than it
         should be (5326 bytes excess)
 +----------------------------------------------------------------------------+
 | Name:            test                                                      |
 | Mapset:          terracewall                                               |
 | Location:        Nemi                                                      |
 | Database:        /home/harri/grass                                         |
 | Title:                                                                     |
 | Map scale:       1:1                                                       |
 | Name of creator: harri                                                     |
 | Organization:                                                              |
 | Source date:     Thu Jan  7 20:58:54 2016                                  |
 | Timestamp (first layer): none                                              |
 |----------------------------------------------------------------------------|
 | Map format:      native                                                    |
 |----------------------------------------------------------------------------|
 |   Type of map: vector (level: 1)                                           |
 |                                                                            |
 |   Number of points:       0               Number of centroids:  7          |
 |   Number of lines:        8               Number of boundaries: 20         |
 |   Number of areas:        0               Number of islands:    0          |
 |                                                                            |
 |   Map is 3D:              No                                               |
 |   Number of dblinks:      0                                                |
 |                                                                            |
 |   Projection: Oblique Mercator                                             |
 |                                                                            |
 |               N:     5075.53088803    S:                 0                 |
 |               E:     5174.83237245    W:                 0                 |
 |                                                                            |
 |   Digitization threshold: 0                                                |
 |   Comment:                                                                 |
 |                                                                            |
 +----------------------------------------------------------------------------+

I have not drawn anything near (0,0), all the coordinates should be well above (4800,4800).

I can try to run some debugging commands, if someone just lets me know a suitable command line...

[martinl]

Replying to harrikoo:

Now it just happened again! I was drawing a test vector and crossing lines and boundaries, breaking them and merging them, and then in the end, deleting extra lines; immediately after the deletion of one line (select with left, confirm with right) the digitizer crashed. This was not the first line I deleted, perhaps the 20th, so it was something particular about that line.

Please try to write down step-by-step instructions (or video showing all operations) which could help us to reproduce the issue as much easy as possible. Thanks.

[martinl]

Replying to harrikoo:

agreed, I would keep priority as critical not blocker.

[harrikoo]

Replying to martinl:

Replying to harrikoo:

Now it just happened again! I was drawing a test vector and crossing lines and boundaries, breaking them and merging them, and then in the end, deleting extra lines; immediately after the deletion of one line (select with left, confirm with right) the digitizer crashed. This was not the first line I deleted, perhaps the 20th, so it was something particular about that line.

Please try to write down step-by-step instructions (or video showing all operations) which could help us to reproduce the issue as much easy as possible. Thanks.

Another one: Drawing lots of areas, crossing each other, changing lines/boundaries etc. In the end a crash, when I was moving the first/last vertex of a loose boundary line to another place. No intersections took place here.

Since in each case it always takes a lot of drawing to cause the bug, perhaps the bug has something to do with the amount of drawing operations? I haven't experienced this that much in my daily work lately, since I usually digitize only a few areas or lines at a time and then save the map. Could this be something that manifests after a certain amount of operations? Will have to begin counting the operations when I next have time to work on this one.

[mlennert]

Replying to harrikoo:

Replying to martinl:

Replying to harrikoo:

Now it just happened again! I was drawing a test vector and crossing lines and boundaries, breaking them and merging them, and then in the end, deleting extra lines; immediately after the deletion of one line (select with left, confirm with right) the digitizer crashed. This was not the first line I deleted, perhaps the 20th, so it was something particular about that line.

Please try to write down step-by-step instructions (or video showing all operations) which could help us to reproduce the issue as much easy as possible. Thanks.

Another one: Drawing lots of areas, crossing each other, changing lines/boundaries etc. In the end a crash, when I was moving the first/last vertex of a loose boundary line to another place. No intersections took place here.

If areas were crossing each other, how can there have been no intersections ?

Since in each case it always takes a lot of drawing to cause the bug, perhaps the bug has something to do with the amount of drawing operations? I haven't experienced this that much in my daily work lately, since I usually digitize only a few areas or lines at a time and then save the map. Could this be something that manifests after a certain amount of operations? Will have to begin counting the operations when I next have time to work on this one.

I've really tried to reproduce, digitizing many areas and lines, crossing each other or not, changing line types, undoing, redoing, etc. I cannot reproduce. On what OS are you ?

As Martin said, a video would be very helpful in understanding the kind of situation where this happens.

[harrikoo]

I tried to create one but did not manage to make it crash at all, drew, deleted and moved lots of lines and areas. Really irritating. Will continue experimenting some other day.

System is Debian stable, running a self-compiled 7.02RC2.

First time this appeared while I was working on a different computer, running Debian stable under Virtualbox.

[mlennert]

Replying to harrikoo:

I tried to create one but did not manage to make it crash at all, drew, deleted and moved lots of lines and areas. Really irritating. Will continue experimenting some other day.

System is Debian stable, running a self-compiled 7.02RC2.

First time this appeared while I was working on a different computer, running Debian stable under Virtualbox.

Please try with current ​release70 as this is what will become 7.0.3.

[neteler]

Ticket retargeted after milestone closed

[neteler]

Ticket retargeted after 7.0.3 milestone closed

[harrikoo]

Hi!

I still haven't managed to catch the bug on video; however, I've been running a self-compiled version (r67579) of the grass70_release branch for several weeks now, and can report some improvement.

The bug itself has not gone away, I still occasionally get crashes, always connected with breaking boundaries – I discovered this after turning the automatic breaking of boundaries off. So now the crash never happens while drawing, only when using the "Break selected lines/boundaries at intersection" -tool. Opening the map after a crash shows, that new vertices have indeed been created at the intersections of the boundaries, but the boundaries have not been connected into areas.

However, with this version, the vector can be opened again with the digitizer, and after reclosing the vector, it seems ok. A simple rebuild will not remove the extra coor data, but opening and closing it in the digitizer does.

Since now the vector resulting from the crash can be reopened in the digitizer without losing any work, the severity of the bug could perhaps be decreased.

I will update my version again at some point, but it is difficult to stay current, as the bug does not manifest regularly, and I still can find no systematic way to reproduce it.

[martinl]

Since there is no reproducable example I am closing this bug report. Feel free to reopen if needed (with reproducable example of crash).