Crashing is indeed a good outcome in the event of allocation failure. Null pointer dereference though is not guaranteed to produce a crash, at least, according to C spec, it's undefined behavior. (I know it often causes crash in practice but that's not guaranteed) Perhaps there's need for something like "assert(X != null)" where X is the result of calling the allocation routine and then that should be indeed helpful for debugging.
On Tue, Feb 5, 2019 at 3:53 PM parafin <para...@paraf.in> wrote: > 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 <mf...@notonthe.net> 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 > darktable-dev+unsubscr...@lists.darktable.org > > > ___________________________________________________________________________ > darktable developer mailing list > to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
