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 par
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 w
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
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.
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 memo
Mark Feit (2019-Feb-03, excerpt):
>
> What was not done:
[...]
> No effort has been made to do any kind of clean shutdown. I need some
> advice from the learned on how to approach that.
IMHO it would not make sense to try to be overly smart here. A system
with failing `malloc` is on the brink of
On 2/4/19 2:22 AM, Andreas Schneider wrote:
If you want to change allocations anyway, you should really take a
look at
talloc [1]. talloc is a hierarchical, reference counted memory pool system
with destructors. If you free the top memory context all children will be
freed to. It is just fun wor
On Sunday, 3 February 2019 18:17:00 CET Mark Feit wrote:
> (This has been split off from the static code analysis thread since it's
> a different topic.)
>
> I've completed the first cut of an overhaul of the use of dynamic memory
> allocation in the source tree with an eye toward safety and an ev
