[Bug dyninst/23513] Dyninst runtime kills the target process when attaching to the target process for a second time

[scox at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=23513

Stan Cox <scox at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2019-04-10
     Ever confirmed|0                           |1

--- Comment #5 from Stan Cox <scox at redhat dot com> ---
The problem seems intermittant but I do see it and the culprit is that the stap
shared object is not always detached when stapdyn completes.  (gdb session
after failing stapdyn)

(gdb) info sharedlibrary
>From                To                  Syms Read   Shared Object Library
0x00007f3bd7f64670  0x00007f3bd80afc3f  Yes (*)     /lib64/libc.so.6
0x00007f3bd8139110  0x00007f3bd81582b4  Yes (*)     /lib64/ld-linux-x86-64.so.2
0x00007f3bd6eb2320  0x00007f3bd6eb4845  Yes (*)    
/usr/lib64/dyninst/libdyninstAPI_RT.so
0x00007f3bd6eab270  0x00007f3bd6eac039  Yes (*)     /lib64/libdl.so.2
                                        No         
/tmp/stapUaA2KQ/stap_4e52f2023ce6edaabf143f6d5214b684_1361.so
0x00007f3bd8124710  0x00007f3bd8127a80  Yes (*)     /lib64/librt.so.1
0x00007f3bd6e60b50  0x00007f3bd6e6f025  Yes (*)     /lib64/libpthread.so.0
(*): Shared library is missing debugging information.

So whenever stapdyn subsequently runs, dyninst tries to load that nonexistant
library: /tmp/stapUaA2KQ/stap_4e52f2023ce6edaabf143f6d5214b684_1361.so

-- 
You are receiving this mail because:
You are the assignee for the bug.