Operating System - HP-UX
1748011 Members
3483 Online
108757 Solutions
New Discussion

Re: mktime and getenv(3) hang in signal handler

 
SOLVED
Go to solution
BERTRAND_7
Frequent Advisor

mktime hang

Our system is running on HPUX11.31

We have some processes that are running forever and very very rarely one is hanging without apparent reason. 

As these process is running on live system it's quite difficult to investiguate : maintenance people just kill then restart the process that is working fine for a long while until the next occurence.

Yet, recently we had the problem on our integration platform : one developper got the call stack when the process hangs (but it's only a JPG file)

The call stack is :

#0 0xc000000000432750:0 in __ksleep
#1 0xc0000000001c51c0:0 in __mnx_sleep
#2 0xc00000000013fce0:0 in __pthread_mutex_lock??
#3 0xc00000000013dc90:0 in __pthread_mutex_lock??
#4 0xc00000000013da20:0 in pthread_mutex_lock??
#5 0xc000000000453e50:0 in __pthread_mutex_lock??
#6 0xc0000000003252a0:0 in getenv+0xfa0 ()
#7 0xc000000000320a90:0 in tzset+0x110 ()
#8 0xc00000000031d550:0 in localtime_r+0x120 ()
#9 0xc00000000031d210:0 in localtime+0x30 ()
#10 0x400000000004a630:0 in fg_cur_date_asc ()
#11 0x4000000000014f30:0 in fl_alarm_rcv_timer_signal ()
#12 <signal handler called>
#13 0xc00000000013db20:0 in __pthread_mutex_lock_ng+0xe0 ()
#14 0xc00000000013da20:0 in pthread_mutex_lock+0x20 ()
#15 0xc000000000453e50:0 in __pthread_mutex_lock+0xb0 ()
#16 0xc0000000003252a0:0 in getenv+0xfa0 ()
#17 0xc000000000320a90:0 in tzset+0x110 ()
#18 0xc000000000328810:0 in mktime+0x150 ()
#19 0x400000000004d2d0:0 in fg_dasc_to_dsec ()
#20 0x4000000000017c70:0 in fl_alarm_fault ()

 

Has anyone already observed this hang ?

Please advice,

 

Bruno

1 REPLY 1
Dennis Handly
Acclaimed Contributor
Solution

Re: mktime and getenv(3) hang in signal handler

Your application is likely to be illegal and you gambled and lost.  ;-)

You can't call mktime(3) or localtime(3) in a signal handler.  I.e. it isn't async signal safe.  See thread_safety(5)

You might be able to call gmtime(3)?