[GRASS5] SegFault in Vect_New_line_struct()

GRASS GRASS developer
1

Hello all,

When I try to read a soil usage map, with m.in.e00, in e00 format (size
+/-15Mb) the only result is a nice core dump. It's hard to read the soil
usage from that :wink:

The Segfault occurs after updating 5600 lines in dig_att. When calling
Vect_new_line_struct() and Vect__new_line_struct() it bombs immediatly
at the malloc routine in Vect__new_line_struct(). I tried to test the
malloc return value (void*) but that was of no use, it seems that it
segfaults before returning anything. I'd like to solve this, and read my
map, but I don't have any idea where to look. Does anyone have tips?

The system is a Pentium processor and 128Mb mem (256 swap) running SuSE
6.2

Regards
  Job Spijker

----------------------------------------------------------------------
Job Spijker
Faculty of Geographical Sciences, Utrecht University
P.O. Box 80115, 3508 TC Utrecht, The Netherlands
T: +31 (0)30-253 2758 / +31 (0)30-253 2749 F: +31 (0)30-253 1145
e-mail: spijker@geog.uu.nl, spijker@geo.uu.nl ICQ:70495898
----------------------------------------------------------------------
What goes around usually gets dizzy and falls over.

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

spijker@geo.uu.nl wrote:

Hello all,

When I try to read a soil usage map, with m.in.e00, in e00 format (size
+/-15Mb) the only result is a nice core dump. It's hard to read the soil
usage from that :wink:

The Segfault occurs after updating 5600 lines in dig_att. When calling
Vect_new_line_struct() and Vect__new_line_struct() it bombs immediatly
at the malloc routine in Vect__new_line_struct(). I tried to test the
malloc return value (void*) but that was of no use, it seems that it
segfaults before returning anything. I'd like to solve this, and read my
map, but I don't have any idea where to look. Does anyone have tips?

The system is a Pentium processor and 128Mb mem (256 swap) running SuSE
6.2

Regards
        Job Spijker

Hi

Almost always an unexpected bomb-out in malloc() or free() is the result
of a delayed memory allocation problem. So, not likely anything to do
with Vect__new_line_struct().

A likely candidate is m.in.e00/vector.c lines 107, 109, ..., where the
x,y arrays overflow by 1 * sizeof(double).

David

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

3

David D Gray wrote:

spijker@geo.uu.nl wrote:
Almost always an unexpected bomb-out in malloc() or free() is the result
of a delayed memory allocation problem. So, not likely anything to do
with Vect__new_line_struct().

A likely candidate is m.in.e00/vector.c lines 107, 109, ..., where the
x,y arrays overflow by 1 * sizeof(double).

AAARGH! You're right : when the coverage is in single precision and the
number of points is odd, odd things may occur in vector.c :-))

Lines 92,93 are the best candidates for this. Here is a quick bug fix.
Markus, can you insert it before the new release ? I am not on the good
machine for cvs upload.

------------------start of patch

*** vector.c Wed Jul 26 16:36:12 2000
--- vector.c~ Wed Jul 26 16:32:06 2000
***************
*** 59,66 ****
        }
        if (debug > 4)
            fprintf( fdlog, "line %d (%d pnts) id=%d\n", j, npts, covnum);
! x = (double *)G_malloc( sizeof(double) * (npts+1));
! y = (double *)G_malloc( sizeof(double) * (npts+1));

        if (prec) { /* double precision : 1 coord pair / line */
            for (i = 0; i < npts; i++) {
--- 59,66 ----
        }
        if (debug > 4)
            fprintf( fdlog, "line %d (%d pnts) id=%d\n", j, npts, covnum);
! x = (double *)G_malloc( sizeof(double) * npts);
! y = (double *)G_malloc( sizeof(double) * npts);

        if (prec) { /* double precision : 1 coord pair / line */
            for (i = 0; i < npts; i++) {

--------------------------- end of patch --------

--
Michel Wurtz ENGEES - CEREG
                1, quai Koch - BP 1039, F-67070 STRASBOURG cedex
                Tel: +33 03.88.24.82.45 Fax: +33 03.88.37.04.97

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

4

On Wed, Jul 26, 2000 at 04:44:29PM +0200, Michel Wurtz - ENGEES/CEREG wrote:

David D Gray wrote:
>
> spijker@geo.uu.nl wrote:
> Almost always an unexpected bomb-out in malloc() or free() is the result
> of a delayed memory allocation problem. So, not likely anything to do
> with Vect__new_line_struct().
>
> A likely candidate is m.in.e00/vector.c lines 107, 109, ..., where the
> x,y arrays overflow by 1 * sizeof(double).

AAARGH! You're right : when the coverage is in single precision and the
number of points is odd, odd things may occur in vector.c :-))

Lines 92,93 are the best candidates for this. Here is a quick bug fix.
Markus, can you insert it before the new release ? I am not on the good
machine for cvs upload.

------------------start of patch

*** vector.c Wed Jul 26 16:36:12 2000
--- vector.c~ Wed Jul 26 16:32:06 2000
***************
*** 59,66 ****
        }
        if (debug > 4)
            fprintf( fdlog, "line %d (%d pnts) id=%d\n", j, npts, covnum);
! x = (double *)G_malloc( sizeof(double) * (npts+1));
! y = (double *)G_malloc( sizeof(double) * (npts+1));

        if (prec) { /* double precision : 1 coord pair / line */
            for (i = 0; i < npts; i++) {
--- 59,66 ----
        }
        if (debug > 4)
            fprintf( fdlog, "line %d (%d pnts) id=%d\n", j, npts, covnum);
! x = (double *)G_malloc( sizeof(double) * npts);
! y = (double *)G_malloc( sizeof(double) * npts);

        if (prec) { /* double precision : 1 coord pair / line */
            for (i = 0; i < npts; i++) {

Hi Michel,

this is updated and re-tagged to beta8. Now I have to recompile
and put online. Then go to bed.

Cheers

Markus

----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'