[GRASS-dev] [GRASS GIS] #2583: v.net: crash on Windows 7

GDAL · February 10, 2015, 4:27pm

#2583: v.net: crash on Windows 7
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: v.net crash | Platform: MSWindows 7
Cpu: Unspecified |
-------------------------+--------------------------------------------------
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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 10, 2015, 6:01pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: v.net crash | Platform: MSWindows 7
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by mlennert):

* priority: normal => critical

Comment:

Replying to [ticket:2583 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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2583#comment:1>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 11, 2015, 11:46pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: v.net crash | Platform: MSWindows 7
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by mlennert):

Can anyone using Windows confirm this bug ?

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2583#comment:2>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 13, 2015, 3:46pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: v.net crash | Platform: MSWindows 7
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by annakrat):

* priority: critical => blocker

Comment:

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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2583#comment:3>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 14, 2015, 5:07pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: v.net crash | Platform: MSWindows 7
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:4>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 14, 2015, 5:19pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: v.net crash | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by annakrat):

* platform: MSWindows 7 => MSWindows 8

Comment:

Replying to [comment:4 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.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:5>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 14, 2015, 5:36pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: v.net crash | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by neteler):

Replying to [comment:5 annakrat]:
> Replying to [comment:4 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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2583#comment:6>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 14, 2015, 5:58pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: v.net crash | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by annakrat):

Replying to [comment:6 neteler]:
> Replying to [comment:5 annakrat]:
> > Replying to [comment:4 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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2583#comment:7>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 14, 2015, 6:14pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: v.net crash | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by neteler):

Replying to [comment:7 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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2583#comment:8>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 14, 2015, 6:25pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: Default | Version: svn-releasebranch70
Keywords: v.net crash | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by annakrat):

* priority: blocker => critical

Comment:

Replying to [comment:8 neteler]:
> Replying to [comment:7 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.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2583#comment:9>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 14, 2015, 7:06pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: LibVector | Version: svn-releasebranch70
Keywords: v.net | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by neteler):

* keywords: v.net crash => v.net
* component: Default => LibVector

Comment:

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

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/2583#comment:10>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 14, 2015, 11:55pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: LibVector | Version: svn-releasebranch70
Keywords: v.net | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by martinl):

Replying to [comment:3 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.
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:11>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 14, 2015, 11:57pm

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: LibVector | Version: svn-releasebranch70
Keywords: v.net | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by annakrat):

Sorry, the command should be:

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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:12>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 15, 2015, 8:41am

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: LibVector | Version: svn-releasebranch70
Keywords: v.net | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by mlennert):

Replying to [comment:6 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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:13>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 15, 2015, 9:04am

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: LibVector | Version: svn-releasebranch70
Keywords: v.net | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by martinl):

Replying to [comment:12 annakrat]:
> Sorry, the command should be:
>
> {{{
> v.net streets_wake points=schools_wake operation=connect thresh=1000
output=network
> }}}

Replying to [comment:12 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
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:14>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 15, 2015, 9:21am

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: critical | Milestone: 7.0.0
Component: LibVector | Version: svn-releasebranch70
Keywords: v.net | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by neteler):

Replying to [comment:13 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
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:15>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 15, 2015, 9:21am

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: LibVector | Version: svn-releasebranch70
Keywords: v.net | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------
Changes (by neteler):

* priority: critical => blocker

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:16>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 15, 2015, 9:37am

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: LibVector | Version: svn-releasebranch70
Keywords: v.net | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by mlennert):

Replying to [comment:8 neteler]:
> Replying to [comment:7 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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:17>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 15, 2015, 9:44am

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: LibVector | Version: svn-releasebranch70
Keywords: v.net | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(by martinl):

Replying to [comment:14 martinl]:

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

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:18>
GRASS GIS <http://grass.osgeo.org>

GDAL · February 15, 2015, 9:50am

#2583: v.net: crash on Windows
-------------------------+--------------------------------------------------
Reporter: mlennert | Owner: grass-dev@…
Type: defect | Status: new
Priority: blocker | Milestone: 7.0.0
Component: LibVector | Version: svn-releasebranch70
Keywords: v.net | Platform: MSWindows 8
Cpu: Unspecified |
-------------------------+--------------------------------------------------

Comment(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...
...
}}}

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/2583#comment:19>
GRASS GIS <http://grass.osgeo.org>