this bug's URL: http://intevation.de/rt/webrt?serial_num=753
-------------------------------------------------------------------------
Subject: tcltkgrass menu system says xterm not found with Xfree 4.0
Platform: Linux/Intel
Linux distro: Mandrake
linux cpu: AMD (K6, ...)
Xwindows version: Xfree 4.0.x
Xwindows manager: KDE 2.x
TclTk version: tcl/tk 8.3
grass downloaded at: Hannover site
grass binary for platform: Linux/Intel binaries
Hello.
Excuse my poor written english. I found two bugs.
* The first bug was using the tcltkgrass menu system to display data. When I
try to do 'display -> monitors -> start -> X0' or other, grass5 says xterm
not found. In the grass shell it works perfectly 'd.mon start=x0'. I think
it is because xfree 4.0 maybe comes without xterm. Then I did install
xterm.rpm from Internet and the problem disapeared.
* The second bug is that all operations with mapcalc returns me images
without data. I think it is because i have installed a precompiled version
for i686 when I work with an AMD K6-2, that is an i586. All the other
functions except mapcalc works fine.
Thanks.
Àlex
-------------------------------------------- Managed by Request Tracker
From neteler Thu Jun 14 17:14:08 2001
Return-Path: <neteler>
Received: by hgeo02.geog.uni-hannover.de (SMI-8.6/SMI-SVR4)
id RAA19190; Thu, 14 Jun 2001 17:14:08 +0100
Date: Thu, 14 Jun 2001 17:14:08 +0100
From: Markus Neteler <neteler@geog.uni-hannover.de>
To: "Eric G. Miller" <egm2@jps.net>
Cc: grass5 developers list <grass5@geog.uni-hannover.de>
Subject: Re: [GRASS5] Re: r.sunmask - memory leakage in GRASS lib
Message-ID: <20010614171408.E18856@hgeo02.geog.uni-hannover.de>
Mail-Followup-To: "Eric G. Miller" <egm2@jps.net>,
grass5 developers list <grass5@geog.uni-hannover.de>
References: <20010529132445.G18447@hgeo02.geog.uni-hannover.de> <200106051039.f55AdGZ28715@geni.cemtlo.com> <20010611142409.C23183@hgeo02.geog.uni-hannover.de> <20010611223226.A23961@calico.local> <20010613160712.F10125@hgeo02.geog.uni-hannover.de> <20010613180409.A1089@calico.local>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <20010613180409.A1089@calico.local>; from egm2@jps.net on Wed, Jun 13, 2001 at 06:04:09PM -0700
Sender: grass5-admin@geog.uni-hannover.de
Errors-To: grass5-admin@geog.uni-hannover.de
X-BeenThere: grass5@geog.uni-hannover.de
X-Mailman-Version: 2.0.5
Precedence: bulk
List-Help: <mailto:grass5-request@geog.uni-hannover.de?subject=help>
List-Post: <mailto:grass5@geog.uni-hannover.de>
List-Subscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=subscribe>
List-Id: GRASS 5 Developers mailing list <grass5.geog.uni-hannover.de>
List-Unsubscribe: <http://www.geog.uni-hannover.de/mailman/listinfo/grass5>,
<mailto:grass5-request@geog.uni-hannover.de?subject=unsubscribe>
List-Archive: <http://www.geog.uni-hannover.de/pipermail/grass5/>
Status: O
Content-Length: 2732
Lines: 65
Eric,
(cc to GRASS 5)
On Wed, Jun 13, 2001 at 06:04:09PM -0700, Eric G. Miller wrote:
On Wed, Jun 13, 2001 at 04:07:12PM +0100, Markus Neteler wrote:
> Eric,
>
> On Mon, Jun 11, 2001 at 10:32:26PM -0700, Eric G. Miller wrote:
> > Here's a diff that fixes all the significant leakages in libgis (from
> > r.sunmask's point of view). I'm sure there are quite a few still in
> > there.
>
> it *seems* that the leakage in r.sunmask is fixed. But the machine will
> run some more 5h to finish the map. r.sunmask is incredible slow with
> FP maps!I only tested it on a very small map (float) so it didn't take but a
couple minutes. I'm not even sure I understand what r.sunmask is trying
to do (with my test map, I got an output raster of mostly -1 values with
a few 1 values -- maybe my test map has weird values to begin with).
congrats, the r.sunmask runs through now...!
The idea of this module is to calculate cast shadow areas from DEM or
buildings or whatever. You specify
- either the sun position directly (if you know)
- or specify location, date, time, etc and let r.sunmask calc. the sun
position for you
Then the shadow maps is written, null() where is no shadow and 1 where
is shadow.
> A C related question (sorry, I am geographer only):
>
> > RCS file: /grassrepository/grass/src/libes/gis/file_name.c,v
> > > char *location = G__location_path();
> [...]
> > > G_free (location);
>
> Is it always required to write GRASS functions which output characters in
> return code to a variables and G_free() this variable later?
>
> If so, many leakages will be there in GRASSIt's not consistent. Some functions return pointers to a static buffer
or other memory that shouldn't be free'ed by the caller. Many return
dynamic memory. It is a real problem. For most modules, it doesn't
matter too much; a few char buffers are leaked, but usually the memory
is fairly insignificant. But, in this case, it's library functions
calling other library functions (perhaps repeatedly) and they need to be
very careful. I'm certain I did not find all occurences of library
functions not being careful about memory.While I was messing about, I did wonder if we could plug in something
like the Boehm Conservative Garbage collector for G_malloc/G_calloc. I
don't have any experience with these things, and I understand it can be
problematic with lots of pointers being passed around to the same chunk
of memory (I don't know). Just a thought...
Probably a good idea! Anyone out there familiar with such stuff?
Regards and thanks again for the leakage detection and fixing
(thanks to Justin and Huidae as well!)
Markus
