Details Ticket 4987


Comment | Reply | Take | Resolve


Serial Number 4987
Subject malloc errors/declaration - 64 bit problems
Area grass6
Queue grass
Requestors flor@itc.it,neteler@itc.it
Owner none
Status open
Last User Contact Tue Aug 8 19:43:22 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Tue Aug 8 19:43:22 2006 (2 yr ago)
Created Tue Aug 8 16:16:28 2006 (2 yr ago)

Transaction History Ticket 4987


Tue, Aug 8 2006 16:16:28    Request created by guest  
Subject: malloc errors/declaration - 64 bit problems

grass obtained from: CVS
grass binary for platform: Compiled from Sources

Copied to bugtracker by MN.
-------

On Tue, Aug 08, 2006 at 04:10:04PM +0200, Roberto Flor wrote:
Here my findings on 64 bit problems:

Simple, potential error on 64 bit machines, really only for float case:

./raster/simwe/r.sim.sediment/main.c:   si = (double **)G_malloc (sizeof(double)*(my));
./raster/simwe/r.sim.sediment/main.c:   sigma = (double **)G_malloc (sizeof(double)*(my));
./raster/simwe/r.sim.sediment/main.c:        dif = (float **)G_malloc (sizeof(float)*(my));
./raster/simwe/r.sim.sediment/main.c:        er = (float **)G_malloc (sizeof(float)*(my));
./vector/v.surf.idw/main.c:    npoints_currcell = (long **)G_malloc(window.rows
* sizeof(long));


Overzealous but should'nt be a problem:

./raster/r.param.scale/nrutil.c:        t = (float ***) G_malloc (((nrow+NR_END)
* sizeof(float**)));
./imagery/i.smap/bouman/multialloc.c:          r[0]=(char *)G_malloc(max*sizeof(char
**));
./lib/imagery/alloc.c:    x = (double ***)G_malloc((a+1) * sizeof(double **));
Hyper allocation, requires more memory than necessary:

./vector/v.surf.idw/main.c:        search_list = (struct cell_list **)G_malloc(max_radius
* sizeof(struct cell_list));
./vector/v.surf.idw/main.c:        search_list_start = (struct cell_list **)G_malloc(max_radius
* sizeof(struct cell_list));
./vector/v.surf.idw/main.c:    points = (struct Point ***)G_malloc(window.rows
* sizeof(struct Point));
./vector/v.surf.idw/main.c:        points[row] = (struct Point **)G_malloc(window.cols
* sizeof(struct Point));

In all the case the sizeof shoul to be of a pointer.
Tue, Aug 8 2006 16:17:01    User changed to flor@itc.it,neteler@itc.it by mneteler  
Tue, Aug 8 2006 16:45:35    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 8 Aug 2006 15:45:17 +0100 (BST)
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
X-X-Sender paulk@agrippa.ukshells.co.uk
To Request Tracker <grass-bugs@intevation.de>
Cc grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #4987] (grass) malloc errors/declaration - 64 bit problems
In-Reply-To <20060808141628.1DC7410016A@lists.intevation.de>
Message-ID <Pine.LNX.4.62.0608081542430.6792@agrippa.ukshells.co.uk>
References <20060808141628.1DC7410016A@lists.intevation.de>
MIME-Version 1.0
Content-Type TEXT/PLAIN; charset=US-ASCII; format=flowed
X-SA-Do-Not-Run Yes
X-SA-Exim-Connect-IP 217.10.143.90
X-SA-Exim-Mail-From paul-grass@stjohnspoint.co.uk
X-SA-Exim-Scanned No (on mail.ukshells.net); SAEximRunCond expanded to false
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-4.248 tagged_above=-999 required=3 tests=[AWL=0.752, BAYES_00=-5]
X-Spam-Level
On Tue, 8 Aug 2006, Request Tracker wrote:

> On Tue, Aug 08, 2006 at 04:10:04PM +0200, Roberto Flor wrote:
> Here my findings on 64 bit problems:
>
> Simple, potential error on 64 bit machines, really only for float case:
>
[...]
> ./vector/v.surf.idw/main.c:    npoints_currcell = (long **)G_malloc(window.rows
* sizeof(long));
>
[...]
>
> Hyper allocation, requires more memory than necessary:
>
> ./vector/v.surf.idw/main.c:        search_list = (struct cell_list **)G_malloc(max_radius
* sizeof(struct cell_list));
> ./vector/v.surf.idw/main.c:        search_list_start = (struct cell_list **)G_malloc(max_radius
* sizeof(struct cell_list));
> ./vector/v.surf.idw/main.c:    points = (struct Point ***)G_malloc(window.rows
* sizeof(struct Point));
> ./vector/v.surf.idw/main.c:        points[row] = (struct Point **)G_malloc(window.cols
* sizeof(struct Point));
>
> In all the case the sizeof shoul to be of a pointer.

The v.surf.idw are all my mistakes; well spotted and thanks for pointing 
them out. To fix them, I guess the size of a pointer is always the same no 
matter what type it points to, so is there a standard way of representing 
it always, e.g. like sizeof(char *)? Or should we always write sizeof(long *),
sizeof(struct Point *) etc. as appropriate? Is it just a question of
programming style?

Paul


Tue, Aug 8 2006 18:13:19    Mail sent by flor@itc.it  
Return-Path <flor@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <44D8B81C.30206@itc.it>
Date Tue, 08 Aug 2006 18:13:16 +0200
From Roberto Flor <flor@itc.it>
User-Agent Thunderbird 1.5.0.5 (X11/20060726)
MIME-Version 1.0
To Paul Kelly via RT <grass-bugs@intevation.de>
Cc Markus Neteler <neteler@itc.it>
Subject Re: [bug #4987] (grass) malloc errors/declaration - 64
References <20060808144535.6B6E71005B1@lists.intevation.de>
In-Reply-To <20060808144535.6B6E71005B1@lists.intevation.de>
Content-Type multipart/alternative; boundary="------------000901020008010703050906"
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-2.731 tagged_above=-999 required=3 tests=[AWL=1.066, BAYES_00=-5, FORGED_RCVD_HELO=0.266, HTML_30_40=0.437, HTML_MESSAGE=0.5]
X-Spam-Level
This is a multi-part message in MIME format.
--------------000901020008010703050906
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Paul Kelly via RT wrote:
> On Tue, 8 Aug 2006, Request Tracker wrote:
>
>   
>
>
> The v.surf.idw are all my mistakes; well spotted and thanks for pointing 
> them out. To fix them, I guess the size of a pointer is always the same no
> matter what type it points to, so is there a standard way of representing 
> it always, e.g. like sizeof(char *)? Or should we always write sizeof(long
*),
> sizeof(struct Point *) etc. as appropriate? Is it just a question of
> programming style?
>
> Paul
>
>   

For ANSI/ISO Standard C, it should be  sizeof(void *), since void * is 
the generic pointer, but a quick search in the grass codes find just 
eight lines:

[root@jbach grass6]# egrep -R 'sizeof[ \t]*\([a-Z]+[ \t]*\*' . |grep 
[ch]:|grep void

./raster/r.stats/raw_stats.c:    rast = (void **) G_calloc (nfiles, 
sizeof (void *));
./raster/r.stats/raw_stats.c:    rastp = (void **) G_calloc (nfiles, 
sizeof (void *));
./raster/r.mapcalc/expression.c:        void **argv = G_malloc (2 * 
sizeof(void *));
./raster/r.mapcalc/expression.c:        void **argv = G_malloc (2 * 
sizeof(void *));
./raster/r.mapcalc/expression.c:        void **argv = G_malloc (2 * 
sizeof(void *));
./raster/r.mapcalc/expression.c:        void **argv = G_malloc ((argc + 
1) * sizeof(void *));
./imagery/i.ortho.photo/photo.rectify/exec.c:    cell_buf = (CELL **) 
G_calloc (NROWS, sizeof (void *));
./imagery/i.rectify/exec.c:    cell_buf = (void **) G_calloc (NROWS, 
sizeof(void *));


All other instances use  sizeof(long *):
egrep -R 'sizeof[ \t]*\([a-Z]+[ \t]*\*' . |grep [ch]:|grep -v void |wc
223

so for now it's faster keep the same syntax, but a cleaner syntax should 
be void *.

Roberto Flor





--------------000901020008010703050906
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Paul Kelly via RT wrote:
<blockquote cite="mid20060808144535.6B6E71005B1@lists.intevation.de"
 type="cite">
  <pre wrap="">On Tue, 8 Aug 2006, Request Tracker wrote:

  </pre>
  <br>
  <pre wrap=""><!---->
The v.surf.idw are all my mistakes; well spotted and thanks for pointing 
them out. To fix them, I guess the size of a pointer is always the same no 
matter what type it points to, so is there a standard way of representing 
it always, e.g. like sizeof(char *)? Or should we always write sizeof(long *),
sizeof(struct Point *) etc. as appropriate? Is it just a question of
programming style?

Paul

  </pre>
</blockquote>
<br>
For ANSI/ISO Standard C, it should be  sizeof(void *), since void * is
the generic pointer, but a quick search in the grass codes find just
eight lines:<br>
<br>
[root@jbach grass6]# egrep -R 'sizeof[ \t]*\([a-Z]+[ \t]*\*' . |grep
[ch]:|grep void<br>
<br>
./raster/r.stats/raw_stats.c:    rast = (void **) G_calloc (nfiles,
sizeof (void *));<br>
./raster/r.stats/raw_stats.c:    rastp = (void **) G_calloc (nfiles,
sizeof (void *));<br>
./raster/r.mapcalc/expression.c:        void
**argv = G_malloc (2 *
sizeof(void *));<br>
./raster/r.mapcalc/expression.c:        void
**argv = G_malloc (2 *
sizeof(void *));<br>
./raster/r.mapcalc/expression.c:        void
**argv = G_malloc (2 *
sizeof(void *));<br>
./raster/r.mapcalc/expression.c:        void
**argv = G_malloc ((argc +
1) * sizeof(void *));<br>
./imagery/i.ortho.photo/photo.rectify/exec.c:    cell_buf = (CELL
**)
G_calloc (NROWS, sizeof (void *));<br>
./imagery/i.rectify/exec.c:    cell_buf = (void **) G_calloc (NROWS,
sizeof(void *));<br>
<br>
<br>
All other instances use  sizeof(long *):<br>
egrep -R 'sizeof[ \t]*\([a-Z]+[ \t]*\*' . |grep [ch]:|grep -v void |wc<br>
223<br>
<br>
so for now it's faster keep the same syntax, but a cleaner syntax
should be void *.<br>
<br>
Roberto Flor<br>
<br>
<br>
<br>
<br>
</body>
</html>

--------------000901020008010703050906--


Tue, Aug 8 2006 18:16:40    Mail sent by flor@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Resent-From neteler@itc.it
Resent-Date Tue, 8 Aug 2006 18:16:37 +0200
Resent-Message-ID <20060808161637.GN28523@bartok.itc.it>
Resent-To grass-bugs@intevation.de
Message-ID <44D8B8A4.70100@itc.it>
Date Tue, 08 Aug 2006 18:15:32 +0200
From Roberto Flor <flor@itc.it>
User-Agent Thunderbird 1.5.0.5 (X11/20060726)
MIME-Version 1.0
To Markus Neteler <neteler@itc.it>
Subject more sizeof errors [bug #4987]
Content-Type text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding 7bit
X-OriginalArrivalTime 08 Aug 2006 16:15:32.0795 (UTC) FILETIME=[DFA438B0:01C6BB05]
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-3.732 tagged_above=-999 required=3 tests=[AWL=1.002, BAYES_00=-5, FORGED_RCVD_HELO=0.266]
X-Spam-Level
Using a smarter regex, I found some other sizeof errors:

64bit dangerous:
./raster/r.le/r.le.patch/trace.c:           twist2[i] = (int 
**)G_calloc(tcols + 3, sizeof(int));
./raster/r.le/r.le.patch/trace.c:          twistP[i] = (float 
**)G_calloc(tcols + 3, sizeof(float));
./raster/r.le/r.le.trace/main.c:           twist2[i] = (int 
**)G_calloc(tcols + 3, sizeof(int));
./raster/r.le/r.le.trace/main.c:          twistP[i] = (float 
**)G_calloc(tcols + 3, sizeof(float));

Cosmetic/overzealous:

/raster/r.le/r.le.patch/trace.c:        twist2 = (int ***)G_calloc(trows 
+ 3, sizeof(int **));
./raster/r.le/r.le.patch/trace.c:        twistP = (float 
***)G_calloc(trows + 3, sizeof(float **));
./raster/r.le/r.le.trace/main.c:        twist2 = (int ***)G_calloc(trows 
+ 3, sizeof(int **));
./raster/r.le/r.le.trace/main.c:        twistP = (float 
***)G_calloc(trows + 3, sizeof(float **));
./raster/r.proj/readcell.c:     ibuffer = (FCELL **) 
G_malloc(sizeof(FCELL **) * nrows);
./imagery/i.smap/bouman/multialloc.c:            *s1 = (t += sizeof 
(char **) * *(q + 1));
./lib/gis/rd_cellhd.c:    array = (char**) G_calloc ( (size_t) count+1, 
sizeof(char**) );

As StandardANSI/ISO all the should be changed to sizeof(void *) .... I 
found 224 occurences ..

ciao
Roberto



 


Tue, Aug 8 2006 19:43:22    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <17624.52528.19731.687397@cerise.gclements.plus.com>
Date Tue, 8 Aug 2006 18:43:12 +0100
To Request Tracker <grass-bugs@intevation.de>
Cc grass-dev@grass.itc.it
Subject Re: [GRASS-dev] [bug #4987] (grass) malloc errors/declaration - 64 bit problems
In-Reply-To <20060808141628.1DC7410016A@lists.intevation.de>
References <20060808141628.1DC7410016A@lists.intevation.de>
X-Mailer VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Virus-Scanned by amavisd-new at intevation.de
X-Spam-Status No, hits=-3.683 tagged_above=-999 required=3 tests=[AWL=1.051, BAYES_00=-5, FORGED_RCVD_HELO=0.266]
X-Spam-Level
Request Tracker wrote:

> this bug's URL: http://intevation.de/rt/webrt?serial_num=4987

> Subject: malloc errors/declaration - 64 bit problems
> 
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
> 
> Copied to bugtracker by MN.
> -------
> 
> On Tue, Aug 08, 2006 at 04:10:04PM +0200, Roberto Flor wrote:
> Here my findings on 64 bit problems:
> 
> Simple, potential error on 64 bit machines, really only for float case:
> 
> ./raster/simwe/r.sim.sediment/main.c:   si = (double **)G_malloc (sizeof(double)*(my));
> ./raster/simwe/r.sim.sediment/main.c:   sigma = (double **)G_malloc (sizeof(double)*(my));
> ./raster/simwe/r.sim.sediment/main.c:        dif = (float **)G_malloc (sizeof(float)*(my));
> ./raster/simwe/r.sim.sediment/main.c:        er = (float **)G_malloc (sizeof(float)*(my));
> ./vector/v.surf.idw/main.c:    npoints_currcell = (long **)G_malloc(window.rows
* sizeof(long));

> ./vector/v.surf.idw/main.c:        search_list = (struct cell_list **)G_malloc(max_radius
* sizeof(struct cell_list));
> ./vector/v.surf.idw/main.c:        search_list_start = (struct cell_list **)G_malloc(max_radius
* sizeof(struct cell_list));
> ./vector/v.surf.idw/main.c:    points = (struct Point ***)G_malloc(window.rows
* sizeof(struct Point));
> ./vector/v.surf.idw/main.c:        points[row] = (struct Point **)G_malloc(window.cols
* sizeof(struct Point));
> 
> In all the case the sizeof shoul to be of a pointer.

I've fixed these in CVS.

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


Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request