Re: [DynInst_API:] Ignore certain signals

[Bill Williams <bill@xxxxxxxxxxx>]

This is in fact a ptrace limitation. If your application is being run under ptrace it will stop on all signals. If it’s possible to perform your instrumentation with binary rewriting (possibly augmented by other techniques) and just let it run with your signal handler installed it will be somewhat more performing but not a lot; signal overhead is a pretty significant fraction of ptrace overhead IIRC.

--bw

---

From: Dyninst-api <dyninst-api-bounces@xxxxxxxxxxx> on behalf of Xiaozhu Meng <mxz297@xxxxxxxxx>
Sent: Tuesday, May 1, 2018 4:44:29 PM
To: Victor van der Veen
Cc: dyninst-api
Subject: Re: [DynInst_API:] Ignore certain signals

 

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 <vvdveen@xxxxxxxxx> 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 <mxz297@xxxxxxxxx> 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 <vvdveen@xxxxxxxxx> 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
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api