- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Program terminated with signal 6 - lwp_kill cxa_gu...
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Forums
Forums
Discussions
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
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- 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
тАО01-08-2010 08:13 AM
тАО01-08-2010 08:13 AM
The errors are the following:
1)aCC runtime: ERROR: Recursive local static object 1ffffffffd50f778 initialization detected
Program terminated with signal 6, Aborted.
#0 0x1ffffffffdbd1f50:0 in _lwp_kill+0x30 () from packcore/modules//libpthread.so.1 (gdb) where #0 0x1ffffffffdbd1f50:0 in _lwp_kill+0x30 () from packcore/modules//libpthread.so.1
#1 0x1ffffffffdb3efa0:0 in pthread_kill () at /ux/core/libs/threadslibs/src/common/pthreads/signal.c:207
#2 0x1ffffffffd2f70e0:0 in raise () at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/raise.c:33
#3 0x1ffffffffd3f85f0:0 in abort () at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/abort_em.c:84
#4 0x1ffffffffdc38cb0:0 in __cxa_guard_acquire () at ../guard.C:46
#5 0x1ffffffffd0bd400:0 in fua::FUA::isMainPackage () at source/FUA.cpp:4155
2)aCC runtime: pure virtual function called for class "ice::FreeUnitAccount".
#0 0x1ffffffffdbd1f50:0 in _lwp_kill+0x30 () from /usr/lib/hpux64/libpthread.so.1
#1 0x1ffffffffdb3efa0:0 in pthread_kill+0x990 () from /usr/lib/hpux64/libpthread.so.1
#2 0x1ffffffffd2f70e0:0 in raise+0xe0 () from /usr/lib/hpux64/libc.so.1
#3 0x1ffffffffd3f85f0:0 in abort+0x170 () from /usr/lib/hpux64/libc.so.1
#4 0x1ffffffffdc35c00:0 in __cxa_pure_virtual+0xe0 () from /usr/lib/hpux64/libCsup.so.1
Most of times the coredump occurs with the message тАЬbad allocation exception thrownтАЭ and the stack is the same of the error 1) above.
This bad allocation problem was solved in another c++ application increasing the maxdsiz_64bit parameter from 4 to 8 GB. We suspected that the application is allocation over than 8 GB, probably due memory leaks.
I also simulated the problem with the command тАЬthrow 10тАЭ, the stack was something like that:
3)Program terminated with signal 6, Aborted.
#0 0x1ffffffffdc11f50:0 in _lwp_kill+0x30 ()
from /usr/lib/hpux64/libpthread.so.1
(gdb) where
#0 0x1ffffffffdc11f50:0 in _lwp_kill+0x30 ()
from /usr/lib/hpux64/libpthread.so.1
#1 0x1ffffffffdb7efa0:0 in pthread_kill+0x990 ()
from /usr/lib/hpux64/libpthread.so.1
#2 0x1ffffffffd2f70e0:0 in raise+0xe0 () from /usr/lib/hpux64/libc.so.1
#3 0x1ffffffffd3f85f0:0 in abort+0x170 () from /usr/lib/hpux64/libc.so.1
#4 0x1ffffffffdc49610:0 in std::terminate()+0x50 ()
from /usr/lib/hpux64/libCsup.so.1
#5 0x1ffffffffdc4bdd0:0 in __cxa_throw+0x3f0 ()
from /usr/lib/hpux64/libCsup.so.1
#6 0x1ffffffffceac440:0 in sra::SRA::CustomerProcessor::execute ()
at source/SRA.cpp:513
IтАЩm not sure if lwp_kill in the function __cxa_pure_virtual and cxa_guard_acquire have benn caused by the bad allocation problem or not.
Can you help find out why the application is receiving the signal 6?
Thanks in advance
Paulo
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-08-2010 09:12 AM
тАО01-08-2010 09:12 AM
Re: Program terminated with signal 6 - lwp_kill cxa_guard_acquire
This means what it says. Your application is illegal. You have function scope static initialization that recursively depends on itself.
You need to have a longer stack trace and see if you find another call to isMainPackage. I.e. please provide the full stack trace.
Also, what version of aC++ do you have? What HP-UX version to you have?
You should install the latest aC++ runtime lib patch to make sure.
>2)aCC runtime: pure virtual function called for class "ice::FreeUnitAccount".
Again, your application is illegal. You have trying to call a pure virtual function during construction. Or you are calling a virtual function after you have deleted the object. Do you have a full stack trace?
>Most of times the coredump occurs with the message "bad allocation exception thrown" and the stack is the same of the error 1) above.
How could it be the same, these are completely different errors? Please provide the full stack trace.
>We suspected that the application is allocation over than 8 GB, probably due memory leaks.
Yes, most likely.
>I also simulated the problem with the command "throw 10"
No need to show me this. :-) The purpose of the error message is so you may not need to see a stack trace.
>I'm not sure if abort in the function __cxa_pure_virtual and cxa_guard_acquire have been caused by the bad allocation problem or not.
We might be able to tell with a full stack trace. It may be you don't handle bad_alloc correctly and the error handling code has never worked??
>Can you help find out why the application is receiving the signal 6?
(You are really getting an aCC runtime errors and the signal is how the aC++ runtime aborts.)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-08-2010 09:35 AM
тАО01-08-2010 09:35 AM
Re: Program terminated with signal 6 - lwp_kill cxa_guard_acquire
> You need to have a longer stack trace and see if you find another call to isMainPackage. I.e. please provide the full stack trace.
#0 0x1ffffffffdbd1f50:0 in _lwp_kill+0x30 ()
from packcore/modules//libpthread.so.1
#1 0x1ffffffffdb3efa0:0 in pthread_kill ()
at /ux/core/libs/threadslibs/src/common/pthreads/signal.c:207
#2 0x1ffffffffd2f70e0:0 in raise ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/raise.c:33
#3 0x1ffffffffd3f85f0:0 in abort ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/abort_em.c:84
#4 0x1ffffffffdc35c00:0 in __cxa_pure_virtual () at ../pure.C:54
#5 0x1ffffffffd0721e0:0 in fua::FUA::printFUContrConsumption ()
at source/FUA.cpp:373
#6 0x1ffffffffd0bcc20:0 in fua::FUA::saveContractConsumption ()
at source/FUA.cpp:5142
#7 0x1ffffffffd063430:0 in fua::FUA::processContract () at source/FUA.cpp:4108
#8 0x1ffffffffcf54110:0 in fua::FUA::process () at source/FUA.cpp:4669
#9 0x1fffffffffea8d40:0 in add::Addon::processCustomer ()
at source/Addon.cpp:210
#10 0x40000000001e5020:0 in iehcore::IehThread::processThread ()
at source/IehThread.cpp:196
#11 0x1ffffffffdb06ec0:0 in __pthread_bound_body ()
at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4874
>Also, what version of aC++ do you have? What HP-UX version to you have?
aCC: HP C/aC++ B3910B A.06.20 [May 13 2008]
HP-UX B.11.31 U ia64
>Again, your application is illegal. You have trying to call a pure virtual function during construction. Or you are calling a virtual function after you have deleted the object. Do you have a full stack trace?
#0 0x1ffffffffdbd1f50:0 in _lwp_kill+0x30 ()
from packcore/modules//libpthread.so.1
(gdb) where
#0 0x1ffffffffdbd1f50:0 in _lwp_kill+0x30 ()
from packcore/modules//libpthread.so.1
#1 0x1ffffffffdb3efa0:0 in pthread_kill ()
at /ux/core/libs/threadslibs/src/common/pthreads/signal.c:207
#2 0x1ffffffffd2f70e0:0 in raise ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/raise.c:33
#3 0x1ffffffffd3f85f0:0 in abort ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/abort_em.c:84
#4 0x1ffffffffdc38cb0:0 in __cxa_guard_acquire () at ../guard.C:46
#5 0x1ffffffffd0bd400:0 in fua::FUA::isMainPackage () at source/FUA.cpp:4155
#6 0x1ffffffffd0bc800:0 in fua::FUA::findFUAccountForExtraBundle ()
at source/FUA.cpp:4139
#7 0x1ffffffffd062970:0 in fua::FUA::processContract () at source/FUA.cpp:4050
#8 0x1ffffffffcf54110:0 in fua::FUA::process () at source/FUA.cpp:4669
#9 0x1fffffffffea8d40:0 in add::Addon::processCustomer ()
at source/Addon.cpp:210
#10 0x40000000001e5020:0 in iehcore::IehThread::processThread ()
at source/IehThread.cpp:196
#11 0x1ffffffffdb06ec0:0 in __pthread_bound_body ()
at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4874
>How could it be the same, these are completely different errors? Please provide the full stack trace.
I├в m not sure, I just know that sometimes occurs bad allocation.
>We might be able to tell with a full stack trace. It may be you don't handle bad_alloc correctly and the error handling code has never worked??
I don├в t have any ├в catch (bad_alloc&) ├в in the source code. So I don├в t handle bad_alloc?
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-08-2010 12:24 PM
тАО01-08-2010 12:24 PM
Re: Program terminated with signal 6 - lwp_kill cxa_guard_acquire
The last three cores occurred in the same point with the same stack.
#0 0x1ffffffffdbd1f50:0 in _lwp_kill+0x30 ()
from packcore/modules//libpthread.so.1
#1 0x1ffffffffdb3efa0:0 in pthread_kill ()
at /ux/core/libs/threadslibs/src/common/pthreads/signal.c:207
#2 0x1ffffffffd2f70e0:0 in raise ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/raise.c:33
#3 0x1ffffffffd3f85f0:0 in abort ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/abort_em.c:84
#4 0x1ffffffffdc35c00:0 in __cxa_pure_virtual () at ../pure.C:54
#5 0x1ffffffffd0721e0:0 in fua::FUA::printFUContrConsumption ()
at source/FUA.cpp:373
#6 0x1ffffffffd0bcc20:0 in fua::FUA::saveContractConsumption ()
at source/FUA.cpp:5142
#7 0x1ffffffffd063430:0 in fua::FUA::processContract () at source/FUA.cpp:4108
#8 0x1ffffffffcf54110:0 in fua::FUA::process () at source/FUA.cpp:4669
#9 0x1fffffffffea8d40:0 in add::Addon::processCustomer ()
at source/Addon.cpp:210
#10 0x40000000001e5020:0 in iehcore::IehThread::processThread ()
at source/IehThread.cpp:196
#11 0x1ffffffffdb06ec0:0 in __pthread_bound_body ()
at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4874
Below you have the source code, maybe it can be usefull:
for (; iter != fuContrConsumptionToSave.end(); ++iter)
{
printFUContrConsumption( *iter );
ICE.saveFUContrConsumption ( *(*iter) );
delete *iter;
}
void FUA::printFUContrConsumption ( ice::FUContrConsumption *fuContrConsumption )
{
//#5 0x1ffffffffd0721e0:0 in fua::FUA::printFUContrConsumption () at source/FUA.cpp:373
iLbgLog_FmtWrite ( log, LBGLOG_LEVEL_INFO, __FILE__, __LINE__, " FU Account Id. = %ld", fuContrConsumption->getFreeUnitAcount().getId() );
}
class FUContrConsumption : virtual public ChangeMonitorable
{
public:
virtual ~FUContrConsumption() throw() { }
/**
* Reference to object Free Unit Account
*/
virtual void setFreeUnitAcount (FreeUnitAccount &acct)= 0;
virtual FreeUnitAccount& getFreeUnitAcount (void)= 0;
Any idea?
Thanks for helping.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-09-2010 12:50 AM
тАО01-09-2010 12:50 AM
Solution#5 0x1ffffffffd0721e0:0 fua::FUA::printFUContrConsumption FUA.cpp:373
I think you are saying line 373 is:
fuContrConsumption->getFreeUnitAcount().getId()
getFreeUnitAcount is pure virtual but I don't think that's it. The name of the bad object is ice::FreeUnitAccount.
Can you split up the statement into:
FreeUnitAccount &r = fuContrConsumption->getFreeUnitAcount();
r.getId()
This can fail if the reference returned by getFreeUnitAcount() has already been destroyed.
After you split it up, print out the address of "r".
What aC++ runtime version are you using? The latest patch is PHSS_40544.
#4 0x1ffffffffdc38cb0:0 __cxa_guard_acquire
#5 0x1ffffffffd0bd400:0 fua::FUA::isMainPackage FUA.cpp:4155
I don't see any obvious recursion. You may have to rebuild with +d if you have lots of inlines, so you can see it.
>I don't have any catch(bad_alloc&) in the source code. So I don't handle bad_alloc?
If you don't handle it, your program should just abort.
>Any idea?
You said you have leaks. You may also have heap corruption or use of the heap after you free things.
You could compile with +check=malloc or use wdb's heap corruption options.
aC++ also has +check=bounds and +check=uninit.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-14-2010 03:50 AM
тАО01-14-2010 03:50 AM
Re: Program terminated with signal 6 - lwp_kill cxa_guard_acquire
#0 0x1ffffffffdbd1f50:0 in _lwp_kill+0x30 ()
from packcore/modules//libpthread.so.1
#1 0x1ffffffffdb3efa0:0 in pthread_kill ()
at /ux/core/libs/threadslibs/src/common/pthreads/signal.c:207
#2 0x1ffffffffd2f70e0:0 in raise ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/raise.c:33
#3 0x1ffffffffd3f85f0:0 in abort ()
at ../../../../../core/libs/libc/shared_em_64_perf/../core/gen/abort_em.c:84
#4 0x1ffffffffdc35c00:0 in __cxa_pure_virtual () at ../pure.C:54
#5 0x1ffffffffd0721e0:0 in fua::FUA::printFUContrConsumption ()
at source/FUA.cpp:373
#6 0x1ffffffffd0bcc20:0 in fua::FUA::saveContractConsumption ()
at source/FUA.cpp:5142
#7 0x1ffffffffd063430:0 in fua::FUA::processContract () at source/FUA.cpp:4108
#8 0x1ffffffffcf54110:0 in fua::FUA::process () at source/FUA.cpp:4669
#9 0x1fffffffffea8d40:0 in add::Addon::processCustomer ()
at source/Addon.cpp:210
#10 0x40000000001e5020:0 in iehcore::IehThread::processThread ()
at source/IehThread.cpp:196
#11 0x1ffffffffdb06ec0:0 in __pthread_bound_body ()
at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4874
It was exactly what you said,
for (iter = globalList.begin() ...){
ice.saveDatabase(iter);
delete *iter
}
But an expcetion was thrown in ice.saveDatabase(iter); and the delete command was not executed.
When it starts to process the next customer, the globallist was still there with one element, but iter->getFreeUnitAccount has been deleted previously.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-14-2010 03:51 AM
тАО01-14-2010 03:51 AM
Re: Program terminated with signal 6 - lwp_kill cxa_guard_acquire
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО01-14-2010 10:18 PM
тАО01-14-2010 10:18 PM
Re: Program terminated with signal 6 - lwp_kill cxa_guard_acquire
If you are happy with the answers you got, please read the following about how to assign points:
http://forums.itrc.hp.com/service/forums/helptips.do?#33
>an exception was thrown in ice.saveDatabase(iter); and the delete command was not executed.
I assume you know how to solve that? Perhaps:
for (iter = globalList.begin() ...){
try {
ice.saveDatabase(iter);
} catch(...) {
delete *iter;
throw;
}
}