HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: core in libcma.2
Operating System - HP-UX
1834009
Members
3142
Online
110063
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-31-2005 01:47 AM
05-31-2005 01:47 AM
core in libcma.2
Hello,
While stress testing our application (which has been stable over the years) on HP-UX 11.0 with newer DCE patches, it consistently generates a core. The backtrace using gdb shows:
#0 0xc092e6d0 in cma__dispatch+0x450 () from /usr/lib/libcma.2
#1 0xc092e1dc in cma__block+0x164 () from /usr/lib/libcma.2
#2 0xc0944078 in ptdexc_cond_wait+0x1c0 () from /usr/lib/libcma.2
#3 0xc05feee4 in cthread_call_executor+0xd4 () from /usr/lib/libdce.2
#4 0xc094be18 in cma__thread_base+0x1f0 () from /usr/lib/libcma.2
#5 0xc09507a0 in cma__thread_start1+0x38 () from /usr/lib/libcma.2
#6 0xc09501ac in cma__thread_start0+0xc () from /usr/lib/libcma.2
We observed this behavior after we installed the newer DCE patches:
PHSS_29749 1.0 HP DCE/9000 1.7 Runtime cumulative patch
PHSS_29750 1.0 HP DCE/9000 1.7 Server/DevTools cum. patch
PHSS_29751 1.0 HP DCE/9000 1.7 Domestic cumulative patch.
Before the application cores, any RPC calls to the application returns with error-code
382312502 connection closed (dce/rpc).
Any thoughts, suggestions on this.
Thanks,
Dilip
While stress testing our application (which has been stable over the years) on HP-UX 11.0 with newer DCE patches, it consistently generates a core. The backtrace using gdb shows:
#0 0xc092e6d0 in cma__dispatch+0x450 () from /usr/lib/libcma.2
#1 0xc092e1dc in cma__block+0x164 () from /usr/lib/libcma.2
#2 0xc0944078 in ptdexc_cond_wait+0x1c0 () from /usr/lib/libcma.2
#3 0xc05feee4 in cthread_call_executor+0xd4 () from /usr/lib/libdce.2
#4 0xc094be18 in cma__thread_base+0x1f0 () from /usr/lib/libcma.2
#5 0xc09507a0 in cma__thread_start1+0x38 () from /usr/lib/libcma.2
#6 0xc09501ac in cma__thread_start0+0xc () from /usr/lib/libcma.2
We observed this behavior after we installed the newer DCE patches:
PHSS_29749 1.0 HP DCE/9000 1.7 Runtime cumulative patch
PHSS_29750 1.0 HP DCE/9000 1.7 Server/DevTools cum. patch
PHSS_29751 1.0 HP DCE/9000 1.7 Domestic cumulative patch.
Before the application cores, any RPC calls to the application returns with error-code
382312502 connection closed (dce/rpc).
Any thoughts, suggestions on this.
Thanks,
Dilip
3 REPLIES 3
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-31-2005 01:49 AM
05-31-2005 01:49 AM
Re: core in libcma.2
Suggestions:
1) Report the problem to HP Response Center
2) Back out the patches.
3) Put the patches on a test server and see if you can stablize your application, because its always good to have current patches.
SEP
1) Report the problem to HP Response Center
2) Back out the patches.
3) Put the patches on a test server and see if you can stablize your application, because its always good to have current patches.
SEP
Steven E Protter
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-31-2005 03:54 AM
05-31-2005 03:54 AM
Re: core in libcma.2
Dilip --
Was libc linked on the command line when the application was built ?
If so this can occassionally cause problems .
Also, what does "chatr" show for this executeable.
If it doesn't show libc.2 as the last library, then you may want to rebuild it.
Was libc linked on the command line when the application was built ?
If so this can occassionally cause problems .
Also, what does "chatr" show for this executeable.
If it doesn't show libc.2 as the last library, then you may want to rebuild it.
"Well, actually, she is a rocket scientist" -- Steve Martin in "Roxanne"
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
05-31-2005 05:38 PM
05-31-2005 05:38 PM
Re: core in libcma.2
Hello Kent:
This is the output from chatr.
# chatr sc_ocm
sc_ocm:
shared executable
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path disabled first Not Defined
shared library list:
dynamic /usr/lib/libndbm.2
dynamic /usr/lib/libdce.2
dynamic /usr/lib/libm.2
dynamic /usr/lib/libc.1
dynamic /usr/lib/libcl.2
dynamic /usr/lib/libc.2
shared library binding:
immediate nonfatal verbose
global hash table disabled
plabel caching disabled
global hash array size:1103
global hash array nbuckets:3
shared vtable support disabled
static branch prediction disabled
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
third quadrant global data space disabled
data page size: D (default)
instruction page size: D (default)
nulptr references enabled
shared library private mapping disabled
shared library text merging disabled
This is the output from chatr.
# chatr sc_ocm
sc_ocm:
shared executable
shared library dynamic path search:
SHLIB_PATH disabled second
embedded path disabled first Not Defined
shared library list:
dynamic /usr/lib/libndbm.2
dynamic /usr/lib/libdce.2
dynamic /usr/lib/libm.2
dynamic /usr/lib/libc.1
dynamic /usr/lib/libcl.2
dynamic /usr/lib/libc.2
shared library binding:
immediate nonfatal verbose
global hash table disabled
plabel caching disabled
global hash array size:1103
global hash array nbuckets:3
shared vtable support disabled
static branch prediction disabled
executable from stack: D (default)
kernel assisted branch prediction enabled
lazy swap allocation disabled
text segment locking disabled
data segment locking disabled
third quadrant private data space disabled
fourth quadrant private data space disabled
third quadrant global data space disabled
data page size: D (default)
instruction page size: D (default)
nulptr references enabled
shared library private mapping disabled
shared library text merging disabled
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP