Thanks! That was exactly the problem. I have increased the constant MAX_THREADS and now I don't have this problem anymore. Is there any reason why the constant is set to 32 instead of a higher value?
I also have tried to find how to dynamically change the DYNINST_max_num_threads value but I haven't found where is it implemented (version 8.2.1). And about disabling tramp guards, I already had them disabled so it seems that this workaround does not solve the problem. Gerard 2015-02-03 20:13 GMT+01:00 Barton Miller <[email protected]>: > Disabling tramp guards certainly works if you really know that you're not > recursing. That can be subtle and error prone, which is why tramp guards > were invented. Proceed cautiously here. > > --bart > > > On 2/3/2015 12:02 PM, Matthew LeGendre wrote: > >> Another possible fix may be to disable tramp guards. Tramp guards are >> used to prevent recursive instrumentation. For example, if you instrument >> malloc() with instrumentation that calls malloc(), then tramp guards will >> prevent you from going into infinite recursion. >> >> If you already know that your instrumentation can't infinitely recurse, >> then disabling tramp guards will give a big performance win and may work >> around this hang. To disable tramp guards, put a call to >> BPatch::setTrampRecursive(true) before you insert instrumentation. >> >> -Matt >> _______________________________________________ >> Dyninst-api mailing list >> [email protected] >> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >> > > _______________________________________________ > Dyninst-api mailing list > [email protected] > https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api >
_______________________________________________ Dyninst-api mailing list [email protected] https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
