Oplock logic bugs in Samba 2.2.2

[Jeremy Allison]

On Fri, Oct 26, 2001 at 05:29:58PM -0400, acherry at pobox.com wrote:
> 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... :)

Do you have a debug level 10 log from this smbd ? That would be *really*
usefull.....

Can you send me whatever log file you have from this smbd ?

Can you give me details on the server system you're running (Solaris ?
Linux ? What version of the OS ?).

Thanks,

	Jeremy.