bugPSPP - Bugs: bug #20874, Exit gracefully if glade files...

 
 

bug #20874: Exit gracefully if glade files cannot be found.

Submitter:  John Darrington <jmd>
Submitted:  Wed 22 Aug 2007 11:14:24 PM UTC
   
 
Category:  Compilation/Portability Severity:  1 - Wishlist
Status:  Fixed Assigned to:  None
Open/Closed:  Closed Release:  Before 0.6.0
Effort:  0.00
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 26 Aug 2007 11:54:19 PM UTC, comment #7: 

Closing this one as everyone seems agreeable.

John Darrington <jmd>
Group administrator
Sun 26 Aug 2007 12:19:11 AM UTC, comment #6: 


>So far as I'm aware there isn't such a scheme. I suppose we could
>check the md5sum of the glade files at startup.


Not really worth it (yet), I guess.

>(Personally I'm not a big fan of the way glade files work. It's
>like having all your C variables in a separate file which gets
>dynamically loaded at run time.)


It's too bad that the option of compiling them into C code was dropped in glade 3, I guess.

Ben Pfaff <blp>
Group administrator
Fri 24 Aug 2007 11:58:46 PM UTC, comment #5: 


> Usually, program libraries and shared objects have a versioning scheme
> to make it difficult to mis-match incompatible versions. I don't know
> whether there is a corresponding scheme for .glade files. If there
> is, I hope that we can use it, at least to the extent that each PSPP
> official release has a unique version.


So far as I'm aware there isn't such a scheme.  I suppose we could check the md5sum of the glade files at startup.

(Personally I'm not a big fan of the way glade files work.  It's like having all your C variables in a separate file which gets dynamically loaded at run time.)


John Darrington <jmd>
Group administrator
Fri 24 Aug 2007 03:14:10 PM UTC, comment #4: 


> > Usually software should be written so that data files cannot cause
> > it to crash.
> To talk about that, we need to define "data file" and "crash". The
> glade files can be considered `code' which happens to be written in
> XML instead of C.


Yes, this is true.

Usually, program libraries and shared objects have a versioning scheme
to make it difficult to mis-match incompatible versions.  I don't know
whether there is a corresponding scheme for .glade files.  If there
is, I hope that we can use it, at least to the extent that each PSPP
official release has a unique version.

> Similary, is an assertion failure a `crash' or an
> error message followed by exit?


It's a crash.  IMO, assertions should only be used for conditions that
cannot happen unless there is a bug in the application.  The PSPP
handler for assertion failure even explicitly tells the user that
there is a bug and that we would like to hear about it.

That's the way I feel about "assert", anyhow.  GTK+ seems to have a
litany of assertion-like constructs with different properties.  I've
never looked at those, so I don't really know how I feel about them.

> If an out-of-date glade file, doesn't provide an essential widget, or
> the set of properties that the code expects, then there is no way the
> code could handle this (in the genreal case). The only sensible thing
> it can do is give up. The question is, when should it decide to give
> up? and what error message(s) should it produce?


Giving up quickly, if the error cannot be recovered from, is just
fine.  A message like "PSPP file '....' is missing or out-of-date.
Please run "make install"." would be perfect IMO, but I think that
your message "could not find glad file '....'." is fine too.

Ben Pfaff <blp>
Group administrator
Fri 24 Aug 2007 05:30:48 AM UTC, comment #3: 


> Usually software should be written so that data files cannot cause it to crash.


To talk about that, we need to define "data file" and "crash". The glade files can be considered `code' which happens to be written in XML instead of C.  Similary, is an assertion failure a `crash' or an error message followed by exit?

If an out-of-date glade file, doesn't provide an essential widget, or the set of properties that the code expects, then there is no way the code could handle this (in the genreal case). The only sensible thing it can do is give up.   The question is, when should it decide to give up? and what error message(s) should it produce?

John Darrington <jmd>
Group administrator
Fri 24 Aug 2007 04:59:16 AM UTC, comment #2: 


>IMO, the error messages make it pretty obvious what the problem
>is. Do people think we need to make it more explicit?


It's a big improvement.  I think it's sufficient, at least until we get further bug reports.

(I didn't try it.)

>...an out of date version of a glade file could also cause a
>crash.


Really?  That's disappointing.  Usually, software should be written so that data files cannot cause it to crash.

Ben Pfaff <blp>
Group administrator
Thu 23 Aug 2007 05:27:51 AM UTC, comment #1: 

I checked in a patch which handles missing icon files a little better.

If one now neglects to run make install, one gets:

* (psppire:28791): WARNING *: Cannot create icon: Failed to open file '/home/jmd/tmp.GYdfm19808/share/pspp/string.png': No such file or directory

 .
 .
 .

(psppire:28791): libglade-WARNING **: could not find glade file '/home/res/tmp.GYdfm19808/share/pspp/data-editor.glade'

* ERROR *: file src/ui/gui/helper.c: line 101 (get_widget_assert): assertion failed: (xml)
aborting...
Aborted


IMO, the error  messages make it pretty obvious what the problem is.  Do people think we need to make it more explicit?

John Darrington <jmd>
Group administrator
Wed 22 Aug 2007 11:14:24 PM UTC, original submission:  

If the person building psppire forgets to run "make install", then the program will crash on startup.  We should check that the files can be found and exit more gracefully.

How far do we want to take this check?  For example, an out of date version of a glade file could also cause a crash.  Perhaps we should check a date stamp or something?

John Darrington <jmd>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by blp (Posted a comment)
  • -email is unavailable- added by jmd (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-08-26 jmd StatusWorks For Me Fixed
        Assigned tojmd None
        Open/ClosedOpen Closed
    2007-08-24 blp StatusIn Progress Works For Me
    2007-08-23 jmd StatusNone In Progress
    2007-08-22 jmd ReleaseNone Before 0.6.0

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code