[GRASS-dev] WinGRASS: Test Build on Vista

GRASS GRASS developer
,
1

Hi lists,

I built GRASS 6.3.0 on Vista (Home Premium) through the usual MSYS/MinGW envrironment.
It works fine on my machine, and it seems that it solved the following bugs:

http://trac.osgeo.org/grass/ticket/111
http://trac.osgeo.org/grass/ticket/118

But I need more tests, from both XP and Vista users;
I specially need to know if that build works fine also on XP systems, because at the moment I cannot access my old XP machine to test it by myself.

In this binary release candidate (the 4th for GRASS 6.3.0) I introduced the following changes:

  • added libjpeg (6b) library [built from source]
  • added JPEG support in libtiff
  • added JPEG support in GRASS
  • updated libpng from 1.2.24 to 1.2.29
  • updated GLS from 1.9 to 1.11
  • updated PostgreSQL from 8.2.6 to 8.3.1
  • updated SQLite from 3.5.6 to 3.5.9
  • added the OGDI tools (3.2.0beta1-4) [prebuilt binaries from OSGEO4W Project]
  • updated GDAL from 1.5.1 to 1.5.2
  • added the AVCE00 tools (2.0.0) [built from source]
  • added the E00compr tools (1.0.0) [built from source]
  • added the GPSBabel tools (1.3.5) [prebuilt binaries from GPSBabel Web Site]
  • updated tcl from 8.5.1 to 8.5.2
  • updated tk from 8.5.1 to 8.5.2

I also tried to add the FFMPEG and wxWidgets supports to GRASS, but I failed for the moment; I’ll try to do that next times :slight_smile:

The WinGRASS-6.3.0-4 Test Installer is available here:
http://gigamaildownload.rossoalice.alice.it/download/download.aspx?AttachmentID=f7bb562d-e5a5-4798-becd-6538000a0dc2&MessageID=f617242a-074b-4298-be4b-82ef221920ea

Any comment or test help will be highly appreciated.
Many thaks guys,

Marco

2

Hi,

I have installed WinGRASS-6.3.0-4 in my Windows XP profesional x64 and all
was fine,

Many thanks for your help. I’m happy that the Vista build works fine also on XP (as I actually expected).

but it does not solve the
http://trac.osgeo.org/grass/ticket/111bug. When I try to execute the
following operation Windows reports me a
system failure:

r.los input=elevation.dem output=los coordinate=599505,4921010 max_dis=2525

Actually I don’t know why r.los has problems on XP, because on Vista it works fine.
Only our IT Guru Glynn might solve the question… :slight_smile:

Many thanks,

Marco

3

Actually, r.los seems to have faulty mem management on all platforms.
If I valgrind the module, I get:

==20182== at 0x804AB15: hidden_point_elimination (pts_elim.c:105)
==20182== by 0x8049D74: main (main.c:303)
==20182== Address 0x4691CB8 is 24 bytes inside a block of size 32 free'd
==20182== at 0x402237F: free (vg_replace_malloc.c:233)
==20182== by 0x403767C: G_free (alloc.c:126)
==20182== by 0x8049673: delete (delete.c:39)
==20182== by 0x804AB14: hidden_point_elimination (pts_elim.c:189)
==20182== by 0x8049D74: main (main.c:303)
  100%
==20182==
==20182== Conditional jump or move depends on uninitialised value(s)
==20182== at 0x40A6CB2: (within /usr/lib/libz.so.1.2.3.3)
==20182== by 0x40A7E5F: deflate (in /usr/lib/libz.so.1.2.3.3)
==20182== by 0x40463A7: G_zlib_compress (flate.c:359)
==20182== by 0x4046551: G_zlib_write (flate.c:224)
==20182== by 0x405D54F: G__write_data_compressed (put_row.c:337)
==20182== by 0x405DE89: put_raster_row (put_row.c:477)
==20182== by 0x804A007: main (main.c:351)
==20182==

... and a dozen more like that. Not a good sign really.

My guess is that whether r.los crashes or not is simply due to
how relaxed the OS's memory allocation scheme is. Some systems
are more forgiving for the sake of better performance. I guess
that XP is more on the strict side and thus kills the module,
while Linux and Vista let you get away with it.

Fixing the mem allocation errors reported by Valgrind may very
well stop r.los from crashing on Win32.

Ben

marco.pasetti@alice.it wrote:

Hi,

>I have installed WinGRASS-6.3.0-4 in my Windows XP profesional x64 and all
>was fine,

Many thanks for your help. I'm happy that the Vista build works fine also on XP (as I actually expected).

>but it does not solve the
>http://trac.osgeo.org/grass/ticket/111bug. When I try to execute the
>following operation Windows reports me a
>system failure:

>r.los input=elevation.dem output=los coordinate=599505,4921010 max_dis=2525

Actually I don't know why r.los has problems on XP, because on Vista it works fine.
Only our IT Guru Glynn might solve the question... :slight_smile:

Many thanks,

Marco

------------------------------------------------------------------------

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

--
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke@oxfordarch.co.uk

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

4

Benjamin Ducke wrote:

Actually, r.los seems to have faulty mem management on all platforms.
If I valgrind the module, I get:

==20182== at 0x804AB15: hidden_point_elimination (pts_elim.c:105)
==20182== by 0x8049D74: main (main.c:303)
==20182== Address 0x4691CB8 is 24 bytes inside a block of size 32 free'd
==20182== at 0x402237F: free (vg_replace_malloc.c:233)
==20182== by 0x403767C: G_free (alloc.c:126)
==20182== by 0x8049673: delete (delete.c:39)
==20182== by 0x804AB14: hidden_point_elimination (pts_elim.c:189)
==20182== by 0x8049D74: main (main.c:303)
  100%
==20182==
==20182== Conditional jump or move depends on uninitialised value(s)
==20182== at 0x40A6CB2: (within /usr/lib/libz.so.1.2.3.3)
==20182== by 0x40A7E5F: deflate (in /usr/lib/libz.so.1.2.3.3)
==20182== by 0x40463A7: G_zlib_compress (flate.c:359)
==20182== by 0x4046551: G_zlib_write (flate.c:224)
==20182== by 0x405D54F: G__write_data_compressed (put_row.c:337)
==20182== by 0x405DE89: put_raster_row (put_row.c:477)
==20182== by 0x804A007: main (main.c:351)
==20182==

... and a dozen more like that. Not a good sign really.

My guess is that whether r.los crashes or not is simply due to
how relaxed the OS's memory allocation scheme is. Some systems
are more forgiving for the sake of better performance. I guess
that XP is more on the strict side and thus kills the module,
while Linux and Vista let you get away with it.

It's more likely to be plain luck rather than any specific design
factor.

Whether or not you get away with continuing to use freed memory
depends upon whether that memory gets re-used. In turn, that depends
upon which other allocations occur.

--
Glynn Clements <glynn@gclements.plus.com>

5

So you agree that it may be worse trying to fix those
mem allocation issues to get r.los to work on Win32?

Ben

Glynn Clements wrote:

Benjamin Ducke wrote:

Actually, r.los seems to have faulty mem management on all platforms.
If I valgrind the module, I get:

==20182== at 0x804AB15: hidden_point_elimination (pts_elim.c:105)
==20182== by 0x8049D74: main (main.c:303)
==20182== Address 0x4691CB8 is 24 bytes inside a block of size 32 free'd
==20182== at 0x402237F: free (vg_replace_malloc.c:233)
==20182== by 0x403767C: G_free (alloc.c:126)
==20182== by 0x8049673: delete (delete.c:39)
==20182== by 0x804AB14: hidden_point_elimination (pts_elim.c:189)
==20182== by 0x8049D74: main (main.c:303)
  100%
==20182==
==20182== Conditional jump or move depends on uninitialised value(s)
==20182== at 0x40A6CB2: (within /usr/lib/libz.so.1.2.3.3)
==20182== by 0x40A7E5F: deflate (in /usr/lib/libz.so.1.2.3.3)
==20182== by 0x40463A7: G_zlib_compress (flate.c:359)
==20182== by 0x4046551: G_zlib_write (flate.c:224)
==20182== by 0x405D54F: G__write_data_compressed (put_row.c:337)
==20182== by 0x405DE89: put_raster_row (put_row.c:477)
==20182== by 0x804A007: main (main.c:351)
==20182==

... and a dozen more like that. Not a good sign really.

My guess is that whether r.los crashes or not is simply due to
how relaxed the OS's memory allocation scheme is. Some systems
are more forgiving for the sake of better performance. I guess
that XP is more on the strict side and thus kills the module,
while Linux and Vista let you get away with it.

It's more likely to be plain luck rather than any specific design
factor.

Whether or not you get away with continuing to use freed memory
depends upon whether that memory gets re-used. In turn, that depends
upon which other allocations occur.

--
Benjamin Ducke
Senior Applications Support and Development Officer

Oxford Archaeological Unit Limited
Janus House
Osney Mead
OX2 0ES
Oxford, U.K.

Tel: +44 (0)1865 263 800 (switchboard)
Tel: +44 (0)1865 980 758 (direct)
Fax :+44 (0)1865 793 496
benjamin.ducke@oxfordarch.co.uk

------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.

6

Benjamin Ducke wrote:

So you agree that it may be worse trying to fix those
mem allocation issues to get r.los to work on Win32?

If the problems are due to faulty memory management, they won't be
limited to Windows. They may well happen on other platforms, just less
frequently. Or they may start happening with future versions of libc,
or with future versions of GRASS.

It would certainly be nice to have them fixed. Unfortunately, tracking
down such bugs can take a lot of effort.

--
Glynn Clements <glynn@gclements.plus.com>

7

Hi Marco,

I loaded the new build under Windows XP and it runs all right, so far as my simple usage is concerned - constructing a map from various vector layers.

However, as someone new to Grass, my knowledge is not great. Using the print button on the map display, I’m having trouble reproducing in a file what I see on the screen

  • An eps file does not appear to include the entire region on the screen, regardless of the paper size specified (I’ve tried A4 and A0)
  • A pdf file using A4 paper is at least contained within the page, although not centrally, but if I specify A0 I get a part map in one corner of the page.
    Can you point me at relevant documentation to read to try to sort this out please?

Many thanks,
John Field

At 02:08 AM 17/06/2008, marco.pasetti@alice.it wrote:

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary=“----_=_NextPart_001_01C8CFCF.63F66E8B”

Hi lists,

I built GRASS 6.3.0 on Vista (Home Premium) through the usual MSYS/MinGW envrironment.
It works fine on my machine, and it seems that it solved the following bugs:

http://trac.osgeo.org/grass/ticket/111
http://trac.osgeo.org/grass/ticket/118

But I need more tests, from both XP and Vista users;
I specially need to know if that build works fine also on XP systems, because at the moment I cannot access my old XP machine to test it by myself.

In this binary release candidate (the 4th for GRASS 6.3.0) I introduced the following changes:

  • added libjpeg (6b) library [built from source]
  • added JPEG support in libtiff
  • added JPEG support in GRASS
  • updated libpng from 1.2.24 to 1.2.29
  • updated GLS from 1.9 to 1.11
  • updated PostgreSQL from 8.2.6 to 8.3.1
  • updated SQLite from 3.5.6 to 3.5.9
  • added the OGDI tools (3.2.0beta1-4) [prebuilt binaries from OSGEO4W Project]
  • updated GDAL from 1.5.1 to 1.5.2
  • added the AVCE00 tools (2.0.0) [built from source]
  • added the E00compr tools (1.0.0) [built from source]
  • added the GPSBabel tools (1.3.5) [prebuilt binaries from GPSBabel Web Site]
  • updated tcl from 8.5.1 to 8.5.2
  • updated tk from 8.5.1 to 8.5.2

I also tried to add the FFMPEG and wxWidgets supports to GRASS, but I failed for the moment; I’ll try to do that next times :slight_smile:

The WinGRASS-6.3.0-4 Test Installer is available here:
http://gigamaildownload.rossoalice.alice.it/download/download.aspx?AttachmentID=f7bb562d-e5a5-4798-becd-6538000a0dc2&MessageID=f617242a-074b-4298-be4b-82ef221920ea

Any comment or test help will be highly appreciated.
Many thaks guys,

Marco

grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user

No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 270.3.0/1505 - Release Date: 16/06/2008 7:20 AM

8

Hi John,

thanks for your help.

However, as someone new to Grass, my knowledge is not great. Using
the print button on the map display, I’m having trouble reproducing
in a file what I see on the screen

did you correctly set the region with g.region? Config → Region → Change region settings: I suggest you to set the region to match the desired map; you can also specify multiple maps or, if needed, zoom in the map display to the desired region and save it through the command “Save display extents to named region” (select this command in the map display window; it’s one of the options given by the “Zoom to…” icon); this done, set the region (with g.region) to match this named region (in g.region GUI: “Set current region from named region”).

Can you point me at relevant documentation to read to try to sort
this out please?

try here: http://grass.osgeo.org/wiki/GRASS_Help

Hope this helps,

Marco