這是一個CU**系統調用的查詢天氣預報的Tuxedo服務，Oracle Pro*C程式，連接配接的是Oracle 10.2.0.4庫，出現問題的現象是不定時的産生core，服務down，觸發Tuxedo服務的自動重新開機機制，但一般MAXGEN配置是100，即1天内若重新開機100次後服務就不會自動重新開機了，隻能人工幹預，每次重新開機後會好一陣，且該服務已經由被同步調用改為異步調用，是以實際業務上影響不大，隻是幾乎每天都會有自動重新開機的報警。
檢視産生的core檔案，如下是其堆棧資訊，
根據提示的應用程式行，找到應用生成的中間.c檔案，
這是其中一個core，對應于select sysdate into:sysdate from sys.dual;這條SQL語句，再檢視其他core，還有針對于其他一些SQL語句的情況，很随機，單獨執行這些SQL均正常。
查下MOS，發現有一篇文章和這很像，Core dump - Access Violation in Client Applications After Upgrade to 9.2.0.8, 10.1.0.5 , 10.2.0.x 11.1 and the client or server is still a prior version (文檔 ID 455832.1)。描述資訊是：
Existing applications (and new applications) encounter a core dump after a database or client-side patch up to versions 9.2.0.8, 10.1.0.5 or 10.2 is applied. This is because these versions contain a patch for Bug 3396162(not a published bug), a patch which must be applied to both client and server for it to be effective, and when mismatched to a client or server that does not contain the patch, causes a core dump/ Access Violation.
強調如果資料庫端或用戶端打了patch到9.2.0.8，10.1.0.5或10.2版本，才會碰見這種core。原因是這些版本包含了bug3396162的patch，這個patch需要在用戶端和服務端同時應用，一旦出現兩端隻有一邊打了patch，就會可能産生core。
而且有一段說明，這個問題的錯誤棧并不是每次都會碰見，再次強調隻要用戶端或服務端隻有一邊打了這個patch，則就會碰見這個bug。
This issue is intermittent and the error stack is not seen 100% of the time. However, if there is a client / server mismatch where the patch for bug 3396162 has been applied to either client or server, but not to both environments, this bug will be encountered.
如下堆棧資訊的描述和上面core的堆棧基本一緻，
給出的wrokaround，
The client and server versions must both contain the fix for bug 3396162. This patch is automatically included in 9.2.0.8, 10.1.0.5 and 10.2.0.x or higher releases. The fix is to ensure the patch is applied to both client and server environments.
用戶端和服務端必須包含3396162這個bug的更新檔，這個更新檔自動包含于9.2.0.8，10.1.0.5和10.2.0.x或更高版本中。
其他版本可以下載下傳patch：3396162，
There exists some patches for 9.2.0.7, 10.1.0.3 and 10.1.0.4 for some platforms, downloadable as Patch :3396162.
再次檢查應用程式，發現makefile中使用的Oracle用戶端庫的版本是9.2.0.7，很符合這篇文章的描述，即用戶端應用使用的Oracle版本是9.2.0.7，資料庫服務端的版本是10.2.0.4，接着推進一些佐證。
1.和DBA确認9.2.0.7庫并未應用這個更新檔3396162。
2.測試環境中，讓開發人員使用原始9.2.0.7編譯的應用程式跑一個一天的持續性測試，發現确實會出現core，而且出現問題的SQL是很随機，和生産環境的現象一緻。
3.讓開發人員使用9.2.0.8以上的用戶端庫來重新編譯應用程式，再次做持續性測試，發現不會再産生core了。
解決方案：
使用9.2.0.8以上的Oracle用戶端重新編譯應用程式，替換生産環境的二進制檔案，重新開機應用。
總結：
C程式出現core dump，跟蹤core的資訊，往往可以進一步定位問題的出處。