Bug 100815

Summary: FBSD 5.5 broke nanosleep in libc_r
Product: Base System Reporter: Michael Scheidell <scheidell>
Component: threadsAssignee: freebsd-threads (Nobody) <threads>
Status: Closed FIXED    
Severity: Affects Only Me CC: hackers
Priority: Normal    
Version: 5.5-RELEASE   
Hardware: Any   
OS: Any   

Description Michael Scheidell 2006-07-25 21:00:32 UTC
	nanosleep returns after time+delta if wallclock changed with libc_r

Fix: 

compile with:
cc -g  -c nanotest.c
cc -g  -o nanotest nanotest.o

or compile on 5.4 system.
(I have only tried compiling and running on 5.4 system.
I have not yet tried compiling on 5.4 and running on 5.5 or visa versa)

I used ntpdate -su to change clock.
(I have an internal system that is 45 seconds behind, just for this test)

output with 5.4 or without libc_r
shows wallclock 'stepping' when you change time
no delay in display.

5.5 with libc_r shows stepping if moving clock head, but if you move
wallclock back 45 seconds, display stops for 45 seconds.
How-To-Repeat:         5.4 works, not including libc_r in 5.5 works
        Given this POC:
        int main( int argc, char **argv )
{
char execs1[256] = "/bin/date +A%Y%m%d%H%M.%S";
char execs2[256] = "/bin/date +B%Y%m%d%H%M.%S";
int a;
  
  while ( 1) {
  
    system( execs1 );
     usleep( 500*1000);
    system( execs2 );
  }

  return 0;
}  /* main */

compile with: 
cc -g  -c nanotest.c
cc -g  -o nanotest nanotest.o -lc_r

run it, set clock back 45 seconds, observe 45 second delay
Comment 1 Daniel Eischen freebsd_committer freebsd_triage 2006-07-25 21:56:46 UTC
State Changed
From-To: open->suspended

In RELENG_5,6 and HEAD libc_r is deprecated in favour of  
libpthread and libthr.  Nobody is working on libc_r bugs  
so mark this PR as suspended.
Comment 2 Michael Scheidell 2006-07-27 21:55:13 UTC
Linked same program with lib_thr and it exits, signal 10.
(make clean, make)

Linked same program with lib_pthread and it actually reboots the computer.

I will attempt to either identify the problem to a repeatable POC, or 
might just remote threads.
The first one I will work on is the lib_pthread. Nothing (well,  almost 
nothing) run in userland should reboot the computer.

-- 
Michael Scheidell, CTO
SECNAP Network Security / www.secnap.com
scheidell@secnap.net  / 1+561-999-5000, x 1131
Comment 3 Alexander Best freebsd_committer freebsd_triage 2010-11-18 20:50:25 UTC
State Changed
From-To: suspended->feedback

We need to check, if this behavior also occurs in recent FreeBSD versions and 
with libthread.
Comment 4 Alexander Best freebsd_committer freebsd_triage 2011-02-23 14:54:24 UTC
State Changed
From-To: feedback->closed

I was not able to reproduce any issues described in this PR with a recent 
version of HEAD. As you can see 

A201102231549.22 
B201102231549.23 
A201102231549.23 
B201102231549.23 
A201102231549.23 
B201102231548.00 
A201102231548.00 
B201102231548.00 
A201102231548.00 
B201102231548.01 
A201102231548.01 
B201102231548.01 
A201102231548.01 
B201102231548.02 
A201102231548.02 
B201102231548.02 
A201102231548.02 

the date got set back ~1.5 minutes, however no delays or even reboots occured.