Oplock logic bugs in Samba 2.2.2

acherry at pobox.com acherry at pobox.com
Fri Oct 26 15:30:02 GMT 2001


Jeremy Allison writes:
 > 
 > Getting more backtraces would be very useful here.
 >

Got one!

(gdb) bt         
#0  0xef5b927c in waitid () from /usr/lib/libc.so.1
#1  0xef5d425c in _waitpid () from /usr/lib/libc.so.1
#2  0xef5e8f50 in system () from /usr/lib/libc.so.1
#3  0x10abcc in smb_panic (why=0x163ad8 "request_oplock_break: no fsp found for our own oplock\n") at lib/util.c:1053
#4  0x123334 in request_oplock_break (share_entry=0x259068, dev=41186627, inode=496120) at smbd/oplock.c:930
#5  0x5eb48 in open_mode_check (conn=0x28b788, fname=0xefffeee0 "apps_nt/netscape/users/eisuser/cache/~~2.tmp", 
    dev=41186627, inode=496120, share_mode=131136, p_flags=0xefffedb4, p_oplock_request=0xefffee24, 
    p_all_current_opens_are_level_II=0xefffedb0) at smbd/open.c:503
#6  0x5f398 in open_file_shared (conn=0x28b788, fname=0xefffeee0 "apps_nt/netscape/users/eisuser/cache/~~2.tmp", 
    psbuf=0xefffee48, share_mode=131136, ofun=1, mode=420, oplock_request=0, Access=0xefffee38, action=0xefffee3c)
    at smbd/open.c:751
#7  0x460f8 in reply_ntcreate_and_X (conn=0x28b788, inbuf=0x236f99 "", outbuf=0x2473e1 "", length=133, bufsize=61440)
    at smbd/nttrans.c:809
#8  0x69ad8 in switch_message (type=162, inbuf=0x236f99 "", outbuf=0x2473e1 "", size=133, bufsize=61440)
    at smbd/process.c:756
#9  0x69b64 in construct_reply (inbuf=0x236f99 "", outbuf=0x2473e1 "", size=133, bufsize=61440) at smbd/process.c:785
#10 0x69e10 in process_smb (inbuf=0x236f99 "", outbuf=0x2473e1 "") at smbd/process.c:879
#11 0x6a7fc in smbd_process () at smbd/process.c:1267
#12 0x2ec20 in main (argc=0, argv=0xeffff58c) at smbd/server.c:811

FYI, I've still got gdb attached to the process, though I've switched
the server back to 2.0.6 (the only 2.2.2 process remaining is the one
I'm debugging).  I don't think this process has any fcntl locks on any
files except the tdb files, so I'm going to keep the debugger attached
to this process for as long as I can.  If you want any more specific
data out of the debugger, I can provide it if it's still running when
you ask.

For some reason I was never able to get core dumps out of the panics,
even if I put a "ulimit -c unlimited" in the Samba startup script.  I
ended up making a gdb run the panic action.

Now if only I can get the NT admins to do something about these users
that end up with their Netscape cache on a network drive... :)

-Andrew
			   




More information about the samba-technical mailing list