NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

kern/41593: descriptor handling critically broken



>Number:         41593
>Category:       kern
>Synopsis:       descriptor handling broken
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Jun 14 10:00:00 +0000 2009
>Originator:     Frank Kardel
>Release:        NetBSD 5.99.13
>Organization:
        
>Environment:
        
        
System: NetBSD pip.kardel.name 5.99.13 NetBSD 5.99.13 (PIP) #17: Sun Jun 14 
07:47:24 MEST 2009 
kardel%pip.kardel.name@localhost:/fs/raid1a/src/NetBSD/tc-merge/src/obj.i386/sys/arch/i386/compile/PIP
 i386
Architecture: i386
Machine: i386
>Description:
        The sequence close(0)->-1,EBADF, dup(22)->26 violates common Unix 
wisdom.
        With the commit of new descriptor code this behavior start to appeas 
(~2009-05-24). This
        breaks at least cups.

        partial syscall trace:
          3643      1 cupsd    1244962370.954798243 RET   fork 0
          3643      1 cupsd    1244962370.954798828 EMUL  "netbsd"
          3643      1 cupsd    1244962370.954865065 CALL  _lwp_ctl(1,0xbfa00184)
          3643      1 cupsd    1244962370.954879919 RET   _lwp_ctl 0
          3643      1 cupsd    1244962370.954906975 CALL  close(0)
          3643      1 cupsd    1244962370.954908182 RET   close -1 errno 9 Bad 
file descriptor
          3643      1 cupsd    1244962370.955109701 CALL  dup(0x16)
          3643      1 cupsd    1244962370.955117915 RET   dup 26/0x1a
>>>       ****                                            pardon me ?
          3643      1 cupsd    1244962370.955119263 CALL  close(1)
          3643      1 cupsd    1244962370.955120506 RET   close 0
          3643      1 cupsd    1244962370.955121256 CALL  dup(0x19)
          3643      1 cupsd    1244962370.955124397 RET   dup 1
          3643      1 cupsd    1244962370.955125120 CALL  close(2)
          3643      1 cupsd    1244962370.955126126 RET   close 0
          3643      1 cupsd    1244962370.955126768 CALL  dup(0x15)
          3643      1 cupsd    1244962370.955129377 RET   dup 2
          3643      1 cupsd    1244962370.955130
        .
        . then perl gets execed ... following opens return fds in the range 5..9
        . just like fd 0 is still a valid fd
        .
          3643      1 perl     1244962371.040871078 RET   read 0
          3643      1 perl     1244962371.040871681 CALL  close(6)
          3643      1 perl     1244962371.040872912 RET   close 0
          3643      1 perl     1244962371.040912081 CALL  
write(5,0xbb525000,0x74)
          3643      1 perl     1244962371.040940682 GIO   fd 5 wrote 116 bytes
          3643      1 perl     1244962371.040941544 RET   write 116/0x74
          3643      1 perl     1244962371.040999585 CALL  
write(5,0xbb525000,0x1d)
          3643      1 perl     1244962371.041023467 GIO   fd 5 wrote 29 bytes
          3643      1 perl     1244962371.041024205 RET   write 29/0x1d
          3643      1 perl     1244962371.041036298 CALL  
read(0,0xbb538000,0x1000)
          3643      1 perl     1244962371.041036724 RET   read -1 errno 9 Bad 
file descriptor
>>>       ****                                            we knew this one from 
>>> the close, but dup/open still think 
>>>       ****                                            fd 0 cannot be 
>>> allocated

>How-To-Repeat:
        pick a -current after 2009-05-25 and what it violating basic semantics
>Fix:
        use kernel before 2009-05-24

>Unformatted:
        
        


Home | Main Index | Thread Index | Old Index