目前分類:Debug/Performance (46)

瀏覽方式: 標題列表 簡短摘要

最近專案的 python 程式莫名的爆出了一堆卡住的問題,

研究了一下,是程式內部出現了 deadlock 死結,簡單記錄一下除錯經過吧~

 

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天在用 gdb 研究 lib7zip 的程式流程,

不過在迴圈裡面設定中斷點的話有點麻煩,每次迴圈都會中斷,

而我只想在某個條件滿足時才中斷就好了...

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

昨天剛學到用 cProfile+gprof2dot 將 profiling 結果視覺化

不過 cProfile 有個問題:它預設只能處理單一執行緒 (thread),

因此如果程式會產生新的 thread 的話,

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

在對 Python 程式做效能最佳化時,我們可以用 Profile+gprof2dot 將 profiling 結果視覺化

不過後來發現也還有別的方法可以視覺化,還可以少掉一個 dot 轉 png 的步驟,

那就是利用 pyprof2calltreeqcachegrind (kcachegrind)~

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

專案裡有隻 python 程式,因為它常常被呼叫到,

可是它執行所花費的時間似乎有點久,比我們預期的要長...

因此今天的任務就是找出程式執行時間的瓶頸 (profiling),來加以改善~

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

在用 gdb debug C/C++ 程式時,常常會看到一些 mangle 過的函式名稱,

理論上 gdb 應該會自動還原名稱,但還是常常會看到沒有 demangle 的函式...

 

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天同事回報,專案的機器斷續出現了數次 BSOD (藍色死亡螢幕),

手上只有一個 Mini Dump,就先用 Windbg 來瞧瞧:

kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

BAD_SYSTEM_CONFIG_INFO (74)
Can indicate that the SYSTEM hive loaded by the osloader/NTLDR
was corrupt.  This is unlikely, since the osloader will check
a hive to make sure it isn't corrupt after loading it.
It can also indicate that some critical registry keys and values
are not present.  (i.e. somebody used regedt32 to delete something
that they shouldn't have)  Booting from LastKnownGood may fix
the problem, but if someone is persistent enough in mucking with
the registry they will need to reinstall or use the Emergency
Repair Disk.
Arguments:
Arg1: 00000002, (reserved)
Arg2: 80de0aa8, (reserved)
Arg3: 00000002, (reserved)
Arg4: c000014c, usually the NT status code.

Debugging Details:
------------------


DUMP_CLASS: 1

DUMP_QUALIFIER: 400

BUILD_VERSION_STRING:  7601.17514.x86fre.win7sp1_rtm.101119-1850

SYSTEM_MANUFACTURER:  innotek GmbH

VIRTUAL_MACHINE:  VirtualBox

SYSTEM_PRODUCT_NAME:  VirtualBox

SYSTEM_VERSION:  1.2

BIOS_VENDOR:  innotek GmbH

BIOS_VERSION:  VirtualBox

BIOS_DATE:  12/01/2006

BASEBOARD_MANUFACTURER:  Oracle Corporation

BASEBOARD_PRODUCT:  VirtualBox

BASEBOARD_VERSION:  1.2

DUMP_TYPE:  2

BUGCHECK_P1: 2

BUGCHECK_P2: ffffffff80de0aa8

BUGCHECK_P3: 2

BUGCHECK_P4: ffffffffc000014c

CPU_COUNT: 1

CPU_MHZ: 898

CPU_VENDOR:  GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3e

CPU_STEPPING: 4

CPU_MICROCODE: 6,3e,4,0 (F,M,S,R)  SIG: 19'00000000 (cache) 19'00000000 (init)

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

BUGCHECK_STR:  0x74

PROCESS_NAME:  System

CURRENT_IRQL:  0

ANALYSIS_SESSION_TIME:  07-19-2016 00:12:29.0497

ANALYSIS_VERSION: 10.0.10586.567 amd64fre

LAST_CONTROL_TRANSFER:  from 829dd75d to 82927428

STACK_TEXT:  
80de0a3c 829dd75d 00000074 00000002 80de0aa8 nt!KeBugCheckEx+0x1e
80de0c50 82a3e400 00000002 97f3a7bd 00000000 nt!CmpLoadHiveThread+0x1d5
80de0c90 828de969 829dd588 00000002 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19


STACK_COMMAND:  kb

THREAD_SHA1_HASH_MOD_FUNC:  0923d9a023698d301c5cb0a37750d4865823449c

THREAD_SHA1_HASH_MOD_FUNC_OFFSET:  75cf9f942485e99c274e32a479046970d353e367

THREAD_SHA1_HASH_MOD:  d084f7dfa548ce4e51810e4fd5914176ebc66791

FOLLOWUP_IP: 
nt!CmpLoadHiveThread+1d5
829dd75d cc              int     3

FAULT_INSTR_CODE:  5846f7cc

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!CmpLoadHiveThread+1d5

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce78a06

IMAGE_VERSION:  6.1.7601.17514

FAILURE_BUCKET_ID:  0x74_nt!CmpLoadHiveThread+1d5

BUCKET_ID:  0x74_nt!CmpLoadHiveThread+1d5

PRIMARY_PROBLEM_CLASS:  0x74_nt!CmpLoadHiveThread+1d5

TARGET_TIME:  2016-07-18T17:44:52.000Z

OSBUILD:  7601

OSSERVICEPACK:  1000

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK:  272

PRODUCT_TYPE:  1

OSPLATFORM_TYPE:  x86

OSNAME:  Windows 7

OSEDITION:  Windows 7 WinNt (Service Pack 1) TerminalServer SingleUserTS

OS_LOCALE:  

USER_LCID:  0

OSBUILD_TIMESTAMP:  2010-11-20 16:42:46

BUILDDATESTAMP_STR:  101119-1850

BUILDLAB_STR:  win7sp1_rtm

BUILDOSVER_STR:  6.1.7601.17514.x86fre.win7sp1_rtm.101119-1850

ANALYSIS_SESSION_ELAPSED_TIME: 32c

ANALYSIS_SOURCE:  KM

FAILURE_ID_HASH_STRING:  km:0x74_nt!cmploadhivethread+1d5

FAILURE_ID_HASH:  {fd769186-fc25-f32f-6b5e-482763a1f51d}

Followup:     MachineOwner
---------
文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

最近拿到一個用 JScript 寫的病毒檔案,想來研究一下看看它是怎麼寫的,

但看了一下,發現裡面用了許多將程式模糊化 (obfuscation) 的技巧,

要單單憑肉眼就看出這個 JScript 在做什麼是很困難的,

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

最近想要在 CentOS 上製造系統忙碌的狀況,看看能不能重現某個奇怪的 bug,

查了一下不少人建議可以用 stress 這個套件,

但是這個套件在 CentOS 7 裡面怎麼找都找不到,base / epel 都找遍了,

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天在查一個 Linux 上的 shared library 沒有釋放掉的問題,

從程式來看,應該呼叫 dlopen() 和 dlclose() 的次數是相當的,

不過因為中間牽扯到其他的 .so 檔,有點不太能肯定會不會有什麼例外,

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

在用 gdb 的時候,有時候想要下一個中斷點,但中斷點的函式是在還沒載入的 DLL 裡面,

這時 gdb 就會問你是否確認要標記這個「未來的」中斷點:

root@localhost / # gdb -ex "b Load7ZLibrary" --args /usr/bin/python load7z.pyc 

Function "Load7ZLibrary" not defined.
Make breakpoint pending on future shared library load? (y or [n])

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

最近專案的 python 程式常常出現當掉的狀況,

用 gdb debug 了一下,看來是 python 用到我們的 C++ 函式庫的問題~

來記錄一下 debug 的過程吧~

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天在用 gdb debug 一個程式問題時,需要看某個陣列的內容~

當然平常如果陣列就是用類似 int array[] 的方式宣告的話,用 gdb 是可以直接看到值的~

舉例來說,下面這個簡單的測試程式:

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天想要用 gdb debug 一個程式,看看某個變數的值,

平常可能可以用 gdb 的中斷點,但有時候想要在某些情況下,才讓 gdb 停在特定地方~

gdb 應該有支援條件式的中斷點,不過另一種方法是直接在程式碼裡喚醒 gdb,

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天用 gdb debug 一個 crash dump,backtrace 裡什麼都看不到:

(gdb) bt
#0  0x00007f4d3fbb23e2 in ?? ()
#1  0x000000000298f970 in ?? ()
#2  0x000000000298f97c in ?? ()
#3  0x000000000298f978 in ?? ()
#4  0x0000000000000000 in ?? ()

 

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

最近在整合 lib7zip 和 p7zip,有時 API 的呼叫不如預期,

還是得去 trace 一下 lib7zip 和 p7zip 的程式碼...

lib7zip 比較簡單,預設狀況似乎都有 debug symbol,但 p7zip 就沒有了,

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天想要查一個 process 所使用的環境變數的值,

如果程式正在執行的話,可以直接印出 /proc/<pid>/environ 的內容,例如:

cat /proc/12345/environ
文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

最近專案的程式有用到 lib7zip 來呼叫 7zip,

不過有個奇怪的問題,就是用 WinRAR 作出來的 .rar 檔案,

如果「檔案名稱」有加密的話 (如下),我呼叫 lib7zip 的程式是解不出來的,但是 7z 本身可以:

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

最近在用 gdb 看一些 crash dump,蠻多時候 gdb 都沒能列出函式參數的內容,

在 x86 環境下,大部分的函式參數是用 stack 的方式在傳遞,

但在 x64 環境下就不一樣了,有好幾個參數都會使用暫存器 (register) 來傳遞,

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

今天在用 gdb 查一個 crash 的問題,看到 backtrace 像下面這樣:

(gdb) bt
#1  0x00002b9872b3ec88 in GetFileType (
    szSrcFilePath=0x163243c "/Normal.dotm", 
    pFileType=0x1b2dc70) at ./FileTypeLib.cpp:488
#2  0x00002b986e671ca8 in ffi_call_unix64 () from /opt/python/lib/python2.6/lib-dynload/_ctypes.so
#3  0x00002b986e671af4 in ffi_call () from /opt/python/lib/python2.6/lib-dynload/_ctypes.so
#4  0x00002b986e66c2f4 in _CallProc () from /opt/python/lib/python2.6/lib-dynload/_ctypes.so
#5  0x00002b986e664118 in ?? () from /opt/python/lib/python2.6/lib-dynload/_ctypes.so
#6  0x0000000000417d2d in PyObject_Call ()
#7  0x000000000048fc7a in PyEval_EvalFrameEx ()
......
#30 0x00000036d120683d in start_thread () from /lib64/libpthread.so.0
#31 0x00000036d06d4fcd in clone () from /lib64/libc.so.6

 

文章標籤

ephrain 發表在 痞客邦 PIXNET 留言(0) 人氣()

1 23
找更多相關文章與討論