Re: [DynInst_API:] attaching to multiple processes

[Bill Williams <bill@xxxxxxxxxxx>]

On 07/20/2013 04:06 AM, Marc Brünink wrote:
> Hi,
>
> I have 2 processes, A and B.
> I can attach to Process A, load a library using
> BPatch_addressSpace::loadLibrary and continue the execution. Same thing
> for process B.
>
> However, I cannot do this in sequence. This fails:
>
> 1. attach to A
> 2. load the lib into A
> 3. continue A
> 4. attach to B
> 5. load the lib into B
> 6. continue B
>
> The second load will hang. However, if I do not continue the execution
> of process A, it seems to work.
>
> 1. attach to A
> 2. load the lib into A
> 3. attach to B
> 4. load the lib into B
> 5. continue A and B
>
>
> My 2 questions are:
> 1. Should the first scenario work as well?
Yes, it should; that's a bug. Can you send me a 
DYNINST_DEBUG_PROCCONTROL trace from the first sequence? (And is it a 
deterministic hang?) This should be something simple that we can send 
out a patch for and get into 8.2.
> 2. What are best practices if I attach to multiple processes? Is it safe
> to have one process running while stopping and manipulating another one?
> Or should I expect trouble due to internal issues, e.g. event handling?
In theory, it's safe; in practice, our testing has been focused on 
homogeneous jobs and homogeneous command sequences. I would expect that 
the few things that involve RPCs (library load and OneTimeCodes being 
the two most common) would be the problem children.
--bw

> Marc
>
>
>
> #0  0x00007f491b30ed84 in pthread_cond_wait@@GLIBC_2.3.2 () from
> /lib/x86_64-linux-gnu/libpthread.so.0
> #1  0x00007f490c7ec07d in CondVar::wait (this=<optimized out>) at
> ../../common/src/dthread-unix.C:180
> #2  0x00007f490c80c766 in MailboxMT::dequeue (this=0x7f49040008c0,
> block=true) at ../src/mailbox.C:156
> #3  0x00007f490c831995 in int_process::waitAndHandleEvents (block=true)
> at ../src/process.C:1015
> #4  0x00007f490c832a84 in Dyninst::ProcControlAPI::Process::runIRPCSync
> (this=<optimized out>, irpc=...)
>      at ../src/process.C:6601
> #5  0x00007f490d1ad2d9 in PCProcess::postIRPC_internal (this=0x7853d30,
> buf=0x8740f00, size=157, breakOffset=155,
>      resultReg=0, addr=<optimized out>, userData=0x78a01d0,
> runProcessWhenDone=false, thread=0x0, synchronous=true,
>      userRPC=true, isMemAlloc=false, result=0x0) at
> ../../dyninstAPI/src/dynProcess.C:2177
> #6  0x00007f490d1ad823 in PCProcess::postIRPC (this=0x7853d30,
> action=..., userData=0x78a01d0, runProcessWhenDone=false,
>      thread=0x0, synchronous=true, result=0x0, userRPC=true,
> isMemAlloc=false, addr=0)
>      at ../../dyninstAPI/src/dynProcess.C:2061
> #7  0x00007f490d0fe3c5 in BPatch_process::oneTimeCodeInternal
> (this=0x8740e70, expr=..., thread=<optimized out>,
>      userData=0x0, cb=<optimized out>, synchronous=true, err=0x0,
> userRPC=true) at ../../dyninstAPI/src/BPatch_process.C:956
> #8  0x00007f490d100d1a in BPatch_process::loadLibrary (this=0x8740e70,
>      libname=0x7f490d49efb8 "/my/super/path/callbacks.so")
>      at ../../dyninstAPI/src/BPatch_process.C:1050
> _______________________________________________
> Dyninst-api mailing list
> Dyninst-api@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api

--
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx