Ever since we migrated to Solaris 10, we have had various concurrent program binaries creating core dumps. Some of them get resolved after we relink the binaries. But some continue core dumps even after relinking them. ARGLTP or the AR to GL Transfer Program is one of the binaries which does this. I have had an SR logged with Oracle for some time. The strangest thing is that the concurrent requests calling ARGLTP complete normal. But for every run of ARGLTP a coredump with signal 11 is created. Here's a stack trace:
adb /erp11i/erp/appl/ar/11.5.0/bin/ARGLTP
1208446806-ARGLTP-15767-62984-54011-tsgsd1009-sun4u
core file = 1208446806-ARGLTP-15767-62984-54011-tsgsd1009-sun4u -- program
``/erp11i/erp/appl/ar/11.5.0/bin/ARGLTP
'' on platform SUNW,Netra-T12
SIGSEGV: Segmentation Fault
$c
libc.so.1`strcmp+0x170(1739c8, 73657364, 0, 0, 1d0634, 1d0614)
afppre+0x1cc(2a81e0, 261b88, 50, 50, ff1ea2b4, ff1f29f8)
fdpcls+0x3e4(4e, 1c2b28, 1c2b18, 1c2800, 1c2800, 1)
main+0x76e0(14f730, 14f774, ffbf9fbc, a, 2a4760, 7f80)
_start+0xdc(0, 0, 0, 0, 0, 0)
$q
A common thing in all the coring binaries is the OS library libc.so.1. Oracle has asked us to check with Sun if this is a known issue and if a new version of libc.so.1 is available. I have an SR logged with Sun also for this.
We finally got a solution. Patch 6815663 is a post ATG RUP6 one off patch which fixes this issue. Since it is not fully regression tested, it is protected by a password. You have to log an SR to get the password. After applying this patch, we have seen that none of the binaries like ARGLTP, PARGDR, PAVDVC, PASGLT etc. are coring anymore.
Subscribe to:
Post Comments (Atom)
Posts
No comments:
Post a Comment