On 2/5/19 10:20 AM, parafin 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).
My definition of cleanly includes leaving a hint on the way out. dt_exit() takes printf()-style arguments, so it will have a reason in hand if the caller provides one, which the sanity-checked allocators do. (See https://github.com/markfeit/darktable/blob/9c0787a3875708a94c8f7ae5cdcf33309c837606/src/common/utility.c#L60 and the functions directly below it.)
What the program does with that information on the way out is up for discussion. What I have there now prints a message to stderr and exits 1 which, as you point out, isn't going to be seen any more than the prior segfaults if the program wasn't launched in a terminal. Writing the message to a file in the config directory would be a reasonably-safe option if stderr isn't a tty. Opening a dialog box to display the message before exiting would be another except in the OOM case. Even then, de-initializing as much of dt as possible might free up enough RAM to make that work, but there are other things that could stymie it. Calling abort() would produce an abnormal end that would end up dumping core on Linux or as a crash report on OS X. I have no idea what Windows would do.
This puts dt better off in terms of code quality and no worse off in terms of UX when the program has to die. That's a net positive. The UX problem is bigger than this.
--Mark ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
