[bug #3117] [GRASS-dev] povray and grass

Glynn Clements glynn at gclements.plus.com
Wed May 17 05:36:37 EDT 2006


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 at gclements.plus.com>




More information about the grass-dev mailing list