On 02/11/2015 08:06 AM, Gerard wrote:
I'm not sure if this patch should have solved my problem with the
maximum number of threads but with this version I still have the same
problem. If I don't increase the MAX_THREADS constant my instrumented
process still hangs after creating around 40 threads.
Tested on 64bits Gentoo Linux with kernel version 3.18.3-gentoo.
Huh. Didn't expect that the vestigial bits of thread index code would
cause a hang; you're sure this is a hang and not a crash mutatee-side?
Anyhow, I've got a more comprehensive patch in the works that eliminates
MAX_THREADS and the thread index code entirely, and I'll be sending that
one out later.
Gerard
2015-02-06 21:54 GMT+01:00 Bill Williams <b...@cs.wisc.edu
<mailto:b...@cs.wisc.edu>>:
As per discussion earlier this week, here's an initial
implementation of TLS-based trampguards. It is not yet pushed to
master; I've tested it locally but it has not been through serious
cross-platform validation yet. Treat as experimental.
This should (mostly) obviate our hard-coded thread limits, and
should produce modestly better performance in multithreaded code.
These changes will not work with an old dyninst runtime library at
present; that's backwards compatibility that I can wedge back in if
anyone particularly cares. As always, feedback (both good and bad)
is encouraged.
--bw
Bill Williams
Paradyn Project
b...@cs.wisc.edu <mailto:b...@cs.wisc.edu>
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu <mailto:Dyninst-api@cs.wisc.edu>
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
--
--bw
Bill Williams
Paradyn Project
b...@cs.wisc.edu
_______________________________________________
Dyninst-api mailing list
Dyninst-api@cs.wisc.edu
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api