I see. Then I think you indeed need to search for ptrace documentation to see if there is a way to let ptrace to not act on a certain signal. I did a quick search, but could not find useful information.
On Tue, May 1, 2018 at 9:24 AM, Victor van der Veen <[email protected]> wrote: > Hi Xiaozhu, > > Thanks. Yes, I can do that for nodejs. However, the prevalent use is case > SIGV: I insert instrumentation that will trigger segmentation faults. These > are then handled by a custom signal handler (also added by my > instrumentation). There may be many of these signals at run-time, and I > don't want to pay for the extra ptrace/Dyninst overhead. This might be a > ptrace limitation, and simply not possible though. > > Best, > Vitor > > On 1 May 2018 at 16:15, Xiaozhu Meng <[email protected]> wrote: > >> Hi Victor, >> >> Can you profile what signals are causing the slowdown? Dyninst uses a few >> different signals such as SIGSTOP, SIGTRAP, SIGUSR1, and SIGUSR2, for >> different purposes. Depending on which signal or signals are causing the >> problem, we may be able to figure out a way to let Dyninst not act on those >> signals. >> >> Thanks, >> >> --Xiaozhu >> >> On Tue, May 1, 2018 at 8:07 AM, Victor van der Veen <[email protected]> >> wrote: >> >>> Hello, >>> >>> Can I modify Dyninst's process control (for Linux) so that whenever a >>> mutator remains attached to its mutatee, certain signals are delivered to >>> the mutatee only? >>> >>> I am instrumenting a binary (node.js) that triggers many signals during >>> one of its benchmarks and I have the impression that this is causing a >>> modest slowdown, as well as some weird memory leak. It would be great if I >>> could tell Dyninst to not act on those signals. >>> >>> Apologies for not reading the ptrace manual first :-) >>> >>> Best regards, >>> Victor van der Veen >>> >>> _______________________________________________ >>> 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
