#2583 closed defect (fixed)
v.net: crash on Windows
| Reported by: | mlennert | Owned by: | |
|---|---|---|---|
| Priority: | critical | Milestone: | 7.0.0 |
| Component: | LibVector | Version: | svn-releasebranch70 |
| Keywords: | v.net | Cc: | |
| CPU: | Unspecified | Platform: | MSWindows 8 |
Description
Using 7.0RC2 the following command
v.net schools_wake points=streets_wake operation=connect thresh=1000 output=network
crashes the module on Windows 7 running in a kvm virtual environment in a Debian testing host.
I don't see such a crash with grass 6.4svn in the same environment.
Change History (34)
comment:1 by , 9 years ago
| Priority: | normal → critical |
|---|---|
| Summary: | v.net: crash on Windows 7 → v.net: crash on Windows |
follow-up: 11 comment:3 by , 9 years ago
| Priority: | critical → blocker |
|---|
In RC1 I get:
Copying features... 100% Building topology for vector map <network@user1>... Registering primitives... 49746 primitives registered 453320 vertices registered Number of nodes: 41813 Number of primitives: 49746 Number of points: 0 Number of lines: 49746 Number of boundaries: 0 Number of centroids: 0 Number of areas: - Number of isles: - Copying attributes... Building topology for vector map <network@user1>... Registering primitives... 50247 primitives registered 454155 vertices registered Building areas... 100% 0 areas built 0 isles built Attaching islands... Attaching centroids... 100% Number of nodes: 42136 Number of primitives: 50247 Number of points: 167 Number of lines: 50080 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 v.net complete. 334 lines (network arcs) written to output.
In RC2:
Copying features... 100% Building topology for vector map <network@test>... Registering primitives... 49746 primitives registered 453320 vertices registered Number of nodes: 41813 Number of primitives: 49746 Number of points: 0 Number of lines: 49746 Number of boundaries: 0 Number of centroids: 0 Number of areas: - Number of isles: -
and then crash.
follow-up: 5 comment:4 by , 9 years ago
Note: The release is planned for tomorrow, 15 Feb 2015.
Does it crash on all Windows boxes? Will this crash of a single module block the entire release?
I am not convinced of that. A crash of a single module on an officially obsolete OS like "Windows XP" (http://windows.microsoft.com/en-us/windows/end-support-help) should not be tagged as a blocker.
follow-up: 6 comment:5 by , 9 years ago
| Platform: | MSWindows 7 → MSWindows 8 |
|---|
Replying to neteler:
Note: The release is planned for tomorrow, 15 Feb 2015.
Does it crash on all Windows boxes? Will this crash of a single module block the entire release?
Sorry for misunderstanding, I used Windows 8. So I guess it will crash on most Windows boxes. Also, if v.net crashes, then it's a problem for the whole network analysis as Moritz suggests, that's why I think this is blocker.
I think it's worth spending some time on this even if it would postpone the release for a couple of days. If it proves difficult to fix, then we could release, but we should at least try to analyze the problem, perhaps it's easy to fix. I tested it and it worked in RC1. So that's a good start, but I can't really help with this much in other ways then testing.
follow-ups: 7 13 comment:6 by , 9 years ago
Replying to annakrat:
Replying to neteler:
Note: The release is planned for tomorrow, 15 Feb 2015.
Does it crash on all Windows boxes? Will this crash of a single module block the entire release?
Sorry for misunderstanding, I used Windows 8. So I guess it will crash on most Windows boxes. Also, if v.net crashes, then it's a problem for the whole network analysis as Moritz suggests, that's why I think this is blocker.
The v.net code is the same for a while (last change in relbranch70 was 7 weeks ago).
We are (also upon request of the devs posting in this ticket who complained about the past release procedure) following a new release procedure:
http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
" Step 5 ... - RC2:
RC2 is released as almost final.
Step 6 - Bug squashing: & Release preparation:
A final, concerted bug squashing effort by all developers of no more than one week.
..."
So let's do that. We can have 7.0.1 shortly. But we cannot postpone 7.0.0 forever.
follow-up: 8 comment:7 by , 9 years ago
Replying to neteler:
Replying to annakrat:
Replying to neteler:
Note: The release is planned for tomorrow, 15 Feb 2015.
Does it crash on all Windows boxes? Will this crash of a single module block the entire release?
Sorry for misunderstanding, I used Windows 8. So I guess it will crash on most Windows boxes. Also, if v.net crashes, then it's a problem for the whole network analysis as Moritz suggests, that's why I think this is blocker.
The v.net code is the same for a while (last change in relbranch70 was 7 weeks ago).
Then the problem could be in the vector library and there were changes between RC1 and RC2. So we have no idea if this problem doesn't affect anything else.
We are (also upon request of the devs posting in this ticket who complained about the past release procedure) following a new release procedure:
So let's do that. We can have 7.0.1 shortly. But we cannot postpone 7.0.0 forever.
I just don't like releasing grass with a serious bug when we haven't even tried to fix it. I am talking about postponing it max one week. Basically, my question is: can Markus Metz look at it soon enough? If not, then we can probably release it now.
follow-up: 9 comment:8 by , 9 years ago
Replying to annakrat:
I just don't like releasing grass with a serious bug when we haven't even tried to fix it.
Well, it does not happen e.g. on Linux.
I am talking about postponing it max one week. Basically, my question is: can Markus Metz look at it soon enough?
No idea.
If not, then we can probably release it now.
Changes I see after RC1:
- r64200 diglib: add numerical stability to dig_test_for_intersection()
- r64198 diglib: add numerical stability to dig_distance2_point_to_line()
- r64196 diglib: add numerical stability to dig_x_intersect()
- many changes in http://trac.osgeo.org/grass/log/grass/branches/releasebranch_7_0/lib/vector/Vlib
Too bad.
comment:9 by , 9 years ago
| Priority: | blocker → critical |
|---|
Replying to neteler:
Replying to annakrat:
I just don't like releasing grass with a serious bug when we haven't even tried to fix it.
Well, it does not happen e.g. on Linux.
That doesn't mean the bug is not serious.
I am talking about postponing it max one week. Basically, my question is: can Markus Metz look at it soon enough?
No idea.
If not, then we can probably release it now.
Changes I see after RC1:
- r64200 diglib: add numerical stability to dig_test_for_intersection()
- r64198 diglib: add numerical stability to dig_distance2_point_to_line()
- r64196 diglib: add numerical stability to dig_x_intersect()
- many changes in http://trac.osgeo.org/grass/log/grass/branches/releasebranch_7_0/lib/vector/Vlib
Too bad.
Ok, I downgraded it since this discussion leads to nowhere.
comment:10 by , 9 years ago
| Component: | Default → LibVector |
|---|---|
| Keywords: | crash removed |
Never mind, let's wait for a fix. I have cancelled the tomorrow's release at
http://trac.osgeo.org/grass/wiki/Grass7Planning#a7.0.0finalplanned:15Feb2015
comment:11 by , 9 years ago
Replying to annakrat:
In RC2:
> Number of boundaries: 0 > Number of centroids: 0 > Number of areas: - > Number of isles: -
and then crash.
I cannot reproduce it with 7.0.0svn (Windows 2008 Server 64bit), anyway I am getting strange result
Number of nodes: 0 Number of primitives: 167 Number of points: 167 Number of lines: 0 Number of boundaries: 0 Number of centroids: 0 Number of areas: 0 Number of isles: 0 v.net complete. 0 lines (network arcs) written to output.
follow-up: 14 comment:12 by , 9 years ago
Sorry, the command should be:
v.net streets_wake points=schools_wake operation=connect thresh=1000 output=network
follow-up: 15 comment:13 by , 9 years ago
Replying to neteler:
We are (also upon request of the devs posting in this ticket who complained about the past release procedure) following a new release procedure:
http://trac.osgeo.org/grass/wiki/RFC/4_ReleaseProcedure
" Step 5 ... - RC2:
RC2 is released as almost final.
Step 6 - Bug squashing: & Release preparation:
A final, concerted bug squashing effort by all developers of no more than one week.
..."
Yes, but the first half of the sentence is just as important as the second in this procedure. And I don't see as much effort on that side as there needs to be for this kind of procedure to work... We're still learning :-)
I do think that it would be serious regression to release G7 with non-functional network analysis on Windows...
Unfortunately, I'm travelling this weekend+Monday and won't have much time in front of a computer. (Maybe another lesson for the release procedure: put important release dates at the end of a work week, not during the weekend, as I have the feeling most developers are more active during office hours...). I'll try to look at it this morning, but wifi connection is really slow, so just downloading different versions of the win installer means long waits. And I don't have a win dev chain installed and therefore cannot easily debug...
Moritz
follow-up: 18 comment:14 by , 9 years ago
Replying to annakrat:
Sorry, the command should be:
v.net streets_wake points=schools_wake operation=connect thresh=1000 output=network
Replying to annakrat:
Sorry, the command should be:
> v.net streets_wake points=schools_wake operation=connect thresh=1000 output=network
right, now it makes more sense. I can confirm crash in vlib
Podpis problému: Název události problému: APPCRASH Název aplikace: v.net.exe Verze aplikace: 7.0.0.0 Časové razítko aplikace: 54dd6fcd Název chybného modulu: libgrass_vector.7.0.0svn.dll Verze chybného modulu: 0.0.0.0 Časové razítko chybného modulu: 54dd6ae1 Kód výjimky: c0000005 Posun výjimky: 0003d935 Verze operačního systému: 6.0.6002.2.2.0.274.10 ID národního prostředí: 1029 Další informace 1: fd00 Další informace 2: ea6f5fe8924aaa756324d57f87834160 Další informace 3: fd00 Další informace 4: ea6f5fe8924aaa756324d57f87834160 Přečtěte si prohlášení o zásadách ochrany osobních údajů: http://go.microsoft.com/fwlink/?linkid=50163&clcid=0x0405
The last debug messages are:
D3/5: V2_read_line_nat(): line = 45191 D3/5: Vect__Read_line_nat: offset = 7334408 D3/5: type = 2, do_cats = 1 dead = 0 D3/5: n_cats = 1 D3/5: n_points = 12 D3/5: off = 7334617 D3/5: line = 45191 distance = 119.381284 D3/5: min distance found = 22.835685 D3/5: Vect_read_line(): line = 48182 D3/5: V2_read_line_nat(): line = 48182 D3/5: Vect__Read_line_nat: offset = 7826327 D3/5: type = 2, do_cats = 1 dead = 0 D3/5: n_cats = 1 D3/5: n_points = 3 D3/5: off = 7826392 D3/5: Vect_rewrite_line(): name = network, format = 0, level = 2, line/offset = 48182 D3/5: V2_read_line_nat(): line = 48182 D3/5: Vect__Read_line_nat: offset = 7826327 D3/5: type = 2, do_cats = 1 dead = 0 D3/5: n_cats = 1 D3/5: n_points = 3 D3/5: off = 7826392
follow-up: 22 comment:15 by , 9 years ago
Replying to mlennert: ...
I do think that it would be serious regression to release G7 with non-functional network analysis on Windows...
I guess that "final" only one week after RC2 is too close. But that's OT for this ticket.
Likely this bug had been spotted if there was a test case in place (and executed on Windows of course).
Anyone willing to write a test case for this line?
v.net streets_wake points=schools_wake operation=connect thresh=1000 output=network
comment:16 by , 9 years ago
| Priority: | critical → blocker |
|---|
comment:17 by , 9 years ago
Replying to neteler:
Replying to annakrat:
I just don't like releasing grass with a serious bug when we haven't even tried to fix it.
Well, it does not happen e.g. on Linux.
I am talking about postponing it max one week. Basically, my question is: can Markus Metz look at it soon enough?
No idea.
If not, then we can probably release it now.
Changes I see after RC1:
- r64200 diglib: add numerical stability to dig_test_for_intersection()
- r64198 diglib: add numerical stability to dig_distance2_point_to_line()
- r64196 diglib: add numerical stability to dig_x_intersect()
- many changes in http://trac.osgeo.org/grass/log/grass/branches/releasebranch_7_0/lib/vector/Vlib
These also do not respect the proposed release procedure:
"Any commits from that point [RC] on can only be well-tested, non-invasive bug fixes."
Many of these changes do not even seem to be bug fixes, but optimization. Typically the stuff that should have been tested in trunk and if stable integrated into the next point release... And, yes, tests should help, but they also would have to be run on different platforms before commits.
And my level of understanding does not allow me to understand what in there might cause a MSWin-specific issue. My highest contender, in light of Martin's debug info above is r64215.
Do I understand correctly that r64163 was just in time to be included into RC1 ?
Martin, could you rerun your windows builds to get versions before and after the above change, or is that too much work ?
Or maybe Glynn could have a look at these changes to see if there's anything obvious to more informed eyes than mine ?
Moritz
follow-up: 21 comment:18 by , 9 years ago
Replying to martinl:
it seems to crash at source:grass/trunk/vector/v.net/connect.c#L87
comment:19 by , 9 years ago
Probably it is a memory issue on Windows 32bit? --> "possibly lost: 15,516,703 bytes".
Also an "Uninitialised value was created by a stack allocation" - see below:
CMD="v.net streets_wake points=schools_wake operation=connect thresh=1000 output=network" valgrind --tool=memcheck --leak-check=yes --show-reachable=yes $CMD --o ... ==27244== 795,176 bytes in 41,775 blocks are indirectly lost in loss record 626 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x4E9708F: G__realloc (alloc.c:124) ==27244== by 0x57432A4: dig_node_alloc_line (struct_alloc.c:83) ==27244== by 0x574CA1B: dig_Rd_P_node (plus_struct.c:69) ==27244== by 0x5741F01: dig_load_plus (plus.c:226) ==27244== by 0x4C2CE79: Vect_open_topo (open.c:1152) ==27244== by 0x4C2D6DC: Vect__open_old (open.c:333) ==27244== by 0x4C2DFCE: Vect_open_old (open.c:566) ==27244== by 0x402C9F: main (main.c:65) ==27244== ==27244== 936,576 bytes in 19,512 blocks are possibly lost in loss record 627 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x4E96F38: G__malloc (alloc.c:39) ==27244== by 0x5743200: dig_alloc_node (struct_alloc.c:34) ==27244== by 0x5742B68: dig_add_node (plus_node.c:120) ==27244== by 0x574534C: add_line (plus_line.c:60) ==27244== by 0x574559A: dig_add_line (plus_line.c:147) ==27244== by 0x4C31DB0: Vect_build_nat (build_nat.c:99) ==27244== by 0x4C344D7: Vect_build_partial (build.c:882) ==27244== by 0x4C3459A: Vect_build (build.c:577) ==27244== by 0x402FC1: main (main.c:157) ==27244== ==27244== 1,085,808 bytes in 22,621 blocks are possibly lost in loss record 628 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x4E96F38: G__malloc (alloc.c:39) ==27244== by 0x5743200: dig_alloc_node (struct_alloc.c:34) ==27244== by 0x5742B68: dig_add_node (plus_node.c:120) ==27244== by 0x574549A: add_line (plus_line.c:95) ==27244== by 0x574559A: dig_add_line (plus_line.c:147) ==27244== by 0x4C31DB0: Vect_build_nat (build_nat.c:99) ==27244== by 0x4C344D7: Vect_build_partial (build.c:882) ==27244== by 0x4C3459A: Vect_build (build.c:577) ==27244== by 0x402FC1: main (main.c:157) ==27244== ==27244== 1,193,808 bytes in 49,742 blocks are indirectly lost in loss record 629 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x4E96F38: G__malloc (alloc.c:39) ==27244== by 0x5743339: dig_alloc_line (struct_alloc.c:128) ==27244== by 0x574CD0C: dig_Rd_P_line (plus_struct.c:165) ==27244== by 0x5741F9A: dig_load_plus (plus.c:236) ==27244== by 0x4C2CE79: Vect_open_topo (open.c:1152) ==27244== by 0x4C2D6DC: Vect__open_old (open.c:333) ==27244== by 0x4C2DFCE: Vect_open_old (open.c:566) ==27244== by 0x402C9F: main (main.c:65) ==27244== ==27244== 1,205,904 bytes in 50,246 blocks are possibly lost in loss record 630 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x4E96F38: G__malloc (alloc.c:39) ==27244== by 0x5743339: dig_alloc_line (struct_alloc.c:128) ==27244== by 0x5745252: add_line (plus_line.c:27) ==27244== by 0x574559A: dig_add_line (plus_line.c:147) ==27244== by 0x4C31DB0: Vect_build_nat (build_nat.c:99) ==27244== by 0x4C344D7: Vect_build_partial (build.c:882) ==27244== by 0x4C3459A: Vect_build (build.c:577) ==27244== by 0x402FC1: main (main.c:157) ==27244== ==27244== 1,256,112 bytes in 8,723 blocks are possibly lost in loss record 631 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x5B5DA65: RTreeAllocNode (node.c:88) ==27244== by 0x5B5E87D: RTreeAddBranch (node.c:587) ==27244== by 0x5B5CF27: RTreeInsertRect2M (indexm.c:135) ==27244== by 0x5B5D488: RTreeInsertRectM (indexm.c:231) ==27244== by 0x5B6001A: RTreeInsertRect (index.c:324) ==27244== by 0x5747325: dig_spidx_add_line (spindex.c:339) ==27244== by 0x574527B: add_line (plus_line.c:33) ==27244== by 0x574559A: dig_add_line (plus_line.c:147) ==27244== by 0x4C31DB0: Vect_build_nat (build_nat.c:99) ==27244== by 0x4C344D7: Vect_build_partial (build.c:882) ==27244== by 0x4C3459A: Vect_build (build.c:577) ==27244== ==27244== 1,412,160 bytes in 29,420 blocks are possibly lost in loss record 632 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x5B5B14C: RTreeAllocBoundary (rect.c:86) ==27244== by 0x5B5DA7D: RTreeAllocNode (node.c:91) ==27244== by 0x5B5E87D: RTreeAddBranch (node.c:587) ==27244== by 0x5B5CF27: RTreeInsertRect2M (indexm.c:135) ==27244== by 0x5B5D488: RTreeInsertRectM (indexm.c:231) ==27244== by 0x5B6001A: RTreeInsertRect (index.c:324) ==27244== by 0x5747261: dig_spidx_add_node (spindex.c:305) ==27244== by 0x5742BAC: dig_add_node (plus_node.c:127) ==27244== by 0x574534C: add_line (plus_line.c:60) ==27244== by 0x574559A: dig_add_line (plus_line.c:147) ==27244== by 0x4C31DB0: Vect_build_nat (build_nat.c:99) ==27244== ==27244== 1,807,056 bytes in 37,647 blocks are possibly lost in loss record 633 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x5B5B14C: RTreeAllocBoundary (rect.c:86) ==27244== by 0x5B5DA7D: RTreeAllocNode (node.c:91) ==27244== by 0x5B5E87D: RTreeAddBranch (node.c:587) ==27244== by 0x5B5CF27: RTreeInsertRect2M (indexm.c:135) ==27244== by 0x5B5D488: RTreeInsertRectM (indexm.c:231) ==27244== by 0x5B6001A: RTreeInsertRect (index.c:324) ==27244== by 0x5747261: dig_spidx_add_node (spindex.c:305) ==27244== by 0x5742BAC: dig_add_node (plus_node.c:127) ==27244== by 0x574549A: add_line (plus_line.c:95) ==27244== by 0x574559A: dig_add_line (plus_line.c:147) ==27244== by 0x4C31DB0: Vect_build_nat (build_nat.c:99) ==27244== ==27244== 2,005,680 bytes in 41,785 blocks are indirectly lost in loss record 634 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x4E96F38: G__malloc (alloc.c:39) ==27244== by 0x5743200: dig_alloc_node (struct_alloc.c:34) ==27244== by 0x574CA09: dig_Rd_P_node (plus_struct.c:66) ==27244== by 0x5741F01: dig_load_plus (plus.c:226) ==27244== by 0x4C2CE79: Vect_open_topo (open.c:1152) ==27244== by 0x4C2D6DC: Vect__open_old (open.c:333) ==27244== by 0x4C2DFCE: Vect_open_old (open.c:566) ==27244== by 0x402C9F: main (main.c:65) ==27244== ==27244== 3,768,288 bytes in 78,506 blocks are possibly lost in loss record 635 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x5B5B14C: RTreeAllocBoundary (rect.c:86) ==27244== by 0x5B5DA7D: RTreeAllocNode (node.c:91) ==27244== by 0x5B5E87D: RTreeAddBranch (node.c:587) ==27244== by 0x5B5CF27: RTreeInsertRect2M (indexm.c:135) ==27244== by 0x5B5D488: RTreeInsertRectM (indexm.c:231) ==27244== by 0x5B6001A: RTreeInsertRect (index.c:324) ==27244== by 0x5747325: dig_spidx_add_line (spindex.c:339) ==27244== by 0x574527B: add_line (plus_line.c:33) ==27244== by 0x574559A: dig_add_line (plus_line.c:147) ==27244== by 0x4C31DB0: Vect_build_nat (build_nat.c:99) ==27244== by 0x4C344D7: Vect_build_partial (build.c:882) ==27244== ==27244== 8,094,124 (2,032 direct, 8,092,092 indirect) bytes in 1 blocks are definitely lost in loss record 636 of 636 ==27244== at 0x4A06BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==27244== by 0x4E96F38: G__malloc (alloc.c:39) ==27244== by 0x402C7C: main (main.c:63) ==27244== ==27244== LEAK SUMMARY: ==27244== definitely lost: 11,139 bytes in 95 blocks ==27244== indirectly lost: 8,126,364 bytes in 250,982 blocks ==27244== possibly lost: 15,516,703 bytes in 405,314 blocks ==27244== still reachable: 99,070 bytes in 192 blocks ==27244== suppressed: 0 bytes in 0 blocks ==27244== ==27244== For counts of detected and suppressed errors, rerun with: -v ==27244== Use --track-origins=yes to see where uninitialised values come from ==27244== ERROR SUMMARY: 2466 errors from 258 contexts (suppressed: 1 from 1)
I also see using --track-origins=yes some other issue:
valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --track-origins=yes $CMD --o ... ==27437== Conditional jump or move depends on uninitialised value(s) ==27437== at 0x4C4CB22: Vect_line_prune (line.c:290) ==27437== by 0x4033D2: connect_arcs (connect.c:96) ==27437== by 0x402F18: main (main.c:141) ==27437== Uninitialised value was created by a stack allocation ==27437== at 0x4030C2: connect_arcs (connect.c:23) ==27437== ==27437== Conditional jump or move depends on uninitialised value(s) ==27437== at 0x4C4CB24: Vect_line_prune (line.c:290) ==27437== by 0x4033D2: connect_arcs (connect.c:96) ==27437== by 0x402F18: main (main.c:141) ==27437== Uninitialised value was created by a stack allocation ==27437== at 0x4030C2: connect_arcs (connect.c:23) ==27437== ==27437== Conditional jump or move depends on uninitialised value(s) ==27437== at 0x4C4CB22: Vect_line_prune (line.c:290) ==27437== by 0x403325: connect_arcs (connect.c:85) ==27437== by 0x402F18: main (main.c:141) ==27437== Uninitialised value was created by a stack allocation ==27437== at 0x4030C2: connect_arcs (connect.c:23) ==27437== ... Copying attributes... ...
comment:20 by , 9 years ago
On ~AMD64 Linux I don't see any crash but Valgrind is complaining about use of uninitialized values. Seems that there is a problem when vector is not a 3D one. Don't know it could be the source of a crash in the Windows version.
Still in the light of recent Martin comments it could be the case.
Markus - leak-check doesn't matter unless we are optimizing code. Lost memory is just wasted memory - it doesn't harm (except consuming few bytes of RAM).
==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x5FBA939: dig_line_box (box.c:51) ==10082== by 0x4E74AE2: V2__add_line_to_topo_nat (write_nat.c:895) ==10082== by 0x4E752A4: V2_rewrite_line_nat (write_nat.c:228) ==10082== by 0x4E51082: Vect_rewrite_line (write.c:231) ==10082== by 0x405979: connect_arcs (connect.c:87) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23) ==10082== ==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x4E63D63: Vect_box_extend (box.c:126) ==10082== by 0x4E74B47: V2__add_line_to_topo_nat (write_nat.c:908) ==10082== by 0x4E752A4: V2_rewrite_line_nat (write_nat.c:228) ==10082== by 0x4E51082: Vect_rewrite_line (write.c:231) ==10082== by 0x405979: connect_arcs (connect.c:87) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23) ==10082== ==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x5FBA939: dig_line_box (box.c:51) ==10082== by 0x4E74AE2: V2__add_line_to_topo_nat (write_nat.c:895) ==10082== by 0x4E75161: V2_write_line_nat (write_nat.c:80) ==10082== by 0x4E50FA3: Vect_write_line (write.c:189) ==10082== by 0x405856: connect_arcs (connect.c:99) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23) ==10082== ==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x5FBA944: dig_line_box (box.c:53) ==10082== by 0x4E74AE2: V2__add_line_to_topo_nat (write_nat.c:895) ==10082== by 0x4E75161: V2_write_line_nat (write_nat.c:80) ==10082== by 0x4E50FA3: Vect_write_line (write.c:189) ==10082== by 0x405856: connect_arcs (connect.c:99) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23) ==10082== ==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x4E63D63: Vect_box_extend (box.c:126) ==10082== by 0x4E74B47: V2__add_line_to_topo_nat (write_nat.c:908) ==10082== by 0x4E75161: V2_write_line_nat (write_nat.c:80) ==10082== by 0x4E50FA3: Vect_write_line (write.c:189) ==10082== by 0x405856: connect_arcs (connect.c:99) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23) ==10082== ==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x5FBA8D8: dig_line_box (box.c:51) ==10082== by 0x4E74AE2: V2__add_line_to_topo_nat (write_nat.c:895) ==10082== by 0x4E75161: V2_write_line_nat (write_nat.c:80) ==10082== by 0x4E50FA3: Vect_write_line (write.c:189) ==10082== by 0x405A1B: connect_arcs (connect.c:122) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23) ==10082== ==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x5FBA8D8: dig_line_box (box.c:51) ==10082== by 0x4E74AE2: V2__add_line_to_topo_nat (write_nat.c:895) ==10082== by 0x4E752A4: V2_rewrite_line_nat (write_nat.c:228) ==10082== by 0x4E51082: Vect_rewrite_line (write.c:231) ==10082== by 0x405979: connect_arcs (connect.c:87) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23) ==10082== ==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x4E68F68: Vect_line_prune (line.c:290) ==10082== by 0x40582E: connect_arcs (connect.c:96) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23) ==10082== ==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x4E68F6A: Vect_line_prune (line.c:290) ==10082== by 0x40582E: connect_arcs (connect.c:96) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23) ==10082== ==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x4E68F68: Vect_line_prune (line.c:290) ==10082== by 0x40579A: connect_arcs (connect.c:85) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23) ==10082== ==10082== Conditional jump or move depends on uninitialised value(s) ==10082== at 0x4E68F6A: Vect_line_prune (line.c:290) ==10082== by 0x40579A: connect_arcs (connect.c:85) ==10082== by 0x403164: main (main.c:146) ==10082== Uninitialised value was created by a stack allocation ==10082== at 0x405550: connect_arcs (connect.c:23)
follow-up: 23 comment:21 by , 9 years ago
Replying to martinl:
Replying to martinl:
it seems to crash at source:grass/trunk/vector/v.net/connect.c#L87
more precisely it's somewhere here: source:grass/trunk/lib/vector/Vlib/write.c#L231. In my case before calling rewrite fn from array points = 04033a60, inside V2_rewrite_line_nat() it's lost points = 00000002.
comment:22 by , 9 years ago
follow-up: 24 comment:23 by , 9 years ago
Replying to martinl:
Replying to martinl:
Replying to martinl:
it seems to crash at source:grass/trunk/vector/v.net/connect.c#L87
more precisely it's somewhere here: source:grass/trunk/lib/vector/Vlib/write.c#L231. In my case before calling rewrite fn from array
points = 04033a60, insideV2_rewrite_line_nat()it's lostpoints = 00000002.
The bug was differing function parameter types in the fn arrays, causing memory corruption. Fixed in trunk r64644, tested on MS Windows and Linux. I will backport the fix if the nightly build of trunk works by tomorrow.
follow-up: 25 comment:24 by , 9 years ago
Replying to mmetz:
more precisely it's somewhere here: source:grass/trunk/lib/vector/Vlib/write.c#L231. In my case before calling rewrite fn from array
points = 04033a60, insideV2_rewrite_line_nat()it's lostpoints = 00000002.The bug was differing function parameter types in the fn arrays, causing memory corruption. Fixed in trunk r64644, tested on MS Windows and Linux. I will backport the fix if the nightly build of trunk works by tomorrow.
I have created extra builds (no. 1225), and tested G71. It seems to be fixed. Thanks! Could you backport it today?
follow-up: 26 comment:25 by , 9 years ago
Replying to martinl:
Replying to mmetz:
more precisely it's somewhere here: source:grass/trunk/lib/vector/Vlib/write.c#L231. In my case before calling rewrite fn from array
points = 04033a60, insideV2_rewrite_line_nat()it's lostpoints = 00000002.The bug was differing function parameter types in the fn arrays, causing memory corruption. Fixed in trunk r64644, tested on MS Windows and Linux. I will backport the fix if the nightly build of trunk works by tomorrow.
I have created extra builds (no. 1225), and tested G71. It seems to be fixed. Thanks! Could you backport it today?
OK, backported to relbr70 in r64654.
follow-up: 27 comment:26 by , 9 years ago
Replying to mmetz:
Replying to martinl:
Replying to mmetz:
more precisely it's somewhere here: source:grass/trunk/lib/vector/Vlib/write.c#L231. In my case before calling rewrite fn from array
points = 04033a60, insideV2_rewrite_line_nat()it's lostpoints = 00000002.The bug was differing function parameter types in the fn arrays, causing memory corruption. Fixed in trunk r64644, tested on MS Windows and Linux. I will backport the fix if the nightly build of trunk works by tomorrow.
I have created extra builds (no. 1225), and tested G71. It seems to be fixed. Thanks! Could you backport it today?
OK, backported to relbr70 in r64654.
I have also fixed valgrind's uninitialized value warnings in r64656,7 (trunk, relbr70).
follow-up: 28 comment:27 by , 9 years ago
comment:28 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Replying to martinl:
Replying to mmetz:
OK, backported to relbr70 in r64654.
I have also fixed valgrind's uninitialized value warnings in r64656,7 (trunk, relbr70).
I have tested fresh build of G70 and it's seems to be fixed. Anyone can confirm it? Thanks.
Same here. No more crash and results seem identical to those on GNU/Linux.
Closing this now.
Thanks a lot, MarkusM !
Moritz
follow-up: 30 comment:29 by , 9 years ago
The test for v.net is now at 50%. This is a little bit suspicious. The values changed from yesterday before the last fixes (r64644, r64656). Test suite for v.net was added in r64639 and the values were obtained before the last fixes which can mean that r64644 or r64656 changed the results. Which results are the right ones? Is this even expected?
Test results:
- v.net test for r64642
- http://fatra.cnr.ncsu.edu/grassgistests/reports_for_date-2015-02-17-08-00/report_for_nc_spm_08_grass7_nc/vector/v.net/test_v_net/index.html v.net test for r64658]
Current test output:
======================================================================
FAIL: test_connect (__main__.TestVNet)
Test
----------------------------------------------------------------------
Traceback (most recent call last):
File "vector/v.net/testsuite/test_v_net.py", line 36, in test_connect
self.assertVectorFitsTopoInfo(vector=self.network, reference=topology)
File "etc/python/grass/gunittest/case.py", line 309, in assertVectorFitsTopoInfo
precision=0)
File "etc/python/grass/gunittest/case.py", line 202, in assertModuleKeyValue
self.fail(self._formatMessage(msg, stdMsg))
AssertionError: v.info map=test_vnet layer=1 -t difference:
mismatch values (key, reference, actual): [('lines', 50080, 50069)]
command: v.info map=test_vnet layer=1 -t {'map': 'test_vnet', 'flags': 't'}
======================================================================
FAIL: test_connect_snap (__main__.TestVNet)
Test
----------------------------------------------------------------------
Traceback (most recent call last):
File "vector/v.net/testsuite/test_v_net.py", line 45, in test_connect_snap
self.assertVectorFitsTopoInfo(vector=self.network, reference=topology)
File "etc/python/grass/gunittest/case.py", line 309, in assertVectorFitsTopoInfo
precision=0)
File "etc/python/grass/gunittest/case.py", line 202, in assertModuleKeyValue
self.fail(self._formatMessage(msg, stdMsg))
AssertionError: v.info map=test_vnet layer=1 -t difference:
mismatch values (key, reference, actual): [('lines', 49913, 49902)]
command: v.info map=test_vnet layer=1 -t {'map': 'test_vnet', 'flags': 't'}
I'm getting the same results locally as on the test server.
To test yourself:
# start GRASS session in nc_smp_08_grass7 Location and then cd vector/v.net/testsuite python test_v_net.py
For more complex output:
# start GRASS session in any Location and then python -m grass.gunittest.main --location nc_smp_08_grass7 --location-type nc
follow-ups: 31 32 comment:30 by , 9 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → reopened |
Replying to wenzeslaus:
The test for v.net is now at 50%. This is a little bit suspicious. The values changed from yesterday before the last fixes (r64644, r64656). Test suite for v.net was added in r64639 and the values were obtained before the last fixes which can mean that r64644 or r64656 changed the results. Which results are the right ones? Is this even expected?
MarkusM is the only one who can tell for sure, but I would not be surprised that changes in topology handling induce changes in primitive counts.
At least I can confirm the difference between RC2 and current releasebranch results.
Another strange thing I noticed: using the -s (snap nodes to network) flag, I get
"156 lines (network arcs) written to output"
Why are the new network arcs written when nodes are snapped to the network ?
Reopening the bug for now...
Moritz
comment:31 by , 9 years ago
| Priority: | blocker → critical |
|---|
Replying to mlennert:
Replying to wenzeslaus:
The test for v.net is now at 50%. This is a little bit suspicious. The values changed from yesterday before the last fixes (r64644, r64656). Test suite for v.net was added in r64639 and the values were obtained before the last fixes which can mean that r64644 or r64656 changed the results. Which results are the right ones? Is this even expected?
MarkusM is the only one who can tell for sure, but I would not be surprised that changes in topology handling induce changes in primitive counts.
At least I can confirm the difference between RC2 and current releasebranch results.
Another strange thing I noticed: using the -s (snap nodes to network) flag, I get
"156 lines (network arcs) written to output"
Why are the new network arcs written when nodes are snapped to the network ?
Reopening the bug for now...
But downgrading it as I don't think this merits delaying the release.
follow-up: 33 comment:32 by , 9 years ago
Replying to mlennert:
Replying to wenzeslaus:
The test for v.net is now at 50%. This is a little bit suspicious. The values changed from yesterday before the last fixes (r64644, r64656). Test suite for v.net was added in r64639 and the values were obtained before the last fixes which can mean that r64644 or r64656 changed the results. Which results are the right ones? Is this even expected?
MarkusM is the only one who can tell for sure, but I would not be surprised that changes in topology handling induce changes in primitive counts.
The difference is caused by the fix for the uninitialized values in v.net, therefore I am sure that the new result is correct. Uninitialized double values (here: z coordinates) can have weird effects, I noticed that earlier somewhere else. Unfortunately, this bug has been present in v.net since GRASS 6.4.0 or earlier.
At least I can confirm the difference between RC2 and current releasebranch results.
Another strange thing I noticed: using the -s (snap nodes to network) flag, I get
"156 lines (network arcs) written to output"
Why are the new network arcs written when nodes are snapped to the network ?
Because a line is broken up into 2 lines at the point on the line closest to the node, thus the old line is modified and a new line is written out and reported as a new arc. Of course only if the point on the line closest to the node is not one of the line's end points.
follow-up: 34 comment:33 by , 9 years ago
| Resolution: | → fixed |
|---|---|
| Status: | reopened → closed |
Replying to mmetz:
Replying to mlennert:
Replying to wenzeslaus:
The test for v.net is now at 50%. This is a little bit suspicious. The values changed from yesterday before the last fixes (r64644, r64656). Test suite for v.net was added in r64639 and the values were obtained before the last fixes which can mean that r64644 or r64656 changed the results. Which results are the right ones? Is this even expected?
MarkusM is the only one who can tell for sure, but I would not be surprised that changes in topology handling induce changes in primitive counts.
The difference is caused by the fix for the uninitialized values in
v.net, therefore I am sure that the new result is correct. Uninitialized double values (here: z coordinates) can have weird effects, I noticed that earlier somewhere else. Unfortunately, this bug has been present inv.netsince GRASS 6.4.0 or earlier.
OK, I updated the test with the new values.
comment:34 by , 9 years ago
Replying to annakrat:
Replying to mmetz:
Replying to mlennert:
Replying to wenzeslaus:
The test for v.net is now at 50%. This is a little bit suspicious. The values changed from yesterday before the last fixes (r64644, r64656). Test suite for v.net was added in r64639 and the values were obtained before the last fixes which can mean that r64644 or r64656 changed the results. Which results are the right ones? Is this even expected?
MarkusM is the only one who can tell for sure, but I would not be surprised that changes in topology handling induce changes in primitive counts.
The difference is caused by the fix for the uninitialized values in
v.net, therefore I am sure that the new result is correct. Uninitialized double values (here: z coordinates) can have weird effects, I noticed that earlier somewhere else. Unfortunately, this bug has been present inv.netsince GRASS 6.4.0 or earlier.OK, I updated the test with the new values.
You can convert the old result to the new result by removing all lines with zero length v.clean type=line tool=rmline. These zero length lines have been caused by the uninitialized z value and are ignored in subsequent network analyses. That means the new result is cleaner, but the noise in the old result should not cause errors.
Replying to mlennert:
I could reproduce this crash on another machine running Windows XP natively.
Increasing the priority as this makes any work on the network modules impossible.