这是一个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的信息，往往可以进一步定位问题的出处。