top button
Flag Notify
    Connect to us
      Facebook Login
      Site Registration Why to Join

Facebook Login
Site Registration
Print Preview

Program getting stuck __tz_convert()

+1 vote

I have an application that has run fine on RHEL 5.X and does most of the time on RHEL 6.X. But now and then it gets stuck and there are no errors and the process cannot be terminated with kill -15 PID, it takes kill -9 PID. While doing some research on another problem I ran across the gstack command that I had never used before. So the next time the program hung I ran gstack on its pid and below is the results.

It appears the program had made a call to a local function to get the current date and time and format it to be displayed on the user's terminal, when the user must have just disconnected. The disconnect would have caused the process to receive the SIGHUP signal which it is trapping and would have gotten the date and time and formatted it to put a time stamped message in a log file and then would have exited. But because __tz_convert() was in the process of doing something and was reentered again because of the signal trapping and processing that called __tz_convert again, it blocks on _L_lock_2163() and __lll_lock_wait_private().

I know the general concept of signal handler is to do very little, just set a variable or something. But this signal handler would not return, it would log some information and then exit after removing a lock file. Therefore I never thought it would run into a problem like this. I can provide exact kernel version and version of anything else if needed.

My question is, is this a known problem? Is there a fix for it if it is a known problem? Or a work around?

#0 0x0000003ead2f806e in __lll_lock_wait_private () from /lib64/
#1 0x0000003ead29de5d in _L_lock_2163 () from /lib64/
#2 0x0000003ead29dc17 in __tz_convert () from /lib64/
#3 0x000000000040abd8 in fmt_timestring ()
#4 0x000000000040b6b0 in fmt_timestamp ()
#5 0x000000000040b99d in fmt_mid ()
#6 0x0000000000401fa3 in getout ()
#7 0x0000000000402078 in gotsig ()
#9 0x0000003ead256578 in _IO_vfscanf_internal () from /lib64/
#10 0x0000003ead269945 in vsscanf () from /lib64/
#11 0x0000003ead2639a8 in sscanf () from /lib64/
#12 0x0000003ead29d172 in __tzset_parse_tz () from /lib64/
#13 0x0000003ead29e34e in __tzfile_compute () from /lib64/
#14 0x0000003ead29dcd7 in __tz_convert () from /lib64/
#15 0x000000000040f2a8 in time_update ()
#16 0x0000000000405da1 in timeupdate ()
#17 0x000000000040773e in disp_input_edit ()
posted May 16, 2013 by anonymous

Looking for an answer?  Promote on:
Facebook Share Button Twitter Share Button Google+ Share Button LinkedIn Share Button Multiple Social Share Button

Similar Questions
+2 votes

These days, my mongodb process stuck very easy, just like this mongostat cmd.
Anyone knows what happen with mongodb?

+1 vote

Stuck at:

--> Processing Conflict: mutter-3.16.2-1.fc22.x86_64 conflicts gnome-shell < 3.16.1

For more then 2 hours :( How do I resolve this?

0 votes

We've been having some issues with one of our MySQL servers lately, and currently the dang thing is "stuck". For at least the last hour, NOW() is returning the same value:

mysql> select now();
| now() |
| 2013-06-26 02:27:14 |

The system variable "timestamp" also has that same time value stored in it. How can we kick this loose so that the values are more current with real time? (it is currently 3:08PM here, despite our MySQL instance thinking it's 2am. The system time on the machine is correct:

$ date
Wed Jun 26 15:08:56 PDT 2013

This is MySQL 5.1.46 running on solaris2.10.

Any ideas short of restarting the MySQL engine? I'm willing to do that, but would much rather wait and not do it in the middle of the day.

0 votes

UE is not getting latched in 4G after UE switched on. It takes 4-5 minutes to latch in 4G, first time after switch on it latches in legacy Network. Any clue

Useful Links with Similar Problem
Contact Us
+91 9880187415
#470/147, 3rd Floor, 5th Main,
HSR Layout Sector 7,
Bangalore - 560102,
Karnataka INDIA.