Am 27.06.2012 19:38, schrieb Josef Weidendorfer:
Am 27.06.2012 17:25, schrieb Christoph Bartoschek:
Hi,
the manual does not explain all interactions between data collection and
instrumentation.
I start with --instr-atstart=no
When I then enable instrumentation with
Hi,
is it necessary to use a tool like valgrind to debug deadlocks? For all
deadlocks I have seen it was enough to see the tracebacks of all threads
to diagnose the problem.
Could you please describe why this does not work in your case?
Thanks
Christoph
Am 25.06.2012 10:09, schrieb Marian
Am 29.06.2012 15:46, schrieb Alexander Potapenko:
This may be not that easy to guess which locks are taken when the
deadlock has already occurred.
However a Valgrind-like tool is really an overkill for deadlock
detection: a small library that interposes pthread_mutex_* (or other
locking
On Fri, Jun 29, 2012 at 5:50 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
Am 29.06.2012 15:46, schrieb Alexander Potapenko:
This may be not that easy to guess which locks are taken when the
deadlock has already occurred.
However a Valgrind-like tool is really an overkill for
Am 29.06.2012 15:59, schrieb Alexander Potapenko:
Unfortunately in general there may be any number of locks and any set
of threads may wait for any of those locks.
Yes. I missed that. However I do not remember any situation where it
was not clear for me which locks caused a deadlock I had to
On Fri, 2012-06-29 at 17:46 +0400, Alexander Potapenko wrote:
This may be not that easy to guess which locks are taken when the
deadlock has already occurred.
However a Valgrind-like tool is really an overkill for deadlock
detection: a small library that interposes pthread_mutex_* (or other
