[GRASS-dev] v.select: increasing memory consumption

Markus Metz markus.metz.giswork at gmail.com
Thu Feb 21 06:22:43 PST 2019


Hi Stefan,

On Thu, Feb 21, 2019 at 2:20 PM Stefan Blumentrath <
Stefan.Blumentrath at nina.no> wrote:
>
> Hi again,
>
> Please find below the output from a run of the problematic command with
valgrind (note that ainput data (points) are stored in PostGIS
(v.external)).
>
> Hope that helps to shed some light…
>
> Cheers
>
> Stefan
>
> valgrind --leak-check=yes v.select ainput=grid100 binput=landNorway
output=testNorwayGrid
>
>  [...]
>
> ==13217== LEAK SUMMARY:
> ==13217==    definitely lost: 964 bytes in 39 blocks
> ==13217==    indirectly lost: 72 bytes in 10 blocks
> ==13217==      possibly lost: 79 bytes in 4 blocks
> ==13217==    still reachable: 9,025,026,330 bytes in 188,201,312 blocks

this is the problem, please run valgrind again with
--show-reachable=yes

we need to find out where these 9,025,026,330 bytes have been allocated.

Markus M

>
> From: Markus Metz <markus.metz.giswork at gmail.com>
> Sent: lørdag 19. januar 2019 22:17
> To: Stefan Blumentrath <Stefan.Blumentrath at nina.no>
> Cc: Markus Neteler <neteler at osgeo.org>; GRASS developers list (
grass-dev at lists.osgeo.org) <grass-dev at lists.osgeo.org>
> Subject: Re: [GRASS-dev] v.select: increasing memory consumption
>
>
>
>
>
> On Fri, Jan 18, 2019 at 8:29 AM Stefan Blumentrath <
Stefan.Blumentrath at nina.no> wrote:
> >
> > THanks, we`ll try and report back.
> >
> > -----Original Message-----
> > From: Markus Neteler <neteler at osgeo.org>
> > Sent: fredag 18. januar 2019 07:52
> > To: Stefan Blumentrath <Stefan.Blumentrath at nina.no>
> > Cc: GRASS developers list (grass-dev at lists.osgeo.org) <
grass-dev at lists.osgeo.org>
> > Subject: Re: [GRASS-dev] v.select: increasing memory consumption
> >
> > Hi,
> >
> > On Thu, Jan 17, 2019 at 2:11 PM Stefan Blumentrath <
Stefan.Blumentrath at nina.no> wrote:
> > >
> > > Dear all,
> > >
> > > A colleague of mine just experienced that v.select in GRASS 7.4.3
(from UbuntuGIS) did not stop allocating memory until the server (Ubuntu
16.04) almost died and he killed the process.
> > >
> > > Is that a bug or would v.select have stopped allocating memory at
some point before the system gets unusable? Or is this something the user
should take care of? If I remember correctly there is a “LOW_MEM option”
for v.in.ogr would such a thing be needed here to.
> > >
> > > In a multi-user environment this can be a bit tricky…
> >
> > yeah!
> >
> > > Any hints? Should I open a ticket (probably hard to reproduce with
small test-dataset)?
> >
> > Please re-run the job with "valgrind", see
> >
> > https://grasswiki.osgeo.org/wiki/GRASS_Debugging#Using_Valgrind
> >
>
> > That will give insights about potential memory leaks. He/you may CTRL-C
it on the way to keep the server alive.
>
>
>
> A simple run fo v.select with valgrind does not show any memory leak
(increase of memory consumption within a loop). Can you provide the test
command and ideally also the data causing the problem? That would help with
debugging.
>
>
>
> Markus M
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20190221/dba2dc04/attachment.html>


More information about the grass-dev mailing list