Dear Devs,
it seems that some recent additions to v.transform have broken
the module. There are several places in which read or write
operations to addresses that have not been malloc'd lead to
crashes.
The problems all seem to be related to the new option "table=".
It is unclear to me what this option is intended for. Is it
an input or an output option? Maybe some information should
be added to the HTML manual page.
Anyhow, without the "table=" option set, v.transform crashes
due to this block of code on line 166 of trans_digit.c:
if (field > 0) {
db_close_database_shutdown_driver(driver);
G_free((void *)trans_params);
}
The problem here is that "driver" never gets malloc'd,
unless the "table=" option is given (look at lines
53 and following in trans_digit.c).
With the "table=" option given, there are still illegal
write operations. Valgrind points to lines 88, 126 and
136 of trans_digit.c as culprits. These will make
v.transform crash or not -- depending on your luck.
Cheers,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke AT fastmail.fm
On Thu, Oct 25, 2012 at 12:06 PM, Benjamin Ducke <benducke@fastmail.fm> wrote:
Dear Devs,
it seems that some recent additions to v.transform have broken
the module. There are several places in which read or write
operations to addresses that have not been malloc'd lead to
crashes.
The problems all seem to be related to the new option "table=".
It is unclear to me what this option is intended for. Is it
an input or an output option? Maybe some information should
be added to the HTML manual page.
This table option is a bit strange. Looking at the code, it is not
clear which column is used as key column to select the appropriate
transformation parameters for a given point, probably a column named
"cat". Furthermore, there are no options to define database and
driver. In GRASS 7, I have removed the table option, the table is here
selected through the layer option, which is also used to select the
appropriate category for a given point, also in GRASS 6.
I have changed the behaviour of v.transform in r53553/4 such that the
table option can be safely ignored. Individual transformation
parameters stored in an attribute table can be used with the 'layer'
and 'columns' option. In theory the table option is still recognized.
Is this OK?
Markus M
Anyhow, without the "table=" option set, v.transform crashes
due to this block of code on line 166 of trans_digit.c:
if (field > 0) {
db_close_database_shutdown_driver(driver);
G_free((void *)trans_params);
}
The problem here is that "driver" never gets malloc'd,
unless the "table=" option is given (look at lines
53 and following in trans_digit.c).
With the "table=" option given, there are still illegal
write operations. Valgrind points to lines 88, 126 and
136 of trans_digit.c as culprits. These will make
v.transform crash or not -- depending on your luck.
Cheers,
Ben
--
Benjamin Ducke
{*} Geospatial Consultant
{*} GIS Developer
benducke AT fastmail.fm
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On Thu, Oct 25, 2012, at 17:23, Markus Metz wrote:
On Thu, Oct 25, 2012 at 12:06 PM, Benjamin Ducke <benducke@fastmail.fm>
{SNIP}
This table option is a bit strange. Looking at the code, it is not
clear which column is used as key column to select the appropriate
transformation parameters for a given point, probably a column named
"cat". Furthermore, there are no options to define database and
driver. In GRASS 7, I have removed the table option, the table is here
selected through the layer option, which is also used to select the
appropriate category for a given point, also in GRASS 6.
I have changed the behaviour of v.transform in r53553/4 such that the
table option can be safely ignored. Individual transformation
parameters stored in an attribute table can be used with the 'layer'
and 'columns' option. In theory the table option is still recognized.
Is this OK?
Sounds good to me.
Best,
Ben
Markus M
>
> Anyhow, without the "table=" option set, v.transform crashes
> due to this block of code on line 166 of trans_digit.c:
>
> if (field > 0) {
> db_close_database_shutdown_driver(driver);
> G_free((void *)trans_params);
> }
>
> The problem here is that "driver" never gets malloc'd,
> unless the "table=" option is given (look at lines
> 53 and following in trans_digit.c).
>
> With the "table=" option given, there are still illegal
> write operations. Valgrind points to lines 88, 126 and
> 136 of trans_digit.c as culprits. These will make
> v.transform crash or not -- depending on your luck.
>
> Cheers,
>
> Ben
>
> --
> Benjamin Ducke
> {*} Geospatial Consultant
> {*} GIS Developer
>
> benducke AT fastmail.fm
> _______________________________________________
> grass-dev mailing list
> grass-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev