Re: [GRASS-dev] v.net.visibility memory leak? - was Re: [GRASS-user] traveling salesman problem in air
Markus Metz wrote:
I remember a discussion in the dev ml, I think with the osgeo4w
installer, that memory allocated with malloc/calloc/realloc should be
free-d with free, not G_free. If this is the case, then there is a
problem in the vector libs, because space for a struct line_pnts * is
allocated with calloc and free-d with G_free, and relevant (or all)
calls to malloc/calloc/realloc/free in diglib should be replaced with
G_malloc etc. What to do?
GRASS code should always use the G_* versions unless there is a clear
reason not to, e.g. if the pointer will be passed to an external
library which will assume ownership of it.
==17614== 449,106 bytes in 56 blocks are still reachable in loss record 10
of 16
==17614==at 0x4C2136E: malloc (vg_replace_malloc.c:207)
==17614==by 0x529603E: G__malloc (alloc.c:41)
==17614==by 0x52CE929: G_store (store.c:36)
==17614==by 0x52C29D9: G_set_program_name (progrm_nme.c:52)
==17614==by 0x52AEAD2: G__gisinit (gisinit.c:51)
==17614==by 0x402D97: main (main.c:42)
Need for a complement to G_gisinit that free-s that memory?
Nope.
Single-instance allocations don't need to be free()d; they can remain
until the process terminates.
Explicitly freeing memory when termination is imminent is a waste of
resources (e.g. CPU cycles, and I/O bandwidth in the case where free()
causes swapped-out memory to be swapped back in). It's colloquially
referred to as rearranging the deckchairs on the Titanic.
In OO code, where you need to call destructors upon termination for
other reasons, it's quite common to override free() with a no-op as
soon as you are committed to termination, in order to avoid this
issue.
==17614==
==17614== LEAK SUMMARY:
==17614==definitely lost: 7,604 bytes in 42 blocks.
==17614==indirectly lost: 1,200 bytes in 3 blocks.
==17614== possibly lost: 0 bytes in 0 blocks.
==17614==still reachable: 73,854,014 bytes in 414,618 blocks.
==17614== suppressed: 0 bytes in 0 blocks.
not much changed...
If Vect_set_release_support() does not cause a severe time penalty, I
would recommend to use it. IMHO 73,854,014 - 444,026 (previous result)
bytes = ca. 70 MB lingering around in memory is a bit unnecessary.
That should only be done if vectors will be closed signficantly prior
to termination, e.g.:
for (i = 0; i nvects; i++) {
vect = Vect_open_old(...);
...
Vect_close(vect);
}
Valgrind highlights *potential* issues; it isn't omniscient.
[Nor is it an angry god which must be appeased with a sacrifice of
SSH keys.]
--
Glynn Clements gl...@gclements.plus.com
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS-user] Label crash
On Apr 17, 2009, at 4:24 AM, Markus Neteler wrote: No problem, looks fine. It seems to be Mac specific. Yes, it's a Mac problem. Something that changed in OSX 10.5. And I get the following repeated a whole bunch of times: The process has forked and you cannot use this CoreFoundation functionality safely. You MUST exec(). Break on __THE_PROCESS_HAS_FORKED_AND_YOU_CANNOT_USE_THIS_COREFOUNDATION_FUNCTIONALITY___YOU_MUST_EXEC__ () to debug. The same thing happens if I use d.mon start=PNG. could fork() in lib/driver/main.c be the problem? Very possible. But it's only forks that make it into OSX CoreFoundation. I see a lot of forks in the GRASS source and this is the only one (so far) that has caused the CoreFoundation problem, but maybe they're just waiting to cause trouble. In this case, Freetype gets into corefoundation. I just tried a X monitor, same error. ... ah, we have a bug report already: http://trac.osgeo.org/grass/ticket/377 Michael mentions labels and the forking problem, though the report is for a more specific problem. - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ First Pogril: Why is life like sticking your head in a bucket filled with hyena offal? Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal? First Pogril: I don't know either. Wretched, isn't it? -HitchHiker's Guide to the Galaxy ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] v.net.visibility memory leak? - was Re: [GRASS-user] traveling salesman problem in air
Glynn Clements wrote:
Markus Metz wrote:
I remember a discussion in the dev ml, I think with the osgeo4w
installer, that memory allocated with malloc/calloc/realloc should be
free-d with free, not G_free. If this is the case, then there is a
problem in the vector libs, because space for a struct line_pnts * is
allocated with calloc and free-d with G_free, and relevant (or all)
calls to malloc/calloc/realloc/free in diglib should be replaced with
G_malloc etc. What to do?
GRASS code should always use the G_* versions unless there is a clear
reason not to, e.g. if the pointer will be passed to an external
library which will assume ownership of it.
OK, so lib/vector/diglib needs to be updated. What about dglib and
rtree? AFAICT they are written such that the code can be used as
external standalone libraries and not a single G_*() version is used, I
think.
Single-instance allocations don't need to be free()d; they can remain
until the process terminates.
Explicitly freeing memory when termination is imminent is a waste of
resources (e.g. CPU cycles, and I/O bandwidth in the case where free()
causes swapped-out memory to be swapped back in). It's colloquially
referred to as rearranging the deckchairs on the Titanic.
Clear enough, thanks for the example!
If Vect_set_release_support() does not cause a severe time penalty, I
would recommend to use it. IMHO 73,854,014 - 444,026 (previous result)
bytes = ca. 70 MB lingering around in memory is a bit unnecessary.
That should only be done if vectors will be closed signficantly prior
to termination, e.g.:
for (i = 0; i nvects; i++) {
vect = Vect_open_old(...);
...
Vect_close(vect);
}
Can we add this to the Programmer's manual under GRASS 6 Vector
Architecture where Vect_set_release_support() is mentioned or have I
missed something?
Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #559: wingrass stand-alone installer: MSys console doesn't work
#559: wingrass stand-alone installer: MSys console doesn't work
---+
Reporter: hamish| Owner: cnielsen
Type: defect| Status: assigned
Priority: minor | Milestone: 6.4.0
Component: Installation | Version: 6.4.0 RCs
Resolution:|Keywords: wingrass
Platform: MSWindows XP | Cpu: x86-32
---+
Changes (by cnielsen):
* status: new = assigned
* owner: grass-dev@lists.osgeo.org = cnielsen
* cc: grass-dev@lists.osgeo.org (added)
Comment:
I'll include the fix in the next version of the installer. For now you can
substitute line 88 of msys.bat for these two:
{{{
if x%* == x start %WD%rxvt -backspacekey -sl 2500 -fg %FGCOLOR% -bg
%BGCOLOR% -sr -fn Courier-12 -tn msys -geometry 80x25 -e /bin/sh --login
-i
if NOT x%* == x start %WD%rxvt -backspacekey -sl 2500 -fg %FGCOLOR%
-bg %BGCOLOR% -sr -fn Courier-12 -tn msys -geometry 80x25 -e /bin/sh
--login -c %*
}}}
--
Ticket URL: http://trac.osgeo.org/grass/ticket/559#comment:1
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
This is now a mix of r.in.gdal and r.out.gdal. The two modules
complement each other, and I guess a minimum requirement would be that
something exported with r.out.gdal and then imported again with
r.in.gdal should be identical (taking into consideration the region
settings during export) and not have any data loss, be it due to
clipping data or due to nodata problems.
Glynn Clements wrote:
The only fool-proof nodata value for CELL is 0x8000; all other
values may be actual data values.
For grass rasters of type CELL, not for gdal export as Int32. gdalinfo
says NoData Value=2147483648, but cells that should be nodata are
-2147483648 and are thus not recognized as nodata.
It worked as of a few days ago, in the version I have checked out:
raster/r.in.gdal/main.c:780:
if (((GInt32 *) cell)[indx] == (GInt32) dfNoData) {
(GInt32)2147483648 and (GInt32)-2147483648 are equal.
I think the problem is that gdal allows the nodata value to be out of
range with regard to the raster type, e.g. in gdal, a nodata value of
- with GDT_Byte is legal and can be used to effectively disable
nodata information. No idea if this conforms to GeoTIFF specs (probably
yes), but I'm pretty sure that this is the current policy of gdal
(possible with e.g. gdal_translate).
That would also mean that r.out.gdal with type = GDT_Int32 and nodata =
2147483648, NULL cells become -2147483648 but the nodata value in the
metadata stays 2147483648 (gdalinfo on the export output), which in turn
means that other software, also QGIS, does not see any nodata cells in
the export output -information loss about NULL cells. That's why I
wouldn't use 0x8000 as default nodata value for GDT_Int32 in
r.out.gdal even if r.in.gdal has no problems with it.
If it's been changed, use nodata=-0x8000.
That's currently done in r.out.gdal in trunk and devbr6.
Or cast the nodata value
to the source data type then back to double.
For r.out.gdal, there was discussion about not to override user options
and instead issue an error or a warning (going for error now) that the
nodata value is out of range. Currently, all default nodata values are
within the range of the selected GDAL data type. User-defined nodata
values are tested whether they are within the range of the selected data
type, if not, r.out.gdal in trunk and devbr6 exits with an error
message. r.out.gdal also exits with an error message if the nodata value
is present in the raster to be exported in order to avoid data loss.
This is a rather strict and conservative approach because of the
reported problems with nodata in r.out.gdal exports.
Markus M
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #559: wingrass stand-alone installer: MSys console doesn't work
#559: wingrass stand-alone installer: MSys console doesn't work
---+
Reporter: hamish| Owner: cnielsen
Type: defect| Status: assigned
Priority: minor | Milestone: 6.4.0
Component: Installation | Version: 6.4.0 RCs
Resolution:|Keywords: wingrass
Platform: MSWindows XP | Cpu: x86-32
---+
Comment (by cnielsen):
Replying to [ticket:559 hamish]:
ps- is there a way to automatically minimize the DOS box when launching
GRASS? it just sort of sits there idle.
Yes this can be done in the creation of the shortcut (*.lnk) files.
{{{SW_SHOWMINIMIZED}}} will start it minimized
{{{SH_HIDE}}} should (I haven't tested it yet) start it but run it in the
background (ie. hide it completely). Although there would be no extra
window, it may hide error messages like the one that says wxdigit isn't
working.
Which option should I implement?
--
Ticket URL: http://trac.osgeo.org/grass/ticket/559#comment:2
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Re: [GRASS GIS] #73: r.out.gdal tiff output does not work
On 17/04/09 16:53, Markus Metz wrote: For r.out.gdal, there was discussion about not to override user options and instead issue an error or a warning (going for error now) that the nodata value is out of range. Currently, all default nodata values are within the range of the selected GDAL data type. User-defined nodata values are tested whether they are within the range of the selected data type, if not, r.out.gdal in trunk and devbr6 exits with an error message. r.out.gdal also exits with an error message if the nodata value is present in the raster to be exported in order to avoid data loss. This is a rather strict and conservative approach because of the reported problems with nodata in r.out.gdal exports. In the current state is there a possibility of using gdal's acceptance of unvalid nodata ? And can we force a nodata value which exists in the map ? I would agree with Dylan that this kind of brute-force method should remain possible, be it through the suggested -f flag. I'm always wary of programs that assume they know better than you what you want ;-) Moritz ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #560: WinGRASS not deleting temp ppm files from map display
#560: WinGRASS not deleting temp ppm files from map display --+- Reporter: isaacullah| Owner: grass-dev@lists.osgeo.org Type: defect| Status: new Priority: major | Milestone: 6.4.0 Component: Display | Version: 6.4.0 RCs Keywords: v.digit ppm temp |Platform: MSWindows XP Cpu: x86-32| --+- When v.digit loads, it creates it's own ppm and ppg files for the background of the v.digit display (seperate from the ppm and ppg files created for the regular tcltk map display). When one exits from v.digit, those ppm and ppg stay in the .tmp directory of the mapset. When one exits from grass, the ppm and ppg files for the map display are erased, but NOT those created by the v.digit display. This leads to build up of files that can eat harddrive memory. This problem was dectected on a Windows XP machine, and has not been tested for on Linux or Mac. -- Ticket URL: http://trac.osgeo.org/grass/ticket/560 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] [GRASS GIS] #561: meta: add a new normal bug priority
#561: meta: add a new normal bug priority -+-- Reporter: hamish | Owner: grass-dev@lists.osgeo.org Type: enhancement | Status: new Priority: minor| Milestone: Website Component: Website | Version: Keywords: trac |Platform: Unspecified Cpu: Unspecified | -+-- Hi, could a normal priority be created in the trac ticket system and be set as the default? the default setting of major tends to dramatize the priority setting into irrelevance. thanks, Hamish -- Ticket URL: http://trac.osgeo.org/grass/ticket/561 GRASS GIS http://grass.osgeo.org ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Re: [GRASS GIS] #560: WinGRASS not deleting temp ppm files from map display
#560: WinGRASS not deleting temp ppm files from map display
---+
Reporter: isaacullah| Owner: grass-dev@lists.osgeo.org
Type: defect| Status: new
Priority: major | Milestone: 6.4.0
Component: Display | Version: 6.4.0 RCs
Resolution:|Keywords: v.digit ppm temp
Platform: MSWindows XP | Cpu: x86-32
---+
Comment (by hamish):
the only thing I can think of is that the files are still in use, so can
not be swept up by clean_temp on exit. ?
maybe remove the NUL: from the end of the 3 calls to it in init.bat,
{{{
rem Clean out old .tmp files from the mapset
%WINGISBASE%\etc\clean_temp NUL:
}}}
and see if it produces an error message.
Hamish
--
Ticket URL: http://trac.osgeo.org/grass/ticket/560#comment:1
GRASS GIS http://grass.osgeo.org
___
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
