[GRASS5] [bug #977] (grass) s.in.ascii core dumps

GRASS GRASS developer
1

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

Subject: s.in.ascii core dumps

Platform: Linux/Intel
grass downloaded at: CVS Server, Germany
grass binary for platform: I compiled the sources myself
grass sources source: (latest) GRASS from CVS, pre3/CVS versio

s.in.ascii sites=eaurinia input=e_aurinia.txt fs=","
or
s.in.ascii sites=eaurinia input=e_aurinia.txt fs=,
dumps core on data in the form like this:
3500900,5704300,"AAAAAAAANF","Name",
3500900,5704300,"AAAAAAAANF","Name, another Name",
3555700,5697800,"AAAAAAAANG","Name with umlauts äöü",
3501500,5694000,"AAAAAAAANH","Name...",19760101

cat e_aurinia.txt | tr "," "\t"| s.in.ascii sites=eaurinia2
works partially. Only some lines are imported. If i cut off all fields exept the easting/northing part it works.

I am in a hurry, so i am not able to check further.

I think that s.in.ascii should at least not core dump on input, irrespectively how weird it is.
My guess is that the problem is either the unquoted "," inside the qouted field or the empty fifth field.

Andreas

-------------------------------------------- Managed by Request Tracker

2

Request Tracker wrote:

Subject: s.in.ascii core dumps

s.in.ascii sites=eaurinia input=e_aurinia.txt fs=","
or
s.in.ascii sites=eaurinia input=e_aurinia.txt fs=,
dumps core on data in the form like this:
3500900,5704300,"AAAAAAAANF","Name",
3500900,5704300,"AAAAAAAANF","Name, another Name",
3555700,5697800,"AAAAAAAANG","Name with umlauts äöü",
3501500,5694000,"AAAAAAAANH","Name...",19760101

cat e_aurinia.txt | tr "," "\t"| s.in.ascii sites=eaurinia2
works partially. Only some lines are imported. If i cut off all fields
exept the easting/northing part it works.

I am in a hurry, so i am not able to check further.

I think that s.in.ascii should at least not core dump on input,
irrespectively how weird it is.

My guess is that the problem is either the unquoted "," inside the
qouted field or the empty fifth field.

AFAICT, it's actually a bug in G_parser() regarding the "fs=," option;
the split_opts() function attempts to split the "answer" field into
multiple answers, regardless of whether the "multiple" field is set.
Furthermore, zero-length options result in a NULL answer rather than
the empty string. This causes G_recreate_command() to segfault, as it
expects opt->answers[0] to be valid.

If I fix split_opts(), so that opt->answers[0] is just set to
opt->answer when opt->multiple is false, s.in.ascii works OK.

BTW, s.out.ascii only outputs the first three sites, so there's
something wrong there ($LOCATION/site_lists/eaurinia is correct).

--
Glynn Clements <glynn.clements@virgin.net>

3

Glynn Clements wrote:

BTW, s.out.ascii only outputs the first three sites, so there's
something wrong there ($LOCATION/site_lists/eaurinia is correct).

Sorry, my mistake; the last site doesn't match the guessed format, so
it's ignored.

--
Glynn Clements <glynn.clements@virgin.net>

4

On Mon, Mar 25, 2002 at 01:29:18PM +0100, Request Tracker wrote:

s.in.ascii sites=eaurinia input=e_aurinia.txt fs=,
dumps core on data in the form like this:
3500900,5704300,"AAAAAAAANF","Name",
3500900,5704300,"AAAAAAAANF","Name, another Name",
3555700,5697800,"AAAAAAAANG","Name with umlauts äöü",
3501500,5694000,"AAAAAAAANH","Name...",19760101

Sites files must have uniform field counts/types. While it's not nice
behavior to segfault, the data should just be rejected. There is
currently no provision for NULL fields.

--
Eric G. Miller <egm2@jps.net>

5

On Mon, Mar 25, 2002 at 07:59:39AM -0800, Eric G. Miller wrote:

On Mon, Mar 25, 2002 at 01:29:18PM +0100, Request Tracker wrote:
> s.in.ascii sites=eaurinia input=e_aurinia.txt fs=,
> dumps core on data in the form like this:
> 3500900,5704300,"AAAAAAAANF","Name",
> 3500900,5704300,"AAAAAAAANF","Name, another Name",
> 3555700,5697800,"AAAAAAAANG","Name with umlauts äöü",
> 3501500,5694000,"AAAAAAAANH","Name...",19760101

Sites files must have uniform field counts/types. While it's not nice
behavior to segfault, the data should just be rejected. There is
currently no provision for NULL fields.

Eric,

do you see a change to add:

G_fatal_error("Sites files must have uniform field counts/types. There is
               currently no provision for NULL fields.");

in the module?

Thanks,

Markus

6

Glynn Clements wrote:

If I fix split_opts(), so that opt->answers[0] is just set to
opt->answer when opt->multiple is false, s.in.ascii works OK.

But this breaks "paired" options, i.e.

  opt3->key_desc = "x,y";

I've settled for not skipping "empty" answers; that appears to work.

--
Glynn Clements <glynn.clements@virgin.net>