2014-10-20 32 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