landam / grass-gis-git-migration-test

0 stars 0 forks source link

Handle corrupt data in r.gwflow and gpde library #175

Open landam opened 5 years ago

landam commented 5 years ago

Reported by wenzeslaus on 10 Oct 2015 14:53 UTC Moving ''r.gwflow''-related discussion from https://trac.osgeo.org/grass/ticket/2750 to a separate ticket.

In https://trac.osgeo.org/grass/ticket/2750 [comment:11:ticket:2750 sprice] suggested a simple improvement for ''r.gwflow'' and ''gpde'' library:

If you do a diff with [source:grass/trunk/lib/gpde/n_les_assemble.c#L1289 n_les_assemble.c] you'll see that I [attachment/ticket/2750/lz4_zstd4.tgz added] a few if statements to ensure that the indexing stays within row/col bounds. I was getting segfaults with corrupt data before I fixed the other bugs. I figure it should be able to handle any data without segfaulting, even if corrupt.

This is a trivial change but I'm not sure if this is necessary. Let me throw out some questions. How you can get a corrupt data unless changing raster library? If we want this to handle corrupt data here, where else we want to do that? What is the appropriate else branch, nothing or fatal error?

This is the change:

 /*set the rows to zero */
+if (count < les->rows)
     for (i = 0; i < les->cols; i++)
         les->A[count][i] = 0.0;
 /*set the cols to zero */
+if (count < les->cols)
     for (i = 0; i < les->rows; i++)
         les->A[i][count] = 0.0;
 /*entry on the diagonal */
+if (count < les->rows && count < les->cols)
     les->A[count][count] = 1.0;

The change is in N_les_integrate_dirichlet_2d() function which is used only in ''r.gwflow''.

GRASS GIS version and provenance

svn-trunk

Migrated-From: https://trac.osgeo.org/grass/ticket/2754

landam commented 5 years ago

Comment by neteler on 5 May 2016 14:08 UTC Milestone renamed

landam commented 5 years ago

Comment by neteler on 28 Dec 2016 15:04 UTC Ticket retargeted after milestone closed

landam commented 5 years ago

Modified by @landam on 5 May 2017 20:41 UTC

landam commented 5 years ago

Comment by @landam on 1 Sep 2017 20:28 UTC All enhancement tickets should be assigned to 7.4 milestone.

landam commented 5 years ago

Comment by neteler on 26 Jan 2018 11:40 UTC Ticket retargeted after milestone closed

landam commented 5 years ago

Modified by neteler on 12 Jun 2018 20:48 UTC

landam commented 5 years ago

Comment by @landam on 25 Sep 2018 16:53 UTC All enhancement tickets should be assigned to 7.6 milestone.

landam commented 5 years ago

Comment by @landam on 25 Jan 2019 21:08 UTC Ticket retargeted after milestone closed