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
