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
Hi! I am following this guide to compiling on Windows:
https://raw.githubusercontent.com/darktable-org/darktable/master/packaging/windows/BUILD.txt
When I execute the following step
cmake --build .
It gets to about 77% and then I get a bunch of "deprecated" errors:
In file included from
C:/ms
Hi Pascal,
Thanks for the swift reply!
> But this won't get integrated now as we are
> preparing the 2.6.1 release. You can start a PR now though.
Yes, already figured as much :)
I'm aiming for 2.8, which should leave me some time to also let a few
people test-drive and review the translation.
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
Hi Mihkel,
Sure if you need this, we need this.
> I'll gladly provide the relevant patches as best as I can, but
> thought I'd ask if the project maybe has some established rules for
> such string-splitting, is there anything I should look out for?
No, let's go with that. But this won't get in
Hi,
I'm working on Estonian translation for darktable, but it would rather
desperately need about 20 strings to be split by context, and another 20 a
bit less desperately :)
I'll gladly provide the relevant patches as best as I can, but thought I'd
ask if the project maybe has some established ru
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
10 matches
Mail list logo
