Solaris fcntl CPU/Lock update

Jeff Mandel jeff.mandel at probes.com
Thu Feb 27 15:29:52 GMT 2003


>
>
>>trace from 12327:
>>(gdb) bt
>>#0  0xfecd9794 in __sigprocmask () from /usr/lib/libthread.so.1
>>#1  0xfecce1e8 in _deliversigs () from /usr/lib/libthread.so.1
>>#2  0xfecd05c4 in thr_sigsetmask () from /usr/lib/libthread.so.1
>>#3  <signal handler called>
>>#4  0xb in ?? ()
>>#5  0xfecdb1f0 in usleep () from /usr/lib/libthread.so.1
>>#6  0xf7d1c in do_lock_spin (fsp=0x26da48, conn=0x257c68, lock_pid=0,
>>    count=20, offset=2147483559, lock_type=WRITE_LOCK) at 
>>locking/locking.c:175
>>#7  0x58bb4 in reply_lockingX (conn=0x257c68, inbuf=0x2173c9 "",
>>    outbuf=0x237819 "", length=75, bufsize=16644) at smbd/reply.c:4714
>>#8  0x739bc in switch_message (type=36, inbuf=0x2173c9 "", 
>>outbuf=0x237819 "",
>>    size=75, bufsize=16644) at smbd/process.c:774
>>#9  0x73a48 in construct_reply (inbuf=0x2173c9 "", outbuf=0x237819 "",
>>    size=75, bufsize=16644) at smbd/process.c:803
>>#10 0x73cf4 in process_smb (inbuf=0x2173c9 "", outbuf=0x237819 "")
>>    at smbd/process.c:897
>>#11 0x74814 in smbd_process () at smbd/process.c:1294
>>#12 0x314b4 in main (argc=0, argv=0xffbefeac) at smbd/server.c:832
>>(gdb) The program is running.  Quit anyway (and detach it)? (y or n) y
>>    
>>
>
>This is a much more interesting backtrace than the
>other. Why is smbd linking in pthread libraries ?
>smbd is *NOT* a threaded program.
>
>The backtrace you have here shows smbd trying to get
>a fcntl lock on behalf of a client and failing to get it
>instantaneously, so going into the lock spin code. It
>will try 3 times, sleeping for 10 usec between each attempt,
>and then return a fail to the client. This is not in itself
>a spinning bug or problem, smbd is meant to do this.
>
>I'm worried about the interaction between the Solaris lwp
>libc code and smbd.... smbd should be a simple program
>with only one thread of execution.
>
>Jeremy.
>
>  
>
Since it seems that libthread shows up because nss_ldap (padl's) is 
used, does anyone have suggestions for dealing with this at the nss_ldap 
level?

Jeff



More information about the samba-technical mailing list