Fri, Aug 12 2005
13:13:59
|
|
Request created by guest (as #3514)
|
|
Subject: r.surf.contour - dozens of warnings
Platform: GNU/Linux/i386
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: 61 cvs 09.08.05
example:
GRASS 6.1.cvs (caves_utm33):~ > r.surf.contour input=melio_poz_clear_rast output=melio_poz_clear_ras
t_10_dem2
WARNING: segment_pagein: No such file or directory
WARNING: bseg_put(): could not read segment file at r:64 c:0
WARNING: segment_pagein: No such file or directory
WARNING: bseg_get(): could not read segment file at r:64 c:23
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
WARNING: segment_pagein: No such file or directory
WARNING: cseg_get(): could not read segment file
100%
Although it completes, looks scarry. What is it?
Maciek |
|
Fri, Aug 12 2005
15:52:17
|
|
Mail sent by glynn@gclements.plus.com (as #3514)
|
|
Return-Path |
<glynn@gclements.plus.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn@gclements.plus.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<17148.49708.1788.523814@cerise.gclements.plus.com>
|
Date |
Fri, 12 Aug 2005 16:37:16 +0100
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #3514] (grass) r.surf.contour - dozens of warnings
|
In-Reply-To |
<20050812111359.6A05C101F1E@lists.intevation.de>
|
References |
<20050812111359.6A05C101F1E@lists.intevation.de>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3514
> Subject: r.surf.contour - dozens of warnings
> GRASS 6.1.cvs (caves_utm33):~ > r.surf.contour input=melio_poz_clear_rast output=melio_poz_clear_r
ast_10_dem2
>
> WARNING: segment_pagein: No such file or directory
> Although it completes, looks scarry. What is it?
if (read (SEG->fd, SEG->scb[cur].buf, SEG->size) != SEG->size)
{
G_warning ("segment_pagein: %s\n", strerror(errno));
return -1;
}
The warning occurs if read() returns a short count, i.e. if you try to
read beyond the end of the file, or an error.
The actual error message is bogus; read() only sets errno if it
returns a negative result, not if it returns a short count.
--
Glynn Clements <glynn@gclements.plus.com>
|
|
Sat, Aug 13 2005
11:43:31
|
|
Area changed to grass6.1 by msieczka (as #3514)
|
|
Wed, Aug 31 2005
20:54:16
|
|
Area changed to grass6 by mneteler (as #3514)
|
|
Fri, Oct 14 2005
15:34:43
|
|
Request created by guest (as #3741)
|
|
Subject: r.cost WARNING: segment_pagein: No such file or directory
Platform: GNU/Linux/i386
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: CVS
Hi,
the following problem appears when using r.cost:
r.cost in=allarea.one out=distance2water start_rast=streams percent_memory=100
WARNING: segment_pagein: No such file or directory
WARNING: segment_pagein: No such file or directory
Peak cost value: 64.485281
Interestingly, the result map is generated.
But the message is confusing.
Thanks
Daniela
|
|
Wed, Dec 21 2005
11:15:20
|
|
Request 3741 merged into 3514 by hbowman (as #3741)
|
|
Wed, Dec 21 2005
11:18:58
|
|
Comments added by hbowman (as #3514)
|
|
This is in lib/segment/pagein.c for those playing along at home.
Hamish
|
|
Wed, Dec 21 2005
17:48:48
|
|
User changed to neteler@itc.it,werchowyna@epf.pl by mneteler (as #3514)
|
|
Wed, Dec 21 2005
17:49:25
|
|
Comments added by mneteler (as #3514)
|
|
the same happens in the new r.walk since it is a r.cost
derivate
Markus |
|
Wed, Mar 1 2006
08:20:31
|
|
Mail sent by hamish_nospam@yahoo.com (as #3514)
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 1 Mar 2006 20:20:06 +1300
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Glynn Clements <glynn@gclements.plus.com>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #3514] (grass) r.surf.contour - dozens of warnings
|
Message-Id |
<20060301202006.5a22e00c.hamish_nospam@yahoo.com>
|
In-Reply-To |
<17148.49708.1788.523814@cerise.gclements.plus.com>
|
References |
<20050812111359.6A05C101F1E@lists.intevation.de> <17148.49708.1788.523814@cerise.gclements.plus.com>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> > this bug's URL: http://intevation.de/rt/webrt?serial_num=3514
>
> > Subject: r.surf.contour - dozens of warnings
>
> > GRASS 6.1.cvs (caves_utm33):~ > r.surf.contour
> > input=melio_poz_clear_rast output=melio_poz_clear_rast_10_dem2
> >
> > WARNING: segment_pagein: No such file or directory
>
> > Although it completes, looks scarry. What is it?
>
> if (read (SEG->fd, SEG->scb[cur].buf, SEG->size) != SEG->size)
> {
> G_warning ("segment_pagein: %s\n", strerror(errno));
> return -1;
> }
>
> The warning occurs if read() returns a short count, i.e. if you try to
> read beyond the end of the file, or an error.
>
> The actual error message is bogus; read() only sets errno if it
> returns a negative result, not if it returns a short count.
I've updated the warning in lib/segment/pagein.c, and added a level 2
debug message stating how much was read & how much was asked for.
This shows that the error that pops up in r.cost (at least for me) is a
short count:
G61> r.cost -vk in= out= start_points=`v.to.points -v coastline` \
percent_memory=50
Null cells excluded from cost evaluation.
Source map is: Integer cell type
20800 rows, 12100 cols.
Creating some temporary files ...
Reading southland_regional_bound ...
D2/2: segment_pagein: read_result=524268 SEG->size=524288
WARNING: segment_pagein: short count during read()
100%
Initializing output
D2/2: segment_pagein: read_result=524268 SEG->size=524288
WARNING: segment_pagein: short count during read()
100%
WARNING: Adapted sites library used for vector points (module should be
updated to GRASS 6 vector library).
[...]
Finding cost path
7%
[...?]
Hamish
ps - r.cost can make lots of big temp files. We should catch ^C etc &
remove them. In about 10 minutes I just made 12gig worth....
"top" reports r.cost is using 1948mb ram for a region this big, with
seg=50% and 90k start points. :/ going into swap makes me sad.
If I try seg=100% then G_malloc() gives an out of memory error right
at the start, which is nice.
|
|
Wed, Apr 5 2006
05:26:55
|
|
Request created by hbowman
|
|
Subject: segmentation library short read()s
Hi,
as many have noticed, sometime after 6.0 was released modules using the
segmentation library started to see read errors. After fixing the reported
error message in pagein.c we see that a short read is happening:
WARNING: segment_pagein: short count during read(), got 4076, expected 4096
WARNING: segment_pagein: short count during read(), got 1004, expected 1024
...
seems to be consistently short 20 bytes.
spearfish60 example:
================
GRASS 6.1-cvs
G6.1> r.cost in=elevation.10m out=cost_test.61 coordinate=599732,4920952
WARNING: segment_pagein: short count during read(), got 524268, expected
524288
WARNING: segment_pagein: short count during read(), got 524268, expected
524288
[done]
================
GRASS 6.0.2
G6.0.2> r.cost in=elevation.10m out=cost_test.602 coordinate=599732,4920952
Peak cost value: 645941.903859
[done]
Resultant maps differ slightly!!
G61> r.univar -g cost_test61 | grep sum
sum=86555328769.3534545898
G61> r.univar -g cost_test602 | grep sum
sum=86555572145.8440551758
also seen in r.surf.contour, r.watershed, r.walk, ...
two relevant changes to the segment lib since 6.0:
"Roberto Flor (ITC-irst): use lseek"
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/segment/format.c.diff?r1=2.0&r2=2.1
"added missing config.h for off_t (as suggested by Glynn; bug #3974)"
http://freegis.org/cgi-bin/viewcvs.cgi/grass6/lib/segment/seek.c.diff?r1=2.0&r2=2.1
could it be some site_t change somewhere else...?
Hamish
|
|
Wed, Apr 5 2006
05:39:40
|
|
Request 3514 merged into 4244 by hbowman (as #3514)
|
|
Wed, Apr 5 2006
06:49:43
|
|
Mail sent by glynn@gclements.plus.com
|
|
Return-Path |
<glynn@gclements.plus.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn@gclements.plus.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<17459.19552.789687.746068@cerise.gclements.plus.com>
|
Date |
Wed, 5 Apr 2006 05:49:36 +0100
|
To |
Request Tracker <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #4244] (grass) segmentation library short read()s
|
In-Reply-To |
<20060405032655.EA4341005AE@lists.intevation.de>
|
References |
<20060405032655.EA4341005AE@lists.intevation.de>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4244
> -------------------------------------------------------------------------
>
> Subject: segmentation library short read()s
>
> Hi,
>
> as many have noticed, sometime after 6.0 was released modules using the
> segmentation library started to see read errors. After fixing the reported
> error message in pagein.c we see that a short read is happening:
> WARNING: segment_pagein: short count during read(), got 4076, expected 4096
> WARNING: segment_pagein: short count during read(), got 1004, expected 1024
> ...
>
> seems to be consistently short 20 bytes.
It is caused by this change to zero_fill():
RCS file: /grassrepository/grass6/lib/segment/format.c,v
Working file: format.c
----------------------------
revision 2.1
date: 2005/06/30 15:48:40; author: markus; state: Exp; lines: +28 -4
Roberto Flor (ITC-irst): use lseek
----------------------------
Specifically, the line:
if ( lseek(fd,nbytes-1,SEEK_SET) < 0 ) {
should use SEEK_CUR rather than SEEK_SET, as it is supposed to be
writing nbytes from the current position, not from the start of the
file.
Note that there is a 20-byte header (5 "int"s) at the start of the
file, which would explain why the read() is always 20 bytes short
(zero_fill() is always called just after the header has been written).
I'm not sure why that header is there in the first place; segment
files aren't supposed to be shared across different processes, are
they?
--
Glynn Clements <glynn@gclements.plus.com>
|
|
Wed, Apr 5 2006
12:55:15
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 5 Apr 2006 22:54:46 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Glynn Clements <glynn@gclements.plus.com>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #4244] (grass) segmentation library short read()s
|
Message-Id |
<20060405225446.7f77e6dd.hamish_nospam@yahoo.com>
|
In-Reply-To |
<17459.19552.789687.746068@cerise.gclements.plus.com>
|
References |
<20060405032655.EA4341005AE@lists.intevation.de> <17459.19552.789687.746068@cerise.gclements.plus.com>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4244
> > -------------------------------------------------------------------
> >
> > Subject: segmentation library short read()s
..
> > as many have noticed, sometime after 6.0 was released modules using
> > the segmentation library started to see read errors. After fixing
> > the reported error message in pagein.c we see that a short read is
> > happening: WARNING: segment_pagein: short count during read(), got
> > 4076, expected 4096 WARNING: segment_pagein: short count during
> > read(), got 1004, expected 1024 ...
> >
> > seems to be consistently short 20 bytes.
>
> It is caused by this change to zero_fill():
>
> RCS file: /grassrepository/grass6/lib/segment/format.c,v
..
> revision 2.1
..
> Specifically, the line:
>
> if ( lseek(fd,nbytes-1,SEEK_SET) < 0 ) {
>
> should use SEEK_CUR rather than SEEK_SET, as it is supposed to be
> writing nbytes from the current position, not from the start of the
> file.
I can confirm that change gets rid of the warnings and the r.univar
sum of values now matches the 6.0.2 value.
> Note that there is a 20-byte header (5 "int"s) at the start of the
> file, which would explain why the read() is always 20 bytes short
> (zero_fill() is always called just after the header has been written).
>
> I'm not sure why that header is there in the first place; segment
> files aren't supposed to be shared across different processes, are
> they?
Don't know. I wouldn't have thought so.
Hamish
|
|
Mon, Apr 17 2006
09:34:49
|
|
Comments added by hbowman
|
|
[reposted from the grass5 mailing list...]
From: Roberto Flor <flor itc it>
CC: Markus Neteler <neteler itc it>
Subject: Re: [GRASS5] [bug #4244] (grass) segmentation library short read()s
Date: Wed, 05 Apr 2006 16:45:33 +0200
To: grass5 grass itc it
Glynn Clements wrote:
>Request Tracker wrote:
>
>
>
>Specifically, the line:
>
> if ( lseek(fd,nbytes-1,SEEK_SET) < 0 ) {
>
>should use SEEK_CUR rather than SEEK_SET, as it is supposed to be
>writing nbytes from the current position, not from the start of the
>file.
>
>Note that there is a 20-byte header (5 "int"s) at the start of the
>file, which would explain why the read() is always 20 bytes short
>(zero_fill() is always called just after the header has been written).
>
>I'm not sure why that header is there in the first place; segment
>files aren't supposed to be shared across different processes, are
>they?
>
>
>
The patch is quite correct; the segment file was shorter of 20 bytes
when using the lseek zero_fill.
The header is required because the segment_format just create the file,
while the segment_init initialize it.
The typical segment library usage was:
fd=open_for_writing
segment_format(fd,..)
close(fd)
fd=open_for_reading_writing
segment_init(fd,...)
and the parameters are shared through the header.
The lseek zero_fill does not really allocate the file, it just extend
the file size, so it's possible a write error later, but it's a lot
faster than writing zero bytes to a file. The write error are handled
inside segment_pageout and segment_put_row with a G_warning and a -1
return code.
_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5
|
|
Mon, Apr 17 2006
09:41:52
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Mon, 17 Apr 2006 19:41:33 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Roberto Flor <flor@itc.it>, glynn@gclements.plus.com
|
Cc |
grass5@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [GRASS5] [bug #4244] (grass) segmentation library short read()s
|
Message-Id |
<20060417194133.074af5f8.hamish_nospam@yahoo.com>
|
In-Reply-To |
<4433D80D.1020503@itc.it>
|
References |
<20060405032655.EA4341005AE@lists.intevation.de> <17459.19552.789687.746068@cerise.gclements.plus.com> <4433D80D.1020503@itc.it>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> Request Tracker wrote:
> this bug's URL: http://intevation.de/rt/webrt?serial_num=4244
> ----------------------------------------------------------------
>
> Subject: segmentation library short read()s
...
> >Specifically, the line:
> >
> > if ( lseek(fd,nbytes-1,SEEK_SET) < 0 ) {
> >
> >should use SEEK_CUR rather than SEEK_SET, as it is supposed to be
> >writing nbytes from the current position, not from the start of the
> >file.
> >
> >Note that there is a 20-byte header (5 "int"s) at the start of the
> >file, which would explain why the read() is always 20 bytes short
> >(zero_fill() is always called just after the header has been
> >written).
> >
> >I'm not sure why that header is there in the first place; segment
> >files aren't supposed to be shared across different processes, are
> >they?
>
> The patch is quite correct; the segment file was shorter of 20 bytes
> when using the lseek zero_fill.
> The header is required because the segment_format just create the
> file, while the segment_init initialize it.
> The typical segment library usage was:
> fd=open_for_writing
> segment_format(fd,..)
> close(fd)
> fd=open_for_reading_writing
> segment_init(fd,...)
>
> and the parameters are shared through the header.
> The lseek zero_fill does not really allocate the file, it just
> extend the file size, so it's possible a write error later, but
> it's a lot faster than writing zero bytes to a file. The write error
> are handled inside segment_pageout and segment_put_row with a
> G_warning and a -1 return code.
.... so, should this change be committed to CVS or not?
> > if ( lseek(fd,nbytes-1,SEEK_SET) < 0 ) {
> >
> >should use SEEK_CUR rather than SEEK_SET
If not, I find it worring that r.cost output is not the same from GRASS
6.0 to GRASS 6.1.
thanks,
Hamish
|
|
Mon, Apr 17 2006
18:48:42
|
|
Mail sent by glynn@gclements.plus.com
|
|
Return-Path |
<glynn@gclements.plus.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn@gclements.plus.com>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<17475.50914.387854.675233@cerise.gclements.plus.com>
|
Date |
Mon, 17 Apr 2006 17:48:34 +0100
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
Roberto Flor <flor@itc.it>, grass5@grass.itc.it, grass-bugs@intevation.de
|
Subject |
Re: [GRASS5] [bug #4244] (grass) segmentation library short read()s
|
In-Reply-To |
<20060417194133.074af5f8.hamish_nospam@yahoo.com>
|
References |
<20060405032655.EA4341005AE@lists.intevation.de> <17459.19552.789687.746068@cerise.gclements.plus.com> <4433D80D.1020503@itc.it> <20060417194133.074af5f8.hamish_nospam@yahoo.com>
|
X-Mailer |
VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Hamish wrote:
> > Request Tracker wrote:
> > this bug's URL: http://intevation.de/rt/webrt?serial_num=4244
> > ----------------------------------------------------------------
> >
> > Subject: segmentation library short read()s
> ...
>
> > >Specifically, the line:
> > >
> > > if ( lseek(fd,nbytes-1,SEEK_SET) < 0 ) {
> > >
> > >should use SEEK_CUR rather than SEEK_SET, as it is supposed to be
> > >writing nbytes from the current position, not from the start of the
> > >file.
[snip]
> .... so, should this change be committed to CVS or not?
Yes.
--
Glynn Clements <glynn@gclements.plus.com>
|
|
Tue, Apr 18 2006
01:52:31
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 18 Apr 2006 11:52:16 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Glynn Clements via RT <grass-bugs@intevation.de>
|
Cc |
neteler@itc.it, werchowyna@epf.pl
|
Subject |
Re: [bug #4244] (grass) segmentation library short read()s
|
Message-Id |
<20060418115216.5fcf6f05.hamish_nospam@yahoo.com>
|
In-Reply-To |
<20060417164842.552961005B7@lists.intevation.de>
|
References |
<20060417164842.552961005B7@lists.intevation.de>
|
X-Mailer |
Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> > > Request Tracker wrote:
> > > this bug's URL: http://intevation.de/rt/webrt?serial_num=4244
> > > ----------------------------------------------------------------
> > >
> > > Subject: segmentation library short read()s
> > ...
> >
> > > >Specifically, the line:
> > > >
> > > > if ( lseek(fd,nbytes-1,SEEK_SET) < 0 ) {
> > > >
> > > >should use SEEK_CUR rather than SEEK_SET, as it is supposed to be
> > > >writing nbytes from the current position, not from the start of the
> > > >file.
>
> [snip]
>
> > .... so, should this change be committed to CVS or not?
>
> Yes.
thanks.
fix applied in CVS, closing bug.
Hamish
|
|
Tue, Apr 18 2006
02:06:25
|
|
Status changed to resolved by hbowman
|
|