Details Ticket 3010


Comment | Reply | Take | Resolve


Serial Number 3010
Subject segfaults invisible in GUI
Area grass6
Queue grass
Requestors tutey@o2.pl
Owner none
Status open
Last User Contact Fri Jul 7 16:46:30 2006 (2 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Wed Jul 26 14:23:42 2006 (2 yr ago)
Created Fri Feb 18 00:06:49 2005 (4 yr ago)

Transaction History Ticket 3010


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  
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