On 06/18/2013 11:33 AM, Matthew LeGendre wrote:
Zifei,
I think you've found the right bug. Dyninst gets all of its library
information from the link maps, and the only way I could imagine this
bug happening is via the vsyscall page being added there. It doesn't
make a lot of sense for glibc to do this (lots of tools will break), but
oh well.
It's hard to be sure without a machine to test on, but I believe the
attached patch against Dyninst 8.1.2 would fix the problem.
Bill,
Does the batlab have any machines with a new enough glibc that would
reproduce this?
This may not be a "new enough" question but a "narrow window" question;
the batlab has Fedora 16/17/18 at present. By default, F17 has glibc
2.15-59 and F18 has glibc 2.16-31, and I've not observed this problem on
either of those platforms. F16 is glibc2.14.90-24, which also does not
exhibit this problem.
--bw
-Matt
On Mon, 17 Jun 2013, Zifei Tong wrote:
Hi,
Thanks for your explanation.
The copying/renaming trick and the workaround patch I attached in the
last mail is to demonstrate the issue.
I just realized this could be a issue of glibc [2]. Dyninst might need
work around this problem as in [1][3].
[1] http://sourceware.org/bugzilla/show_bug.cgi?id=14466
[2] http://sourceware.org/bugzilla/show_bug.cgi?id=13097
[3]
http://pkgs.fedoraproject.org/cgit/gdb.git/tree/gdb-glibc-vdso-workaround.patch
Thanks,
Zifei Tong
On Tue, Jun 18, 2013 at 1:54 AM, Saul St. John <sstjohn@xxxxxxxxxxx>
wrote:
linux-vdso.so.1 (nee linux-gate.so.1) is a virtual shared library
that lives
in the kernel, providing fast syscall alternatives. It is mapped by the
kernel into the address space of any userland program.
I don't know what the correct solution is, but copying a different
shared
object into /usr/lib and renaming it linux-vdso.so.1 does not sound
OK; it
sounds likely to confuse ld.so.
see also:
*
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ABI/stable/vdso?id=v3.8
* http://www.trilithium.com/johan/2005/08/linux-gate/
-s
On 06/16/2013 12:05 PM, Zifei Tong wrote:
Hi,
I cannot get dyninst working on my Archlinux machine.
The problem is dyninst tries to load linux-vdso.so.1, which will fail.
I copyed a .so file for /usr/lib and rename it to linux-vdso.so.1,
then everything is OK.
Here is related debug log:
[140737353914176]mapped_object.C[157]: about to parseImage
[140737353914176]mapped_object.C[159]: name linux-vdso.so.1, codeBase
0x7ffff88fa000, dataBase 0x7ffff88fa000
[140737353914176]image.C[1100]: about to create image
[140737353914176]image.C[1374]: opening file linux-vdso.so.1
[140737353914176]image.C[1102]: created image
[140737353914176]image.C[1105]: processing shared object
[140737353914176]image.C[1123]: error in processing, deleting image
and returning
[140737353914176]mapped_object.C[162]: failed to parseImage
[140737353914176]pcEventHandler.C[857]: failed to create mapped object
for library linux-vdso.so.1
[140737353914176]pcEventHandler.C[194]: continue condition ( 0 0 1 1
1 1 )
[140737353914176]pcEventHandler.C[230]: delaying process continue:
<return failure> <desired stop> <stopped> <no reported event> <not
terminated> <no pending events>
[140737353914176]pcEventHandler.C[242]: finished handling event:
Library (err = true)
[140737353914176]dynProcess.C[418]: bootstrap failed to wait for events
Failed to bootstrap process 26943: terminating...
[140737353914176]dynProcess.C[1147]: Terminating process 26943
[140737353914176]pcEventMuxer.C[219]: Begin callbackMux, process
pointer = 0x6b4e90, event post-ForceTerminate
[140737353914176]pcEventMuxer.C[439]: Added event post-ForceTerminate
to mailbox, size now 1
[140737353914176]pcEventMuxer.C[221]: after muxing event, mailbox
size is
1
[140737353914176]pcEventMuxer.C[464]: Returning event
post-ForceTerminate from mailbox
[140737353914176]pcEventHandler.C[65]: attempting to handle event
post-ForceTerminate on thread 26943/26943
[140737353914176]pcEventHandler.C[194]: continue condition ( 1 0 1 1
0 1 )
[140737353914176]pcEventHandler.C[230]: delaying process continue:
<return success> <desired stop> <stopped> <no reported event>
<terminated> <no pending events>
[140737353914176]pcEventHandler.C[236]: pending exit reported to
BPatch-level, marking process exited
[140737353914176]pcEventHandler.C[242]: finished handling event:
post-ForceTerminate (err = false)
[140737353914176]dynProcess.C[1155]: finished terminating process 26943
--FATAL-- #68: Dyninst was unable to create the specified process
--FATAL-- #68: create process failed bootstrap
Here is a workaround patch:
diff --git a/dyninstAPI/src/pcEventHandler.C
b/dyninstAPI/src/pcEventHandler.C
index 46a4ff9..64c516d 100644
--- a/dyninstAPI/src/pcEventHandler.C
+++ b/dyninstAPI/src/pcEventHandler.C
@@ -839,6 +839,8 @@ bool
PCEventHandler::handleLibrary(EventLibrary::const_ptr ev, PCProcess
*evProc
const set<Library::ptr> &added = ev->libsAdded();
for(set<Library::ptr>::const_iterator i = added.begin(); i !=
added.end(); ++i) {
+ if ((*i)->getAbsoluteName() == "linux-vdso.so.1")
+ continue;
Address dataAddress = (*i)->getLoadAddress();
if( evProc->usesDataLoadAddress() ) dataAddress =
(*i)->getDataLoadAddress();
I tried to trace what's going on but got no clue. Would you please
help?
I am using Linux 3.9.6 x86_64, with dyninst compiled against master
HEAD.
Thanks,
--
仝子飞 (Zifei Tong)
College of Computer Science and Technology, Zhejiang University
_______________________________________________
Dyninst-api mailing list
Dyninst-api@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/dyninst-api
t
_______________________________________________
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
--
--bw
Bill Williams
Paradyn Project
bill@xxxxxxxxxxx
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}