heya, just to be sure it is very clear.. what parafin is referring to is that darktable catches say a sigsegv and writes out the stack trace (not only in theory you could debug it if you had run it through gdb), see src/common/system_signal_handling.c.
(not a fan of popup modal dialogs for my part.) cheers, jo On Wed, Feb 6, 2019 at 10:59 AM Mark Feit <[email protected]> wrote: > > 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 [email protected] > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to [email protected]
