[GRASS5] Re: [GRASSLIST:9350] Re: v.in.ascii problems

Hamish hamish_nospam at yahoo.com
Wed Dec 7 11:40:02 EST 2005


> If I use the full million it gets stuck on the scanning step:
> 
> D3/3: row 374430 : 28 chars
> 
> Interesting, that line is the second value with elevation > 100.
> 
> changing the first z value to 500.054 it segfaults pretty quick:
> 
> D5/5: Vect_hist_write()
> D4/5: G_getl2: ->-75.622346,35.949693,500.054<-
> D3/5: row 1 : 28 chars
> D4/5: token: -75.622346
> D4/5: is_latlong north: -75.622346
> D4/5: row 1 col 0: '-75.622346' is_int = 0 is_double = 1
> D4/5: token: 35.949693
> D4/5: is_latlong north: 35.949693
> D4/5: row 1 col 1: '35.949693' is_int = 0 is_double = 1
> D4/5: row 1 col 2: '500.054' is_int = 0 is_double = 1
> D4/5: G_getl2: ->-75.629469,35.949693,11.962<-
> D3/5: row 2 : 27 chars
> D4/5: token: -75.629469
> D4/5: is_latlong north: -75.629469
> D4/5: row 2 col 0: 'H629469' is_int = 0 is_double = 0
> Segmentation fault
> 
> where is 'H629469' coming from?
> 
> v.in.ascii/points.c
>  tmp_token is getting corrupted, cascades from there
> 
> int points_analyse (){
> ...
>     char **tokens;
> ...
>     tmp_token=(char *) G_malloc(256);
> ...
>     while (1) {
> ...
>         tokens = G_tokenize (buf, fs);
> ...
>         for ( i = 0; i < ntokens; i++ ) {
> ...
> [*]                 sprintf(tmp_token, "%f", northing);
> ...
> 		    /* replace current DMS token by decimal degree */
>                     tokens[i]=tmp_token;
> 
> BOOM. pointer abuse. (bug is new lat/lon scanning code, only in
> 6.1CVS)
> 
> [*] and if northing column is longer than 256 without hitting the fs, 
>    buffer overflow??  add ,int maxlength, parameter to G_tokenize()?
>    or can %f never be more than 256 bytes long?
>     same %f effectively cutting down precision of lat/lon coords to 6 
>    spots after the decimal place? (be that pretty small on the ground)


more:

from lib/gis/token.c
G_tokenize() 
/* break buf into tokens. delimiters are replaced by NULLs
   and tokens array will point to varous locations in buf
   buf must not have a new line

so overwriting (or attempting to overwrite :) the a tokens[i] string
with a tmp_token which is longer will stray into either tokens[i+1]'s
address or if i=num_tokens, beyond the address space of the the array.

eg: G_scan_northing("35N") -> 35.000000 will have the zeros stray into
the easting column.



Hamish




More information about the grass-dev mailing list