Operating System - HP-UX
1748167 Members
4002 Online
108758 Solutions
New Discussion юеВ

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

 
SOLVED
Go to solution
blackwater
Regular Advisor

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

> 1) You are in the middle of a throw and you get a SIGTERM. This is your issue.

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*?
blackwater
Regular Advisor

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

According to the backtrace the application from sys_logger::sys_logger_impl::log_message() calls syslog() and that finally results in SIGBUS.

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.
Dennis Handly
Acclaimed Contributor

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

>is correct when a function expects arguments like (int, const char*, ...) to give it just int and const char*?

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.
blackwater
Regular Advisor

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

Dennis, thank you for your answer.

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;
blackwater
Regular Advisor

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

Sorry, I misprinted one sentence.

One more question. I suspect that I have done again something wrong in my SIGTERM handler but I can't find a bug.
Dennis Handly
Acclaimed Contributor

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

>One more question.

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
Dennis Handly
Acclaimed Contributor

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

Oops, that should be: You can get the framesize by:
(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
blackwater
Regular Advisor

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

> 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.

(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?
blackwater
Regular Advisor

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

I don't use sigaltstack. I have almost decided to use it but then I was told about sigwaitinfo(). Using sigwaitinfo() looks like a good idea. What is your advice on this, Dennis? At least I will not be restricted in what libc functons I can use.

Dennis Handly
Acclaimed Contributor
Solution

Re: HP-UX 11.23, gcc4.3.1, __cxa_throw, application coredumps

>Am I right that there is no stack overflow?

It 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.