OK, pushed to git with those 2 includes (should have checked that
myself).
On Mon, 02 Sep 2013 21:52:52 +0200 (CEST)
Richard Levitte wrote:
> That worked like a charm! (which shows that gdb on my system is
> allowed to attach to other processes, obviously)
>
> BTW, I had to add the following t
That worked like a charm! (which shows that gdb on my system is
allowed to attach to other processes, obviously)
BTW, I had to add the following two lines in src/common/darktable.c to
have waitpid declared properly:
#include
#include
Cheers,
Richard
In message <20130902210410.20d88...@darkho
Yup, UI'll try it out asap.
In message <[email protected]> on Mon, 2 Sep 2013
21:04:10 +0400, parafin said:
parafin> I have another theory about what's causing the hang, can you please try
parafin> the attached patch? it replaces popen/read/write with fork/exec, so
para
I have another theory about what's causing the hang, can you please try
the attached patch? it replaces popen/read/write with fork/exec, so
that there's no I/O deadlock possible between DT and gdb processes.
On Mon, 2 Sep 2013 15:41:39 +0200
johannes hanika wrote:
> does your system allow gdb to
does your system allow gdb to attach to processes? some disable that by
default, which might lead to weird behaviour.
oh, also i'm quite sure we don't restrict ourselves to async-signal-safe
functions in the sigseg handler (man 7 signal). so i guess every once in a
million this is quite prone to d
Hi!
When darktable crashes, or bugs out, or whatever you want to call it,
it starts gdb with a set of commands. Trouble is, this simply does
nothing. Or rather, it just freezes. Processes look like this:
: ; ps auxw | grep darktable
levitte 13570 28.6 10.7 4171824 877656 pts/7 tl 14:08 10
