- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, applicatio...
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
тАО02-03-2010 07:45 AM
тАО02-03-2010 07:45 AM
Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps
Good point.
Now my question is if it is correct when a function expects arguments like (int, const char*, ...) to give it just int and const char*?
I have taken a look in functions that are called in the backtrace and found the following code. The first function calls the second function and pass two arguments. The second function is defined as
void sys_logger::log_message(u_int32 type, const char* psz_format, ...)
{
va_list args;
va_start(args, psz_format );
p_impl -> log_message( type, psz_format, args );
va_end(args);
}
So it expects two named arguments and then variable number of unnamed arguments.
However in the code it never get any unnamed arguments, only first two ones.
I changed code of the first function that calls sys_logger::log_message() in this way:
Instead of :
SYS_LOGGER ->
log_message( type_msg, psz_msg );
I wrote:
SYS_LOGGER ->
log_message( type_msg, "%s", psz_msg );
Now there have been no coredumps.
So my question is if it is correct when a function expects arguments like (int, const char*, ...) to give it just int and const char*?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-03-2010 09:28 AM
тАО02-03-2010 09:28 AM
Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps
I took a look at sys_logger::sys_logger_impl::log_message():
void sys_logger_impl::log_message(u_int32 type, const char *psz_format, va_list args )
{
char buffer [4096];
vsnprintf( buffer, sizeof( buffer ), psz_format, args );
buffer[sizeof(buffer)-1] = 0;
syslog( type, "%s", buffer );
if (type != slmt_information) {
std::cout << buffer << std::endl;
}
}
As I said earlier if ... is an empty list then args is made of the empty list and this functions ends up with SIGBUS in the call to syslog().
If ... is not an empty list then args is not made of the empty list and this functions ends up correctly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2010 03:20 AM
тАО02-04-2010 03:20 AM
Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps
Sure, you could pass that to printf all the time:
printf("hi guy\n");
>I changed code of the first function that calls sys_logger::log_message() in this way:
No need to do that. Of course log_message needs to not access the missing third parm.
>if ... is an empty list then args is made of the empty list and this functions ends up with SIGBUS in the call to syslog().
Then your foreign devil compiler is likely broken.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2010 04:37 AM
тАО02-04-2010 04:37 AM
Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps
One more question. I suspect that I have done again something wrong in my SIGTERM handler but I can find a bug.
So, unfortunately the error has not been fixed. It was possible to reproduce it yesterday but this morning I got it again.
I simplified code that handles SIGTERM in order to avoid as much as posssible my own functions. So now I have this code:
void CDECL_CALLING_CONVENTION app_env_log::sigterm_handler( int num, siginfo_t *r, void * )
{
syslog(6,"%s","HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH");
b_terminated = true;
if (application_) {
application_->signal_stop();
application_ = 0;
}
}
And it coredumped in syslog. What is wrong?
#0 0xc00000000029ffb0:0 in kill+0x30 () from /lib/hpux64/libc.so.1
#1 0xc0000000001c3510:0 in raise ()
at ../../../../../core/libs/libc/shared_em_64/../core/gen/raise.c:19
#2 0xc000000000260f30:0 in abort ()
at ../../../../../core/libs/libc/shared_em_64/../core/gen/abort_em.c:84
#3 0x40000000003312b0:0 in os_sp::app_env_log::sigbus_handler (num=10,
r=0x9fffffff7f20e210)
at ../../../src/common/rating_shared/app_env_log.cpp:281
#4
#5 0xc0000000002a20b0:0 in time+0x30 () from /lib/hpux64/libc.so.1
#6 0xc00000000021f3a0:0 in syslog ()
at ../../../../../core/libs/libc/shared_em_64/../core/gen/syslog.c:245
#7 0x4000000000331600:0 in os_sp::app_env_log::sigterm_handler (num=960688,
r=0xe0000001308828e0)
at ../../../src/common/rating_shared/app_env_log.cpp:293
#8
#9 0xc000000003daee70:0 in uwx_decode_uinfo () at uwx_uinfo.c:168
#10 0xc000000003dadc00:0 in uwx_get_frame_info () at uwx_step.c:211
#11 0xc000000003db7020:0 in uwx_restore_markers () at uwx_step.c:347
#12 0xc000000003dccac0:0 in _Unwind_RaiseException ()
at ExceptionHandling.C:449
#13 0xc00000000f9d0430 in __cxa_throw (obj=
tinfo=0x600000000002bc50, dest=0x9fffffffbf63ad50)
at /tmp/gcc-4.3.1.tar.gz/gcc-4.3.1/libstdc++-v3/libsupc++/eh_throw.cc:71
#14 0x40000000002f4070:0 in ip::raise (code=4, mess=
at ../../../src/common/rating_lib/ip.cpp:73
#15 0x40000000002f4590:0 in ip::raise ()
at ../../../src/common/rating_lib/ip.cpp:77
This is code with line numbers:
291 void CDECL_CALLING_CONVENTION app_env_log::sigterm_handler( int num, siginfo_t *r, void * )
292 {
293 syslog(6,"%s","HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH");
294 b_terminated = true;
295 if (application_) {
296 application_->signal_stop();
297 application_ = 0;
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-04-2010 04:38 AM
тАО02-04-2010 04:38 AM
Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps
One more question. I suspect that I have done again something wrong in my SIGTERM handler but I can't find a bug.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2010 02:07 AM
тАО02-05-2010 02:07 AM
Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps
One thing I forgot to ask, is what frame are you interested in? On several, you have 2 separate signals. And if you do get the first signal, you can't really expect to recover from it and the number of libc functions you can call is severely limited.
You may want to swap the order:
if (application_) {
temp = application_;
application_ = 0;
temp->signal_stop();
}
Or if lots of threads beating up on signals, use an atomic swap on application_.
>And it coredumped in syslog. What is wrong?
No, it got a signal in time(2) in frame 5. What signal did it get, SIGBUS it seems.
How big is your thread stack? You could have a thread stack overflow where the local variable in time(2) is in the guard page.
You can get the framesize by:
(gdb) frame 5
(gdb) p /x $save_sp
(gdb) frame XXX (where XXX is the one for __pthread_bound_body)
(gdb) p $sp - $save_sp
- Tags:
- guard page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2010 03:34 AM
тАО02-05-2010 03:34 AM
Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps
(gdb) frame 5
(gdb) p /x $save_sp = $sp
(gdb) frame XXX (where XXX is the one for __pthread_bound_body)
(gdb) p $sp - $save_sp
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2010 05:45 AM
тАО02-05-2010 05:45 AM
Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps
(gdb) frame 5
(gdb) p /x $save_sp = $sp
$1 = 0x9fffffff7f213370
(gdb) f 19
#19 0xc000000000328f40:0 in __pthread_bound_body ()
at /ux/core/libs/threadslibs/src/common/pthreads/pthread.c:4594
4594 /ux/core/libs/threadslibs/src/common/pthreads/pthread.c: No such file or directory.
in /ux/core/libs/threadslibs/src/common/pthreads/pthread.c
Current language: auto; currently c
(gdb) p $sp - $save_sp
$2 = 31872
I had set PTHREAD_DEFAULT_STACK_SIZE before I ran the program:
export PTHREAD_DEFAULT_STACK_SIZE=1000000
Am I right that there is no stack overflow?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2010 06:12 AM
тАО02-05-2010 06:12 AM
Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
тАО02-05-2010 05:10 PM
тАО02-05-2010 05:10 PM
SolutionIt doesn't seem like it. (Unless you are randomly using mprotect(2) on your stack. ;-)
So unless some evil person is doing "kill -BUS" all over, I'm not sure why the kernel is aborting in the time(2) syscall. If you use sigaction(2) and set SA_SIGINFO, you can get details on why the signal occurred.
syslog(3) is inappropriately using time(&var) instead of: var = time(NULL)
That's where I thought the overflow occurred.
You could try:
(gdb) frame 4
(gdb) p $reason
And again for frame 8.
>I have almost decided to use it
sigaltstack(2) and sigwaitinfo(2) are used for different purposes. The first if you may have a stack overflow.
>Using sigwaitinfo(2) looks like a good idea. What is your advice on this?
sigwaitinfo(2) seems ideal for signals like SIGTERM. But for SIGBUS and SIGSEGV, you want a signal handler.