Details Ticket 3117


Comment | Reply | Take | Resolve


Serial Number 3117
Subject r.out.pov: bias param broken
Area grass6
Queue grass
Requestors stefan.paulick@urbeli.com
Owner none
Status open
Last User Contact Thu May 18 14:27:36 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Thu May 18 14:27:36 2006 (2 yr ago)
Created Fri Mar 25 15:42:13 2005 (3 yr ago)

Transaction History Ticket 3117


Fri, Mar 25 2005 15:42:13    Request created by guest  
Subject: r.out.pov fails when called out of d.m

Platform: GNU/Linux/i386
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: GRASS 6.1.cvs (2005)

r.out.pov map=alt_surf4 tga=/gd/test.tga hftype=1 causes the attached error 
message.  
 
When called from the command line, the file becomes written. 
 
 
too many nested evaluations (infinite loop?) 
    (procedure "GlobalVar::exists" line 1) 
    invoked from within 
"GlobalVar::exists $_widget($path,var)" 
    (procedure "ProgressBar::_modify" line 4) 
    invoked from within 
"ProgressBar::_modify .dialog0.progress" 
    ("eval" body line 1) 
    invoked from within 
"eval ProgressBar::$cmd .dialog0.progress $args" 
    (procedure ".dialog0.progress" line 1) 
    invoked from within 
"$opt($dlg,progress) _modify" 
    (procedure "progress" line 7) 
    invoked from within 
"progress $dlg $val" 
    invoked from within 
"if [eof $fh] { 
                close $fh 
        } else { 
                set str [gets $fh] 
                append str "\n" 
                if { [fblocked $fh] } { set str [read $fh] } 
                while {[set idx [string f..." 
    (procedure "prnout" line 5) 
    invoked from within 
"prnout 1 file7" 
 
 
 
 
Sat, Mar 26 2005 10:34:15    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <028b01c531e7$17f6e4f0$18d21d3e@eustahiush>
From "Maciek Sieczka" <werchowyna@epf.pl>
To "Request Tracker" <grass-bugs@intevation.de>, "grass devel" <grass5@grass.itc.it>
References <20050325144214.0D15E1005B6@lists.intevation.de>
Subject Re: [GRASS5] [bug #3117] (grass) r.out.pov fails when called out of d.m
Date Sat, 26 Mar 2005 10:24:58 +0100
MIME-Version 1.0
Content-Type text/plain; format=flowed; charset="iso-8859-2"; reply-type=original
Content-Transfer-Encoding 7bit
X-Priority 3
X-MSMail-Priority Normal
X-Mailer Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE Produced By Microsoft MimeOLE V6.00.2900.2180
X-Antivirus avast! (VPS 0511-1, 2005-03-17), Outbound message
X-Antivirus-Status Clean
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
A hint (I hope) for developers.

This bug looks exactly like http://intevation.de/rt/webrt?serial_num=2937
where v.in.ogr fails in GUI mode.

Maciek

----- Original Message ----- 
From: "Request Tracker" <grass-bugs@intevation.de>
To: <grass5@grass.itc.it>
Sent: Friday, March 25, 2005 3:42 PM
Subject: [GRASS5] [bug #3117] (grass) r.out.pov fails when called out of d.m
> this bug's URL: http://intevation.de/rt/webrt?serial_num=3117
> -------------------------------------------------------------------------
>
> Subject: r.out.pov fails when called out of d.m
>
> Platform: GNU/Linux/i386
> grass obtained from: CVS
> grass binary for platform: Compiled from Sources
> GRASS Version: GRASS 6.1.cvs (2005)
>
> r.out.pov map=alt_surf4 tga=/gd/test.tga hftype=1 causes the attached
> error
> message.
>
> When called from the command line, the file becomes written.
>
>
> too many nested evaluations (infinite loop?)
>    (procedure "GlobalVar::exists" line 1)
>    invoked from within
> "GlobalVar::exists $_widget($path,var)"
>    (procedure "ProgressBar::_modify" line 4)
>    invoked from within
> "ProgressBar::_modify .dialog0.progress"
>    ("eval" body line 1)
>    invoked from within
> "eval ProgressBar::$cmd .dialog0.progress $args"
>    (procedure ".dialog0.progress" line 1)
>    invoked from within
> "$opt($dlg,progress) _modify"
>    (procedure "progress" line 7)
>    invoked from within
> "progress $dlg $val"
>    invoked from within
> "if [eof $fh] {
>                close $fh
>        } else {
>                set str [gets $fh]
>                append str "\n"
>                if { [fblocked $fh] } { set str [read $fh] }
>                while {[set idx [string f..."
>    (procedure "prnout" line 5)
>    invoked from within
> "prnout 1 file7"
>
>
>
>
>
> -------------------------------------------- Managed by Request Tracker
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>


Tue, Feb 21 2006 21:25:07    Subject changed to r.out.pov fails when called out of d.m - too many nested evaluations (infinite loop?) by msieczka  
Tue, May 16 2006 03:08:05    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 16 May 2006 13:07:42 +1200
From Hamish <hamish_nospam@yahoo.com>
To Maciek Sieczka <werchowyna@epf.pl>
Cc gardner@backserv.gsfc.nasa.gov, grass-dev@grass.itc.it, grass-bugs@intevation.de
Subject Re: [bug #3117] [GRASS-dev] povray and grass
Message-Id <20060516130742.6fab6356.hamish_nospam@yahoo.com>
In-Reply-To <20060515195310.ecf3bace.werchowyna@epf.pl>
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl>
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
> http://intevation.de/rt/webrt?serial_num=3117

I think I've fixed it in CVS. G_percent() was being called for each cell
instead of for each row of data, so the "percent done" bar was being
updated faster than the GUI could handle. Also did some other cleanup of
the code; spotted but didn't fix these errors:

fmt[20] unused and wrong. ( sprintf("%d",double) )
[I didn't remove it as I have absolutely no idea what this code is
trying to do.]

"bias" input parameter is unused and "hfBias" is used uninitialized.
[intended to be the same thing? note hfBias is used twice (in both
main() and processProfiles()), verticalScale is only used in
processProfiles()]


Further cleaning is badly needed by someone who understands it more.
[so don't close the bug]


should be functional now?


Hamish


Tue, May 16 2006 03:16:55    Subject changed to r.out.pov: bias param broken by hbowman  
Tue, May 16 2006 05:00:29    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 <17513.16431.902146.464660@cerise.gclements.plus.com>
Date Tue, 16 May 2006 03:59:59 +0100
To Hamish <hamish_nospam@yahoo.com>
Cc Maciek Sieczka <werchowyna@epf.pl>, grass-bugs@intevation.de, grass-dev@grass.itc.it
Subject Re: [bug #3117] [GRASS-dev] povray and grass
In-Reply-To <20060516130742.6fab6356.hamish_nospam@yahoo.com>
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl> <20060516130742.6fab6356.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:

> > http://intevation.de/rt/webrt?serial_num=3117
> 
> I think I've fixed it in CVS. G_percent() was being called for each cell
> instead of for each row of data, so the "percent done" bar was being
> updated faster than the GUI could handle.

In the worst case, this should just cause the module to run slowly. 
Anything else indicates a bug in the GUI code which processes the
module's output.

> Also did some other cleanup of
> the code; spotted but didn't fix these errors:
> 
> fmt[20] unused and wrong. ( sprintf("%d",double) )
> [I didn't remove it as I have absolutely no idea what this code is
> trying to do.]

Going back through the CVS history, fmt has never been used. My guess
is that r.out.pov was derived from a similar program which used a
textual output format. All of r.out.pov's output is binary.

> "bias" input parameter is unused and "hfBias" is used uninitialized.

hfBias is implicitly initialised to zero. Only automatic variables
(local variables which aren't explicitly declared "static") need an
explicit initialiser.

> [intended to be the same thing?

Probably; bias itself is unused.

-- 
Glynn Clements <glynn@gclements.plus.com>


Tue, May 16 2006 08:22:08    Mail sent by werchowyna@epf.pl  
Return-Path <werchowyna@epf.pl>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 16 May 2006 08:22:04 +0200
From Maciek Sieczka <werchowyna@epf.pl>
To Hamish <hamish_nospam@yahoo.com>
Cc gardner@backserv.gsfc.nasa.gov, grass-dev@grass.itc.it, grass-bugs@intevation.de, glynn@gclements.plus.com
Subject Re: [bug #3117] [GRASS-dev] povray and grass
Message-Id <20060516082204.5d67660f.werchowyna@epf.pl>
In-Reply-To <20060516130742.6fab6356.hamish_nospam@yahoo.com>
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl> <20060516130742.6fab6356.hamish_nospam@yahoo.com>
X-Mailer Sylpheed version 2.1.1 (GTK+ 2.8.6; i486-pc-linux-gnu)
Mime-Version 1.0
Content-Type text/plain; charset=US-ASCII
Content-Transfer-Encoding 7bit
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Tue, 16 May 2006 13:07:42 +1200
Hamish <hamish_nospam@yahoo.com> wrote:

> > http://intevation.de/rt/webrt?serial_num=3117
> 
> I think I've fixed it in CVS.

<snip>

There are other modules that happen to fail due to "too many nested
evaluations (infinite loop?)" in GUI. Those I rememeber are v.in.ogr
and v.extract. See http://intevation.de/rt/webrt?serial_num=2937

Could it be related?

Maciek

--------------------
W polskim Internecie s? setki milion?w stron. My przekazujemy Tobie tylko najlepsze
z nich!
http://katalog.panoramainternetu.pl/


Tue, May 16 2006 12:12:54    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 <17513.42375.49465.172760@cerise.gclements.plus.com>
Date Tue, 16 May 2006 11:12:23 +0100
To Maciek Sieczka <werchowyna@epf.pl>
Cc Hamish <hamish_nospam@yahoo.com>, grass-bugs@intevation.de, grass-dev@grass.itc.it
Subject Re: [bug #3117] [GRASS-dev] povray and grass
In-Reply-To <20060516082204.5d67660f.werchowyna@epf.pl>
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl> <20060516130742.6fab6356.hamish_nospam@yahoo.com> <20060516082204.5d67660f.werchowyna@epf.pl>
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
Maciek Sieczka wrote:

> > > http://intevation.de/rt/webrt?serial_num=3117
> > 
> > I think I've fixed it in CVS.
> 
> <snip>
> 
> There are other modules that happen to fail due to "too many nested
> evaluations (infinite loop?)" in GUI. Those I rememeber are v.in.ogr
> and v.extract. See http://intevation.de/rt/webrt?serial_num=2937
> 
> Could it be related?

I don't know, but I notice that both of those modules have incorrect
startup code.

v.in.ogr calls various GRASS functions before G_parser() has returned,
while v.extract calls the G_define_* functions before calling
G_gisinit().

-- 
Glynn Clements <glynn@gclements.plus.com>


Tue, May 16 2006 14:17:50    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <4469C2E6.4060006@itc.it>
Date Tue, 16 May 2006 14:17:42 +0200
From Markus Neteler <neteler@itc.it>
User-Agent Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929)
X-Accept-Language en-us, en
MIME-Version 1.0
To grass-dev@grass.itc.it
Cc grass-bugs@intevation.de
Subject Re: [bug #3117] [GRASS-dev] povray and grass
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl> <20060516130742.6fab6356.hamish_nospam@yahoo.com> <20060516082204.5d67660f.werchowyna@epf.pl> <17513.42375.49465.172760@cerise.gclements.plus.com>
In-Reply-To <17513.42375.49465.172760@cerise.gclements.plus.com>
X-Enigmail-Version 0.93.0.0
OpenPGP url=http://mpa.itc.it/markus/markus_gpgkey.asc
Content-Type text/plain; charset=ISO-8859-1
Content-Transfer-Encoding 7bit
X-OriginalArrivalTime 16 May 2006 12:17:41.0847 (UTC) FILETIME=[BACB5E70:01C678E2]
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Glynn Clements wrote:

>Maciek Sieczka wrote:
>
>  
>
>>>>http://intevation.de/rt/webrt?serial_num=3117
>>>>        
>>>>
>>>I think I've fixed it in CVS.
>>>      
>>>
>><snip>
>>
>>There are other modules that happen to fail due to "too many nested
>>evaluations (infinite loop?)" in GUI. Those I rememeber are v.in.ogr
>>and v.extract. See http://intevation.de/rt/webrt?serial_num=2937
>>
>>Could it be related?
>>    
>>
>
>I don't know, but I notice that both of those modules have incorrect
>startup code.
>
>v.in.ogr calls various GRASS functions before G_parser() has returned,
>while v.extract calls the G_define_* functions before calling
>G_gisinit().
>  
>

Glynn,

numerous modules are using G_define_standard_option(). I don't see why
this should be a problem.
The function is in lib/gis/parser.c

Markus


Wed, May 17 2006 11:36:53    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 <17514.61093.663514.762340@cerise.gclements.plus.com>
Date Wed, 17 May 2006 10:36:37 +0100
To Markus Neteler <neteler@itc.it>
Cc grass-dev@grass.itc.it, grass-bugs@intevation.de
Subject Re: [bug #3117] [GRASS-dev] povray and grass
In-Reply-To <4469C2E6.4060006@itc.it>
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl> <20060516130742.6fab6356.hamish_nospam@yahoo.com> <20060516082204.5d67660f.werchowyna@epf.pl> <17513.42375.49465.172760@cerise.gclements.plus.com> <4469C2E6.4060006@itc.it>
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
Markus Neteler wrote:

> >>>>http://intevation.de/rt/webrt?serial_num=3117
> >>>>        
> >>>>
> >>>I think I've fixed it in CVS.
> >>>      
> >>>
> >><snip>
> >>
> >>There are other modules that happen to fail due to "too many nested
> >>evaluations (infinite loop?)" in GUI. Those I rememeber are v.in.ogr
> >>and v.extract. See http://intevation.de/rt/webrt?serial_num=2937
> >>
> >>Could it be related?
> >>    
> >>
> >
> >I don't know, but I notice that both of those modules have incorrect
> >startup code.
> >
> >v.in.ogr calls various GRASS functions before G_parser() has returned,
> >while v.extract calls the G_define_* functions before calling
> >G_gisinit().
> 
> numerous modules are using G_define_standard_option(). I don't see why
> this should be a problem.
> The function is in lib/gis/parser.c

Those functions aren't the problem. The problem with v.extract is that
it's calling them before it calls G_gisinit(), which is supposed to be
called before any other GRASS function.

[Apart from anything else, G_gisinit() sets the program name, which is
used by G_fatal_error(), so anything which might cause G_fatal_error()
to be called (i.e. almost everything) cannot safely be called before
G_[no_]gisinit().]

I have no idea whether or not this actually causes problems at
present; I'm just pointing out that it's a bug regardless of whether
or not you happen to "get away with it".

OTOH, the bug in v.in.ogr is very likely to cause problems. In order
for alternate execution modes (--help, --tcltk etc) to work, it is
essential that the module doesn't attempt to actually do /anything/
except declare its options until after G_parser() returns (/if/ it
returns, which it won't if any of the alternate execution modes are
used).

Module authors/maintainers need to stop overlooking this issue.

Based upon past experience, this may require that they are forced to
stop overlooking this issue, e.g. by making most functions generate a
fatal error if called before G_parser().

[I suspect that this can be implemented by adding checks to a few core
functions, e.g. G_getenv(), G_get_window() etc. Anything which doesn't
call those is probably safe to call at any point.]

Future developments are likely to make this more important. E.g. it
ought to be possible to override most GRASS state using command-line
switches. Of course, command-line switches won't have any effect until
G_parser() has been called. If a module calls GRASS functions which
access such state prior to calling G_parser(), it will use the wrong
state and thus get the wrong results.

Just in case it isn't clear, the only functions which can legitimately
be called before G_parser are:

	G_gisinit
	G_no_gisinit
	G_define_module
	G_define_flag
	G_define_option
	G_define_standard_option
	G_disable_interactive

-- 
Glynn Clements <glynn@gclements.plus.com>


Wed, May 17 2006 13:59:20    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 17 May 2006 13:59:14 +0200
From Markus Neteler <neteler@itc.it>
To grass-dev@grass.itc.it
Cc grass-bugs@intevation.de
Subject Re: [bug #3117] [GRASS-dev] povray and grass
Message-ID <20060517115914.GH24070@bartok.itc.it>
Mail-Followup-To grass-dev@grass.itc.it, grass-bugs@intevation.de
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl> <20060516130742.6fab6356.hamish_nospam@yahoo.com> <20060516082204.5d67660f.werchowyna@epf.pl> <17513.42375.49465.172760@cerise.gclements.plus.com> <4469C2E6.4060006@itc.it> <17514.61093.663514.762340@cerise.gclements.plus.com>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <17514.61093.663514.762340@cerise.gclements.plus.com>
X-PGP-Key http://www.gdf-hannover.de/neteler/markus_gpgkey.asc
X-PGP-Fingerprint D4D5 2F80 120E AD60 E2F6 2297 21B3 D02B E1E7 E789
User-Agent Mutt/1.5.11
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Wed, May 17, 2006 at 10:36:37AM +0100, Glynn Clements wrote:
> Markus Neteler wrote:
> > >>>>http://intevation.de/rt/webrt?serial_num=3117
> > >>
> > >>There are other modules that happen to fail due to "too many nested
> > >>evaluations (infinite loop?)" in GUI. Those I rememeber are v.in.ogr
> > >>and v.extract. See http://intevation.de/rt/webrt?serial_num=2937
> > >>
> > >>Could it be related?
> > >>
> > >
> > >I don't know, but I notice that both of those modules have incorrect
> > >startup code.
> > >
> > >v.in.ogr calls various GRASS functions before G_parser() has returned,
> > >while v.extract calls the G_define_* functions before calling
> > >G_gisinit().
> > 
> > numerous modules are using G_define_standard_option(). I don't see why
> > this should be a problem.
> > The function is in lib/gis/parser.c
> 
> Those functions aren't the problem. The problem with v.extract is that
> it's calling them before it calls G_gisinit(), which is supposed to be
> called before any other GRASS function.

OK. I have fixed the position of G_gisinit() in v.extract.
 
> [Apart from anything else, G_gisinit() sets the program name, which is
> used by G_fatal_error(), so anything which might cause G_fatal_error()
> to be called (i.e. almost everything) cannot safely be called before
> G_[no_]gisinit().]
> 
> I have no idea whether or not this actually causes problems at
> present; I'm just pointing out that it's a bug regardless of whether
> or not you happen to "get away with it".

Apparently this needs to be better documented. Where?

> OTOH, the bug in v.in.ogr is very likely to cause problems. In order
> for alternate execution modes (--help, --tcltk etc) to work, it is
> essential that the module doesn't attempt to actually do /anything/
> except declare its options until after G_parser() returns (/if/ it
> returns, which it won't if any of the alternate execution modes are
> used).
> 
> Module authors/maintainers need to stop overlooking this issue.
> 
> Based upon past experience, this may require that they are forced to
> stop overlooking this issue, e.g. by making most functions generate a
> fatal error if called before G_parser().

This might be a good idea to actually catch such problems.
Since there are often *many* authors/maintainers, and code sometimes
originates from 20 years back, we have to enforce it.

There are a couple of candidates which do calculations within
the parameter/flag definition part.

> [I suspect that this can be implemented by adding checks to a few core
> functions, e.g. G_getenv(), G_get_window() etc. Anything which doesn't
> call those is probably safe to call at any point.]
> 
> Future developments are likely to make this more important. E.g. it
> ought to be possible to override most GRASS state using command-line
> switches. Of course, command-line switches won't have any effect until
> G_parser() has been called. If a module calls GRASS functions which
> access such state prior to calling G_parser(), it will use the wrong
> state and thus get the wrong results.
> 
> Just in case it isn't clear, the only functions which can legitimately
> be called before G_parser are:
> 
> 	G_gisinit
> 	G_no_gisinit
> 	G_define_module
> 	G_define_flag
> 	G_define_option
> 	G_define_standard_option
> 	G_disable_interactive
>

Question: Why does d.vect work since G_gisinit() comes right
before G_parser()? Because the definition part is "clean"?

Markus


Thu, May 18 2006 00:37:37    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 <17515.42384.372999.836149@cerise.gclements.plus.com>
Date Wed, 17 May 2006 23:37:04 +0100
To Markus Neteler <neteler@itc.it>
Cc grass-dev@grass.itc.it, grass-bugs@intevation.de
Subject Re: [bug #3117] [GRASS-dev] povray and grass
In-Reply-To <20060517115914.GH24070@bartok.itc.it>
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl> <20060516130742.6fab6356.hamish_nospam@yahoo.com> <20060516082204.5d67660f.werchowyna@epf.pl> <17513.42375.49465.172760@cerise.gclements.plus.com> <4469C2E6.4060006@itc.it> <17514.61093.663514.762340@cerise.gclements.plus.com> <20060517115914.GH24070@bartok.itc.it>
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
Markus Neteler wrote:

> > [Apart from anything else, G_gisinit() sets the program name, which is
> > used by G_fatal_error(), so anything which might cause G_fatal_error()
> > to be called (i.e. almost everything) cannot safely be called before
> > G_[no_]gisinit().]
> > 
> > I have no idea whether or not this actually causes problems at
> > present; I'm just pointing out that it's a bug regardless of whether
> > or not you happen to "get away with it".
> 
> Apparently this needs to be better documented. Where?

It's the first section (after "Introduction") in the libgis
documentation:

http://mpa.itc.it/markus/grass61progman/gislib.html#init

    Library Initialization
    
    It is mandatory that the system be initialized before any other
    library routines are called.
    
    int G_gisinit(char *program_name) initialize gis library

[snip]

I'm not sure that it can be made much clearer than that (especially as
"mandatory" is in bold type).

OTOH, the front page of the Programmer's Manual simply lists all of
the libraries in alphabetical order, with libgis treated as just one
of many libraries, when it's really rather more important than e.g. 
the bitmap or btree libraries.

> > OTOH, the bug in v.in.ogr is very likely to cause problems. In order
> > for alternate execution modes (--help, --tcltk etc) to work, it is
> > essential that the module doesn't attempt to actually do /anything/
> > except declare its options until after G_parser() returns (/if/ it
> > returns, which it won't if any of the alternate execution modes are
> > used).
> > 
> > Module authors/maintainers need to stop overlooking this issue.
> > 
> > Based upon past experience, this may require that they are forced to
> > stop overlooking this issue, e.g. by making most functions generate a
> > fatal error if called before G_parser().
> 
> This might be a good idea to actually catch such problems.
> Since there are often *many* authors/maintainers, and code sometimes
> originates from 20 years back, we have to enforce it.
> 
> There are a couple of candidates which do calculations within
> the parameter/flag definition part.

Yes; those are the most common reasons/excuses for reading the state
before G_parser() returns.

This has already caused problems with e.g. --html-description,
requiring the construction of a temporary mapset in order to generate
the HTML pages, due to modules requiring a valid mapset simply to
generate help text, HTML pages or the Tcl/Tk UI code. ISTR that a few
modules tried to use the active monitor; I don't know if they have
been fixed yet.

> > [I suspect that this can be implemented by adding checks to a few core
> > functions, e.g. G_getenv(), G_get_window() etc. Anything which doesn't
> > call those is probably safe to call at any point.]
> > 
> > Future developments are likely to make this more important. E.g. it
> > ought to be possible to override most GRASS state using command-line
> > switches. Of course, command-line switches won't have any effect until
> > G_parser() has been called. If a module calls GRASS functions which
> > access such state prior to calling G_parser(), it will use the wrong
> > state and thus get the wrong results.
> > 
> > Just in case it isn't clear, the only functions which can legitimately
> > be called before G_parser are:
> > 
> > 	G_gisinit
> > 	G_no_gisinit
> > 	G_define_module
> > 	G_define_flag
> > 	G_define_option
> > 	G_define_standard_option
> > 	G_disable_interactive
> 
> Question: Why does d.vect work since G_gisinit() comes right
> before G_parser()? Because the definition part is "clean"?

Yes. The G_define_* functions (and G_gettext(), used by the _() macro)
are (currently) sufficiently trivial that they don't depend upon
library initialisation. The only thing which could go wrong is if
G_malloc() fails to obtain enough memory for a Flag/Option struct
(which is highly unlikely).

-- 
Glynn Clements <glynn@gclements.plus.com>


Thu, May 18 2006 04:32:09    Mail sent by hamish_nospam@yahoo.com  
Return-Path <hamish_nospam@yahoo.com>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 18 May 2006 14:31:20 +1200
From Hamish <hamish_nospam@yahoo.com>
To Glynn Clements <glynn@gclements.plus.com>
Cc grass-bugs@intevation.de, grass-dev@grass.itc.it, neteler@itc.it
Subject Re: [bug #3117] [GRASS-dev] povray and grass [-> 6.1.0 freeze & release?]
Message-Id <20060518143120.6ec57f2b.hamish_nospam@yahoo.com>
In-Reply-To <17514.61093.663514.762340@cerise.gclements.plus.com>
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl> <20060516130742.6fab6356.hamish_nospam@yahoo.com> <20060516082204.5d67660f.werchowyna@epf.pl> <17513.42375.49465.172760@cerise.gclements.plus.com> <4469C2E6.4060006@itc.it> <17514.61093.663514.762340@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
> Those functions aren't the problem. The problem with v.extract is that
> it's calling them before it calls G_gisinit(), which is supposed to be
> called before any other GRASS function.
> 
> [Apart from anything else, G_gisinit() sets the program name, which is
> used by G_fatal_error(), so anything which might cause G_fatal_error()
> to be called (i.e. almost everything) cannot safely be called before
> G_[no_]gisinit().]
> 
> I have no idea whether or not this actually causes problems at
> present; I'm just pointing out that it's a bug regardless of whether
> or not you happen to "get away with it".


Added some comments to lib/gis/parser.c about this for more visibility.
(non-doxygenized header)

I notice g.region has fallen afoul of this rule in the last 2 weeks.


If the change is to be made so stuff happening before G_parser() will
trigger a fatal error, can this wait until after 6.1.0 is released?

On the subject of 6.1.0, are there objections to declaring the feature
freeze in force /as of now/ and plan for a release date of 1 June?
We need to stop breaking and refactoring things for a little while.
AFAICT things have gotten *less* stable since the start of this month,
the original time the freeze was suggested to begin. And 6.1.0 is
overdue.

I would like to freeze everything but gis.m and the r.3D modules- I
don't want to kill the development momentum they currently enjoy. Gis.m
is important to have working well, and changes to the r3.* modules
shouldn't touch the rest of the package. Radim had mentioned he thought
it unpracticable to do a half-freeze. As the freeze will last until
6.2.0 is released in (guessing) 4-6 months time, we need to figure out
some solution - any new release is stalled until we do.
6.1.0 should be a CVS tag, development continues in CVS/HEAD, yes?
& 6.2.0 starts a new CVS branch.

The only important new thing I think needs to happen before 6.1.0 is to
finish any outstanding translation prep work, as suggested by Cedric,
  http://article.gmane.org/gmane.comp.gis.grass.devel/12229

We also need to go through the bug tracker and increase the priority of
any bugs we consider Release-Critical for 6.2. I don't think we have any
true RC bugs: no active security bugs and fails-to-build stuff gets
fixed quickly, so I mean rough-edges like adding v.in.ogr split code and
lingering v.buffer warts. NVIZ segfault on Vector points save (#4377)
and cleaner d.labels text rotation too.

For kicks and giggles we could prepare 6.0.3 and 5.4.1 rc-1 at the same
time as 6.1.0, and release them soon after.
I'm not sure if this is fixed yet, but it would be very nice if 5.4.1
could ignore the extra 3D lines in a GRASS 6 mapset's WIND file
gracefully. The 5.4 release branch probably needs some merging from
grass5 HEAD; I think 6.0.x branch has been kept pretty much up to date.


??,
Hamish


Thu, May 18 2006 11:23:03    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Message-ID <446C3CF3.9030405@itc.it>
Date Thu, 18 May 2006 11:22:59 +0200
From Markus Neteler <neteler@itc.it>
User-Agent Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929)
X-Accept-Language en-us, en
MIME-Version 1.0
To grass-dev@grass.itc.it
Cc grass-bugs@intevation.de
Subject Re: [bug #3117] [GRASS-dev] povray and grass
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl> <20060516130742.6fab6356.hamish_nospam@yahoo.com> <20060516082204.5d67660f.werchowyna@epf.pl> <17513.42375.49465.172760@cerise.gclements.plus.com> <4469C2E6.4060006@itc.it> <17514.61093.663514.762340@cerise.gclements.plus.com> <20060517115914.GH24070@bartok.itc.it> <17515.42384.372999.836149@cerise.gclements.plus.com>
In-Reply-To <17515.42384.372999.836149@cerise.gclements.plus.com>
X-Enigmail-Version 0.93.0.0
OpenPGP url=http://mpa.itc.it/markus/markus_gpgkey.asc
Content-Type text/plain; charset=ISO-8859-1
Content-Transfer-Encoding 7bit
X-OriginalArrivalTime 18 May 2006 09:22:59.0251 (UTC) FILETIME=[A781A830:01C67A5C]
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Glynn Clements wrote:

>It's the first section (after "Introduction") in the libgis
>documentation:
>
>http://mpa.itc.it/markus/grass61progman/gislib.html#init
>
>    Library Initialization
>    
>...
>
>OTOH, the front page of the Programmer's Manual simply lists all of
>the libraries in alphabetical order, with libgis treated as just one
>of many libraries, when it's really rather more important than e.g. 
>the bitmap or btree libraries.
>  
>

I have made libgis more outstanding now
(http://mpa.itc.it/markus/grass61progman/)
The file to change was lib/index.dox . All developers are kindly invited
to improve
the documentation (see .dox files in the source code).

Markus


Thu, May 18 2006 14:27:36    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 <17516.26667.581158.948051@cerise.gclements.plus.com>
Date Thu, 18 May 2006 13:27:23 +0100
To Hamish <hamish_nospam@yahoo.com>
Cc neteler@itc.it, grass-bugs@intevation.de, grass-dev@grass.itc.it
Subject Re: [bug #3117] [GRASS-dev] povray and grass [-> 6.1.0 freeze & release?]
In-Reply-To <20060518143120.6ec57f2b.hamish_nospam@yahoo.com>
References <1147705369.25093.9.camel@forbin> <20060515175219.8e45ce43.werchowyna@epf.pl> <1147714359.26176.3.camel@forbin> <20060515195310.ecf3bace.werchowyna@epf.pl> <20060516130742.6fab6356.hamish_nospam@yahoo.com> <20060516082204.5d67660f.werchowyna@epf.pl> <17513.42375.49465.172760@cerise.gclements.plus.com> <4469C2E6.4060006@itc.it> <17514.61093.663514.762340@cerise.gclements.plus.com> <20060518143120.6ec57f2b.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:

> > Those functions aren't the problem. The problem with v.extract is that
> > it's calling them before it calls G_gisinit(), which is supposed to be
> > called before any other GRASS function.
> > 
> > [Apart from anything else, G_gisinit() sets the program name, which is
> > used by G_fatal_error(), so anything which might cause G_fatal_error()
> > to be called (i.e. almost everything) cannot safely be called before
> > G_[no_]gisinit().]
> > 
> > I have no idea whether or not this actually causes problems at
> > present; I'm just pointing out that it's a bug regardless of whether
> > or not you happen to "get away with it".
> 
> Added some comments to lib/gis/parser.c about this for more visibility.
> (non-doxygenized header)
> 
> I notice g.region has fallen afoul of this rule in the last 2 weeks.

I noticed that g.region didn't comply (use of llinfo() and
G_{lat,lon}_format_string()) when I updated it to handle GRASS_REGION
and WIND_OVERRIDE, but I didn't realise that this was recent.

> If the change is to be made so stuff happening before G_parser() will
> trigger a fatal error, can this wait until after 6.1.0 is released?

Certainly.

In any case, the change would initially need to be done in such a way
that it could be disabled easily, in case it turns out that a
substantial proportion of modules don't comply (especially critical
ones such as g.region).

Intentionally triggering bugs as a mechanism to get them fixed only
works if it doesn't result in everyone just reverting to the previous
version.

> On the subject of 6.1.0, are there objections to declaring the feature
> freeze in force /as of now/ and plan for a release date of 1 June?
> We need to stop breaking and refactoring things for a little while.
> AFAICT things have gotten *less* stable since the start of this month,
> the original time the freeze was suggested to begin. And 6.1.0 is
> overdue.
> 
> I would like to freeze everything but gis.m and the r.3D modules- I
> don't want to kill the development momentum they currently enjoy. Gis.m
> is important to have working well,

The main issue there is that gis.m development may highlight further
architectural problems within GRASS. IOW, you might find that making
specific features work (or fixing specific bugs) requires potentially
destabilising changes to core GRASS code.

> I'm not sure if this is fixed yet, but it would be very nice if 5.4.1
> could ignore the extra 3D lines in a GRASS 6 mapset's WIND file
> gracefully. The 5.4 release branch probably needs some merging from
> grass5 HEAD; I think 6.0.x branch has been kept pretty much up to date.

I suspect that we've reached the point where maintaining 5.x is
becoming impractical. I haven't looked at it in months; I haven't even
done "cvs update" since early February. Anything beyond trivial
bug-fixes would require climbing the learning curve again.

-- 
Glynn Clements <glynn@gclements.plus.com>


Comment | Reply | Take | Resolve

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request