Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#2583 closed defect (fixed)

v.net: crash on Windows

Reported by: mlennert Owned by: grass-dev@…
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 in reply to:  description Changed 5 years ago by mlennert

Priority: normalcritical
Summary: v.net: crash on Windows 7v.net: crash on Windows

Replying to mlennert:

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 could reproduce this crash on another machine running Windows XP natively.

Increasing the priority as this makes any work on the network modules impossible.

comment:2 Changed 5 years ago by mlennert

Can anyone using Windows confirm this bug ?

comment:3 Changed 5 years ago by annakrat

Priority: criticalblocker

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.

comment:4 Changed 5 years ago by 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?

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.

comment:5 in reply to:  4 ; Changed 5 years ago by annakrat

Platform: MSWindows 7MSWindows 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.

comment:6 in reply to:  5 ; Changed 5 years ago by 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).

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.

comment:7 in reply to:  6 ; Changed 5 years ago by annakrat

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.

comment:8 in reply to:  7 ; Changed 5 years ago by 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:

Too bad.

comment:9 in reply to:  8 Changed 5 years ago by annakrat

Priority: blockercritical

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:

Too bad.

Ok, I downgraded it since this discussion leads to nowhere.

comment:10 Changed 5 years ago by neteler

Component: DefaultLibVector
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 in reply to:  3 Changed 5 years ago by martinl

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.

comment:12 Changed 5 years ago by annakrat

Sorry, the command should be:

v.net streets_wake points=schools_wake operation=connect thresh=1000 output=network

comment:13 in reply to:  6 ; Changed 5 years ago by mlennert

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

comment:14 in reply to:  12 ; Changed 5 years ago by martinl

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

comment:15 in reply to:  13 ; Changed 5 years ago by neteler

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 Changed 5 years ago by neteler

Priority: criticalblocker

comment:17 Changed 5 years ago by mlennert

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:

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

comment:18 in reply to:  14 ; Changed 5 years ago by martinl

Replying to martinl:

it seems to crash at source:grass/trunk/vector/v.net/connect.c#L87

comment:19 Changed 5 years ago by neteler

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 Changed 5 years ago by marisn

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)

comment:21 in reply to:  18 ; Changed 5 years ago by 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, inside V2_rewrite_line_nat() it's lost points = 00000002.

comment:22 in reply to:  15 Changed 5 years ago by annakrat

Replying to neteler:

Anyone willing to write a test case for this line?

v.net streets_wake points=schools_wake operation=connect thresh=1000 output=network

Done in r64639.

comment:23 in reply to:  21 ; Changed 5 years ago by mmetz

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, inside V2_rewrite_line_nat() it's lost points = 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.

comment:24 in reply to:  23 ; Changed 5 years ago by 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, inside V2_rewrite_line_nat() it's lost points = 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?

comment:25 in reply to:  24 ; Changed 5 years ago by 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, inside V2_rewrite_line_nat() it's lost points = 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.

comment:26 in reply to:  25 ; Changed 5 years ago by mmetz

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, inside V2_rewrite_line_nat() it's lost points = 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).

comment:27 in reply to:  26 ; Changed 5 years ago by 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.

comment:28 in reply to:  27 Changed 5 years ago by mlennert

Resolution: fixed
Status: newclosed

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

comment:29 Changed 5 years ago by 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?

Test results:

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

comment:30 in reply to:  29 ; Changed 5 years ago by mlennert

Resolution: fixed
Status: closedreopened

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 in reply to:  30 Changed 5 years ago by mlennert

Priority: blockercritical

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.

comment:32 in reply to:  30 ; Changed 5 years ago by 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 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.

comment:33 in reply to:  32 ; Changed 5 years ago by annakrat

Resolution: fixed
Status: reopenedclosed

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 in v.net since GRASS 6.4.0 or earlier.

OK, I updated the test with the new values.

comment:34 in reply to:  33 Changed 5 years ago by mmetz

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 in v.net since 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.

Note: See TracTickets for help on using tickets.