[GRASS-user] i.rectify error

2010-06-08 Thread Luís Ferreira
On 

Ubuntu 10.04 x86_64
GRASS 6.4 SVN rev 42488

when trying to rectify an raster  group, the following error appears:

GRASS 6.4.0svn (grass_32629):~ > i.rectify
*** glibc detected *** i.rectify: munmap_chunk(): invalid pointer:
0x01c08280 ***
=== Backtrace: =
/lib/libc.so.6(+0x775b6)[0x7fa63fe905b6]
/lib/libc.so.6(+0x9b039)[0x7fa63feb4039]
/lib/libc.so.6(+0x9b1b9)[0x7fa63feb41b9]
/usr/lib/grass-6.4.0svn/lib/libgrass_gis.so(G_date+0x20)[0x7fa640a6a954]
/usr/lib/grass-6.4.0svn/lib/libgrass_gis.so(G_short_history
+0x19)[0x7fa640a77c2e]
/usr/lib/grass-6.4.0svn/lib/libgrass_gis.so(+0x1a95a)[0x7fa640a6295a]
/usr/lib/grass-6.4.0svn/lib/libgrass_gis.so(G_close_cell
+0x7c)[0x7fa640a61f10]
i.rectify(write_map+0x1ce)[0x406c1e]
i.rectify(rectify+0x498)[0x4061c4]
i.rectify(exec_rectify+0x30d)[0x404519]
i.rectify(main+0x7d8)[0x405328]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7fa63fe37c4d]
i.rectify[0x402b19]
=== Memory map: 
0040-00408000 r-xp  08:01
400720 /usr/lib/grass-6.4.0svn/bin/i.rectify
00607000-00608000 r--p 7000 08:01
400720 /usr/lib/grass-6.4.0svn/bin/i.rectify
00608000-00609000 rw-p 8000 08:01
400720 /usr/lib/grass-6.4.0svn/bin/i.rectify
00609000-00619000 rw-p  00:00 0 
01bec000-01c36000 rw-p  00:00 0
[heap]
7fa63db42000-7fa63db4e000 r-xp  08:01
5345   /lib/libnss_files-2.11.1.so
7fa63db4e000-7fa63dd4d000 ---p c000 08:01
5345   /lib/libnss_files-2.11.1.so
7fa63dd4d000-7fa63dd4e000 r--p b000 08:01
5345   /lib/libnss_files-2.11.1.so
7fa63dd4e000-7fa63dd4f000 rw-p c000 08:01
5345   /lib/libnss_files-2.11.1.so
7fa63dd4f000-7fa63dd59000 r-xp  08:01
5349   /lib/libnss_nis-2.11.1.so
7fa63dd59000-7fa63df58000 ---p a000 08:01
5349   /lib/libnss_nis-2.11.1.so
7fa63df58000-7fa63df59000 r--p 9000 08:01
5349   /lib/libnss_nis-2.11.1.so
7fa63df59000-7fa63df5a000 rw-p a000 08:01
5349   /lib/libnss_nis-2.11.1.so
7fa63df5a000-7fa63df71000 r-xp  08:01
5339   /lib/libnsl-2.11.1.so
7fa63df71000-7fa63e17 ---p 00017000 08:01
5339   /lib/libnsl-2.11.1.so
7fa63e17-7fa63e171000 r--p 00016000 08:01
5339   /lib/libnsl-2.11.1.so
7fa63e171000-7fa63e172000 rw-p 00017000 08:01
5339   /lib/libnsl-2.11.1.so
7fa63e172000-7fa63e174000 rw-p  00:00 0 
...
etc

Any ideas? Bug?

Luís Ferreira
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] i.rectify - ERROR: error while writing to temp file

2008-06-13 Thread Alfredo Alessandrini
2008/6/13 Glynn Clements <[EMAIL PROTECTED]>:
>
> Hamish wrote:
>
>> > I'm trying to rectify some scanned maps, but I've
>> > this error:
>> >
>> > ERROR: error while writing to tmp file
>> >
>> > I've checked the write permission of .tmp directory and
>> > it's ok...
>> >
>> > I've 15 GB of free space.
>> >
>> > How can I solve this problem?
>> >
>> > The .tmp directory where the .tmp files are saved, are the
>> > source LOCATION (xy) or target LOCATION?
>>
>>
>> No idea, but the help page says this:
>> ---
>> If i.rectify starts normally but after some time the following text is seen:
>> GIS ERROR: error while writing to temp file
>> the user may try the flag -c (or the module needs more free space on the 
>> hard drive).
>> ---
>>
>> The -c flag: "Use curr. region settings in target location (def.=calculate 
>> smallest area)"
>>
>>
>>
>> the code that triggers that is this, in i.rectify/write.c:
>> ---
>> offset = ((off_t) row++ * target_window.cols + col) *
>>   G_raster_size(map_type);
>> lseek(temp_fd,offset,SEEK_SET);
>>
>> if(write(temp_fd,cell_buf[n],G_raster_size(map_type)*matrix_cols)
>>   != G_raster_size(map_type)*matrix_cols)
>> {
>> unlink(temp_name);
>> G_fatal_error("error while writing to temp file");
>> }
>> ---
>
> However: note that nothing prior to the above checks that the temp_fd
> returned from creat() is valid. So, if creat() fails, the first
> indication will be that write() fails (with EBADF).
>
> I suggest adding an explicit check for the return value from creat(),
> i.e.:
>
>temp_fd = creat(temp_name,0660);
> +   if (temp_fd < 0)
> +   G_fatal_error("unable to open temporary file");
>
> This will make it possible to distinguish between an error when
> opening the file (e.g. EPERM = "permission denied") and an error when
> writing to the file (e.g. ENOSPC = "no space left on device").
>
>> ?does the (off_t) cast only affect nearest row++ and not the whole
>> (row*col+col)? or does the whole thing get promoted once one part of
>> the calc is cast to off_t? or is that ok?
>
> In C, types propagate upwards from the leaves. The result type of a
> diadic operator (addition, multiplication) etc is equal to the
> "largest" operand type, where long long > long > int, and double is
> deemed larger than all integral types.
>
> When dealing with off_t, the general rule is to cast one "limb" of any
> multiplication to off_t (it's invariably multiplications where any
> truncation will occur). The result of the multiplication will then be
> off_t, as will the result of any enclosing expression involving that
> value.
>
> So, in the above code, the off_t propagates up to the result of the
> first multiplication, and then to the addition, then to the second
> multiplication, and then to the assignment.
>
> OTOH, this won't work:
>
>offset = (off_t) ((row++ * target_window.cols + col) * 
> G_raster_size(map_type));
>
> as all of the calculations will be truncated to lesser types (int,
> long, size_t), and by the time that the value is cast to off_t
> (immediately before the assignment), it has already been truncated.
>
> --
> Glynn Clements <[EMAIL PROTECTED]>


I've solved

The region that I've setting is too large :-)

Now, it's work well...


Alfredo
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] i.rectify - ERROR: error while writing to temp file

2008-06-12 Thread Glynn Clements

Hamish wrote:

> > I'm trying to rectify some scanned maps, but I've
> > this error:
> > 
> > ERROR: error while writing to tmp file
> > 
> > I've checked the write permission of .tmp directory and
> > it's ok...
> > 
> > I've 15 GB of free space.
> > 
> > How can I solve this problem?
> > 
> > The .tmp directory where the .tmp files are saved, are the
> > source LOCATION (xy) or target LOCATION?
> 
> 
> No idea, but the help page says this:
> ---
> If i.rectify starts normally but after some time the following text is seen:
> GIS ERROR: error while writing to temp file
> the user may try the flag -c (or the module needs more free space on the hard 
> drive).
> ---
> 
> The -c flag: "Use curr. region settings in target location (def.=calculate 
> smallest area)"
> 
> 
> 
> the code that triggers that is this, in i.rectify/write.c:
> ---
> offset = ((off_t) row++ * target_window.cols + col) *
>   G_raster_size(map_type);
> lseek(temp_fd,offset,SEEK_SET);
> 
> if(write(temp_fd,cell_buf[n],G_raster_size(map_type)*matrix_cols) 
>   != G_raster_size(map_type)*matrix_cols)
> {
> unlink(temp_name);
> G_fatal_error("error while writing to temp file");
> }
> ---

However: note that nothing prior to the above checks that the temp_fd
returned from creat() is valid. So, if creat() fails, the first
indication will be that write() fails (with EBADF).

I suggest adding an explicit check for the return value from creat(),
i.e.:

temp_fd = creat(temp_name,0660);
+   if (temp_fd < 0)
+   G_fatal_error("unable to open temporary file");

This will make it possible to distinguish between an error when
opening the file (e.g. EPERM = "permission denied") and an error when
writing to the file (e.g. ENOSPC = "no space left on device").

> ?does the (off_t) cast only affect nearest row++ and not the whole
> (row*col+col)? or does the whole thing get promoted once one part of
> the calc is cast to off_t? or is that ok?

In C, types propagate upwards from the leaves. The result type of a
diadic operator (addition, multiplication) etc is equal to the
"largest" operand type, where long long > long > int, and double is
deemed larger than all integral types.

When dealing with off_t, the general rule is to cast one "limb" of any
multiplication to off_t (it's invariably multiplications where any
truncation will occur). The result of the multiplication will then be
off_t, as will the result of any enclosing expression involving that
value.

So, in the above code, the off_t propagates up to the result of the
first multiplication, and then to the addition, then to the second
multiplication, and then to the assignment.

OTOH, this won't work:

offset = (off_t) ((row++ * target_window.cols + col) * 
G_raster_size(map_type));

as all of the calculations will be truncated to lesser types (int,
long, size_t), and by the time that the value is cast to off_t
(immediately before the assignment), it has already been truncated.

-- 
Glynn Clements <[EMAIL PROTECTED]>
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


Re: [GRASS-user] i.rectify - ERROR: error while writing to temp file

2008-06-11 Thread Hamish
Alfredo:
> I'm trying to rectify some scanned maps, but I've
> this error:
> 
> ERROR: error while writing to tmp file
> 
> I've checked the write permission of .tmp directory and
> it's ok...
> 
> I've 15 GB of free space.
> 
> How can I solve this problem?
> 
> The .tmp directory where the .tmp files are saved, are the
> source LOCATION (xy) or target LOCATION?


No idea, but the help page says this:
---
If i.rectify starts normally but after some time the following text is seen:
GIS ERROR: error while writing to temp file
the user may try the flag -c (or the module needs more free space on the hard 
drive).
---

The -c flag: "Use curr. region settings in target location (def.=calculate 
smallest area)"



the code that triggers that is this, in i.rectify/write.c:
---
offset = ((off_t) row++ * target_window.cols + col) *
  G_raster_size(map_type);
lseek(temp_fd,offset,SEEK_SET);

if(write(temp_fd,cell_buf[n],G_raster_size(map_type)*matrix_cols) 
  != G_raster_size(map_type)*matrix_cols)
{
unlink(temp_name);
G_fatal_error("error while writing to temp file");
}
---

?does the (off_t) cast only affect nearest row++ and not the whole 
(row*col+col)? or does the whole thing get promoted once one part of the calc 
is cast to off_t? or is that ok?


how does the region in your target mapset look like? of your source image?


Hamish



  

___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user


[GRASS-user] i.rectify - ERROR: error while writing to temp file

2008-06-11 Thread Alfredo Alessandrini
Hi,

I'm trying to rectify some scanned maps, but I've this error:

ERROR: error while writing to tmp file

I've checked the write permission of .tmp directory and it's ok...

I've 15 GB of free space.

How can I solve this problem?

The .tmp directory where the .tmp files are saved, are the source
LOCATION (xy) or target LOCATION?


Alfredo
___
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user