BladeSystem Forums have moved here
To make BladeSystem information easier to find, we have moved the BladeSystem forums here, to Servers and Operating Systems.
Languages and Scripting
Showing results for 
Search instead for 
Do you mean 

mktime hang

Go to Solution
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,



Acclaimed Contributor

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

[ Edited ]

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)?