[GRASS-dev] Vect_*_fatal_error()

Glynn Clements glynn at gclements.plus.com
Sat Nov 12 20:08:15 EST 2011


Wenzeslaus wrote:

> Nowadays there is wxGUI code which uses calls via ctypes. Would it by
> possible to temporary change behaviour of G_fatal_error() to enable
> redirect module output back to console and then print message and do
> exit? (AFAIK, now an error message is showed in GUI and then GUI
> fails, so user and programmer don't see the message.)

Maybe. G_fatal_error() could (try to) write to /dev/tty rather than
stderr. But that won't work if there isn't a controlling tty (and may
be annoying if you have intentionally redirected stderr).

Or G__gisinit() could store fileno(stderr) at start-up; but that won't
work if the GUI closes stderr when it redirects it. More robust would
be e.g.:

	error_fp = fdopen(dup(fileno(stderr)), "w");

> I know that this solution doesn't follow the idea of calling modules
> (and not using library directly), but now it seems to be much easier
> to do this change than rewrite parts of wxGUI which uses ctypes.

That needs to be done anyhow. The longer people ignore this fact and
hope that it somehow just goes away, the more work will ultimately be
required to fix it.

Note that the problem isn't the use of ctypes per se, but its use in
the main GUI process. Something like nviz can't avoid using ctypes,
but it needs to be a separate process (i.e. the GUI should "execute"
the nviz component, not "import" it). That way, a fatal error or a
signal only kills the nviz component, not the whole GUI (well, unless
it's a video driver bug; those frequently kill the X server and
occasionally the kernel, so whether or not it kills the GUI is moot).

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


More information about the grass-dev mailing list