2014-10-20 89 views
0

我们的系统有一个开源库。棘手的是我们有两个库,一个是我们自己的修改,另一个是原始的。这两个副本都在源代码树中,但是应该在运行时调用自定义的副本,而将原始的副本用于构建时用于其他目的。如何跟踪哪个库被动态加载

现在我怀疑,在我们的系统升级过程中,定制的一个隐藏了原来的隐藏。由于系统的复杂性,修改源代码以进行一些跟踪是可行的,但是很尴尬。我认为如果我只是objdump顶级图书馆得到线索。

以下是详细信息:

1) The customization one and the original one have the same source file names 
2) Their library names are same 
3) The customization is some implementation change at deep within; so it is 
    invisible from outside 
4) The 2 libraries are at different sub directory trees 

因为它是动态链接的,我居然怀疑objdump的可以告诉我任何区别。但任何建议表示赞赏!

回答

-1

修改你的类路径(如果这是一个Java应用程序),并添加这个自定义的jar之前,原来的。

这应该解决问题。

有时在构建时使用的类路径在运行时期间会被保存和使用,但是您仍然可以在java的命令行参数中修改此类以用于类路径条目,或者如果它从tomcat运行内部仍然可以相同。

0

我认为ldd应该简单地告诉你,作为一种预测而不是痕迹。例如,对于ls命令:

# ldd $(which ls) 
    linux-vdso.so.1 (0x00000333f2a54000) 
    libselinux.so.1 => /lib64/libselinux.so.1 (0x00000333f2610000) 
    libcap.so.2 => /lib64/libcap.so.2 (0x00000333f2408000) 
    libacl.so.1 => /lib64/libacl.so.1 (0x00000333f21f8000) 
    libc.so.6 => /lib64/libc.so.6 (0x00000333f1e48000) 
    libdl.so.2 => /lib64/libdl.so.2 (0x00000333f1c40000) 
    libpcre.so.1 => /usr/lib64/libpcre.so.1 (0x00000333f19d8000) 
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00000333f17b8000) 
    /lib64/ld-linux-x86-64.so.2 (0x00000333f2838000) 
    libattr.so.1 => /lib64/libattr.so.1 (0x00000333f15b0000) 

对于跟踪你可以滥用的东西像AppArmor的抱怨模式这一点。

或者使用gdb,GNU调试器。运行“ls”命令的示例:

# gdb ls 
GNU gdb (GDB; openSUSE 13.1) 7.6.50.20130731-cvs 
Copyright (C) 2013 Free Software Foundation, Inc. 
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> 
This is free software: you are free to change and redistribute it. 
There is NO WARRANTY, to the extent permitted by law. Type "show copying" 
and "show warranty" for details. 
This GDB was configured as "x86_64-suse-linux". 
Type "show configuration" for configuration details. 
For bug reporting instructions, please see: 
<http://bugs.opensuse.org/>. 
Find the GDB manual and other documentation resources online at: 
<http://www.gnu.org/software/gdb/documentation/>. 
For help, type "help". 
Type "apropos word" to search for commands related to "word". 
.. 
Reading symbols from /usr/bin/ls...Missing separate debuginfo for /usr/bin/ls 
Try: zypper install -C "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4" 
(no debugging symbols found)...done. 
(gdb) start 
Function "main" not defined. 
Make breakpoint pending on future shared library load? (y or [n]) y 
Temporary breakpoint 1 (main) pending. 
Starting program: /usr/bin/ls 
warning: Cannot call inferior functions, Linux kernel PaX protection forbids return to non-executable pages! 
Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2 
Try: zypper install -C "debuginfo(build-id)=afa98667969782208459e394f8c8f87ac7510710" 
bak core learning.log  learning.mode lr old   test.log testpolicy  testpolicy.large 
c learn learning.log.uniq ll    lrw paxtest.log test2.log testpolicy.gradm testpolicy.large.gradm 
[Inferior 1 (process 25609) exited normally] 
(gdb) info sharedlibrary 
From    To     Syms Read Shared Object Library 
0x00000342a0556ae0 0x00000342a056ee10 Yes (*)  /lib64/ld-linux-x86-64.so.2 
(*): Shared library is missing debugging information. 
(gdb) 
+0

gdb解决方案与我正在寻找的最接近。问题:在我进入函数之后,我怎么知道我在哪个库? “show sharedlib”对我不起作用,因为许多库被归档(或者其他一些原因,无论如何,我看不到库) – 2014-10-20 18:27:17

+0

我对gdb的了解不多。顺便说一句,你也可以使用lsof,例如。 lsof -Pn | grep yourappname | grep“\ .so” – Peter 2014-10-24 08:31:22