Description of problem: I was told that I should submit this problem to my OS vendor. Process runs under LD_ASSUME_KERNEL=2.4.19 Below is code sample which crashes and gdb traceback. Software is Bacula (www.bacula.org). Version-Release number of selected component (if applicable): glibc-headers-2.3.2-95.27 How reproducible: Sometimes Steps to Reproduce: char *bstrftime_nc(char *dt, int maxlen, utime_t tim) { time_t ttime = (time_t)tim; struct tm tm; /* ***FIXME**** the format and localtime_r() should be user configurable */ localtime_r(&ttime, &tm); /* NOTE! since the compiler complains about %y, I use %y and cut the century */ strftime(dt, maxlen, "%d-%b-%Y %H:%M", &tm); strcpy(dt+7, dt+9); return dt; } Actual results: Using host libthread_db library "/lib64/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 5497)] [New Thread 32769 (LWP 5498)] [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 5497)] [New Thread 32769 (LWP 5498)] [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 5497)] [New Thread 32769 (LWP 5498)] [New Thread 16386 (LWP 5499)] [New Thread 32771 (LWP 5512)] 0x0000002a95e56df6 in select () from /lib64/libc.so.6 $1 = "bitess-fd", '\0' <repeats 20 times> $2 = 0x539c78 "bacula-fd" $3 = 0x539cb8 "/usr/sbin/bacula-fd" $4 = "PostgreSQL" $5 = 0x42c198 "1.36.1 (24 November 2004)" $6 = 0x427f67 "x86_64-redhat-linux-gnu" $7 = 0x427f60 "redhat" $8 = 0x427f4d "Enterprise release" #0 0x0000002a95e56df6 in select () from /lib64/libc.so.6 #1 0x0000000000414425 in bnet_thread_server (addrs=0x0, max_clients=-1075437056, client_wq=0x538200, handle_client_request=0) at bnet_server.c:155 #2 0x000000000040402f in main (argc=0, argv=0x0) at filed.c:258 Thread 4 (Thread 32771 (LWP 5512)): #0 0x0000002a95791233 in waitpid () from /lib64/libpthread.so.0 #1 0x0000000000420f14 in signal_handler (sig=11) at signal.c:159 #2 0x0000002a9579004e in __pthread_sighandler () from /lib64/libpthread.so.0 #3 <signal handler called> #4 0x0000002a95e24c05 in strftime () from /lib64/libc.so.6 #5 0x00000000004152a5 in bstrftime_nc (dt=0x2a96cd5ca0 "00-Dec-04 01:16", maxlen=50, tim=704) at btime.c:91 #6 0x000000000040afb6 in list_terminated_jobs ( sendit=0x40b180 <bsock_sendit>, arg=0x53fe18) at status.c:193 #7 0x000000000040ab8f in do_status (sendit=0x40b180 <bsock_sendit>, arg=0x53fe18) at status.c:101 #8 0x000000000040b211 in status_cmd (jcr=0x3) at status.c:268 #9 0x00000000004068cf in handle_client_request (dirp=0x3) at job.c:210 #10 0x0000000000424015 in workq_server (arg=0x3) at workq.c:347 #11 0x0000002a9578bb26 in pthread_start_thread () from /lib64/libpthread.so.0 #12 0x0000002a95e5d143 in thread_start () from /lib64/libc.so.6 /etc/bacula/btraceback.gdb:10: Error in sourced command file: Cannot access memory at address 0x2a96cd6000 #0 0x0000002a95e56df6 in select () from /lib64/libc.so.6 Expected results: Additional info:
We need a self-contained testcase that reproduces this. #include <time.h> #include <sys/time.h> #include <string.h> char *bstrftime_nc(char *dt, int maxlen, unsigned long tim) { time_t ttime = (time_t)tim; struct tm tm; localtime_r(&ttime, &tm); strftime(dt, maxlen, "%d-%b-%Y %H:%M", &tm); strcpy(dt+7, dt+9); return dt; } int main (void) { char dt[50]; bstrftime_nc(dt, 50, 704); return 0; } certainly works on RHEL3 U4/x86_64.
Even disas 0x0000002a95e24c05 0x0000002a95e24c05+32 (or whatever address the segfault happens at) plus rpm -qf /lib64/libc-2.3.2.so output would be helpful, given that in glibc-2.3.2-95.27.x86_64.rpm's /lib64/libc.so.6 that address points into the middle of another instruction.
$ rpm -qf /lib64/libc-2.3.2.so glibc-2.3.2-95.30 And which rpm disas belongs to?
disas is a gdb command (shorthand for disassemble). *c05 is not the start of an instruction in glibc-2.3.2-95.30's strftime either. Is the #4 0x0000002a95e24c05 in strftime () from /lib64/libc.so.6 segfault address really what you get with the U4 glibc? If you can reproduce the segfault, please run the program under gdb and when it reports a segfault disas $pc $pc+32, post the output here.
The problem is that I cannot reproduce problem any more. You can view the initial conversation here: http://bugs.bacula.org/bug_view_advanced_page.php?bug_id=0000200 My RHES installation I believe was U3 then. Also that daemon which crashed was run with LD_ASSUME_KERNEL=2.4.19 in environment.
In that case I'm afraid there is nothing to do about this. If you manage to reproduce it in the future, please try to grab more details and reopen the bug with it.