Fri, Feb 18 2005
00:06:49
|
|
Request created by guest
|
|
Subject: invisible errors in GUI
Platform: GNU/Linux/i386
grass obtained from: Mirror of Trento site
grass binary for platform: Compiled from Sources
GRASS Version: grass-6.0.cvs_src_snapshot_2005_01_22
Error information like:
Segmenation fault
File size limit exceeded
Is NOT DISPLAYED AT ALL when it happens to a command invoked from GUI. Neither
any other info is printed. So the user doesn't know what's is going on and may
be waiting forever for some output.
If not possible to display such information in GUI then redirect it at least
to terminal?
Maciek |
|
Sat, Jul 23 2005
15:18:18
|
|
Area changed to grass6.1 by msieczka
|
|
Wed, Aug 31 2005
20:48:34
|
|
Area changed to grass6 by mneteler
|
|
Fri, Sep 2 2005
18:37:55
|
|
User changed to werchowyna@epf.pl by msieczka
|
|
Sun, Feb 26 2006
10:42:30
|
|
Subject changed to segfaluts invisible in GUI by msieczka
|
|
Sun, Feb 26 2006
10:43:07
|
|
Subject changed to segfaults invisible in GUI by msieczka
|
|
Tue, Apr 4 2006
19:17:10
|
|
Mail sent by cshock
|
|
Maciek,
By GUI I assume you mean d.m, gis.m, or grasstcltk.
This happens because standard error is (was) being directed to /dev/null to
keep it from "polluting" the terminal. It currently isn't doing so in some
places that it was before; the new "gronsole" code for running and displaying
output that is used in the command line guis (gui.tcl) and gis.m uses the old
behaviour of gui.tcl and does not redirect standard error to /dev/null.
(aside: It actually redirects it to standard output to avoid errors on closing
the pipe, this isn't really necessary).
The partial sollution for this is to capture standard error and include it in
the output displayed in the guis, especially since SUBMITTING (as I understand
it) demands that all purely informative output is to standard error.
There are many many procs used in gis.m and d.m to run programs, and many
other parts of these GUIs run programs via exec without calling an abstracting
proc. Most of these other uses of exec and open redirect output and standard
error in odd fashions. Those that don't redirect standard error or catch exec
and close will throw errors if there is any standard error output, which is
probably the correct behaviour for segfaults, but is incorrect much of the
time when modules are spitting informative information into standard error.
Consequently most of these calls use redirection or catching and the error
output is lost. This makes somewhat of a difficult web to unentangle.
--Cedric
The thread "[GRASS5] General and gis.m module running (stdout,stderr,exit
status) issues" has some somewhat related discussion that could be considered
an instance of this problem. |
|
Tue, Apr 4 2006
19:25:18
|
|
Mail sent by msieczka
|
|
The thread Cedric refers to is here:
http://grass.itc.it/pipermail/grass5/2006-April/022122.html
Maciek
|
|
Fri, Jul 7 2006
16:46:30
|
|
Mail sent by guest
|
|
Hi,
still an issue? Maybe Cedric has further comments?
Markus |
|
Wed, Jul 26 2006
14:23:42
|
|
User changed to tutey@o2.pl by msieczka
|
|