One can argue that crashing might be helpful for debugging - backtrace is produced and it's possible to deduce the reason DT exited. E.g. if some allocation size is computed too high (say due to integer underflow) malloc can fail and if we just exit cleanly we will lose all context of the failure. Also it might be surprising for user unless DT prints some error message (which BTW won't be seen in most cases because DT is usually started by users without opening a terminal window).
On Tue, 5 Feb 2019 08:47:36 -0500 Mark Feit <[email protected]> wrote: > On 2/5/19 3:10 AM, Stefan Klinger wrote: > > IMHO it would not make sense to try to be overly smart here. A system > > with failing `malloc` is on the brink of desaster, and writing > > failsave code under these conditions is extremely difficult. For one, > > the recovery routines must not try to allocate memory. > > Not looking for fail-safe so much as fail-nicely: don't SIGESEGV by > trying to use the NULL from a failed malloc(), just close the database, > remove the lock file and head for the exit(). I've had dt crash hard > enough times that I'm not worried about state. The most I can recall > losing is what I was doing on one image. > > What I added exits through a function called dt_fail(), which provides a > good single point of exit. What happens there can be a subject for > later discussion. > > --Mark > > > ___________________________________________________________________________ > darktable developer mailing list > to unsubscribe send a mail to [email protected] > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to [email protected]
