smb_receive problem with 2.2.3

[Esh, Andrew]

I now have log level 8 of the error occurring. The file is being unlinked,
and there are oplocks on it. The code tries to queue the request but winds
up failing later. I included the salient portion of the log. Note the last
line. Every time we reproduce this bug, we see the "Unknown error" message
with the 4294967295 (-1) error number. We never see that error number
anywhere else. Here's the log:

[2002/02/15 12:07:27, 3] smbd/oplock.c:initial_break_processing(491)
  initial_break_processing: called for dev = 0, inode = 1605 file_id = 2500
  Current oplocks_open (exclusive = 3, levelII = 0)
[2002/02/15 12:07:27, 6] smbd/process.c:process_smb(859)
  got message type 0x0 of len 0x35
[2002/02/15 12:07:27, 3] smbd/process.c:process_smb(860)
  Transaction 19394 of length 57
[2002/02/15 12:07:27, 5] lib/util.c:show_msg(268)
  size=53
  smb_com=0x6
  smb_rcls=0
  smb_reh=0
  smb_err=0
  smb_flg=24
  smb_flg2=3
[2002/02/15 12:07:27, 5] lib/util.c:show_msg(276)
  smb_tid=1
  smb_pid=51966
  smb_uid=0
  smb_mid=61511
  smt_wct=1
[2002/02/15 12:07:27, 5] lib/util.c:show_msg(285)
  smb_vwv[0]=6 (0x6)
[2002/02/15 12:07:27, 5] lib/util.c:show_msg(291)
  smb_bcc=16
[2002/02/15 12:07:27, 3] smbd/process.c:switch_message(667)
  switch message SMBunlink (pid 8099)
[2002/02/15 12:07:27, 2] smbd/process.c:switch_message(678)
  switch_message: queueing message due to being in oplock break state.
[2002/02/15 12:07:27, 3] smbd/oplock.c:initial_break_processing(491)
  initial_break_processing: called for dev = 0, inode = 1605 file_id = 2500
  Current oplocks_open (exclusive = 3, levelII = 0)
[2002/02/15 12:07:57, 0] smbd/oplock.c:oplock_break(758)
  oplock_break: receive_smb error (Success)
  oplock_break failed for file fakeh/usr/spool/uucp/xtmp/fake08 (dev = 0,
inode = 1605, file_id = 2500).
[2002/02/15 12:07:57, 0] smbd/oplock.c:oplock_break(843)
  oplock_break: client failure in break - shutting down this smbd.
[2002/02/15 12:07:57, 3] smbd/sec_ctx.c:set_sec_ctx(313)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2002/02/15 12:07:57, 5] smbd/uid.c:change_to_root_user(215)
  change_to_root_user: now uid=(0,0) gid=(0,0)
[2002/02/15 12:07:57, 2] smbd/server.c:exit_server(487)
  Closing connections
[2002/02/15 12:07:57, 3] smbd/sec_ctx.c:set_sec_ctx(313)
  setting sec ctx (0, 0) - sec_ctx_stack_ndx = 0
[2002/02/15 12:07:57, 5] smbd/uid.c:change_to_root_user(215)
  change_to_root_user: now uid=(0,0) gid=(0,0)
[2002/02/15 12:07:57, 1] smbd/service.c:close_cnum(674)
  r4c1w101 (10.55.41.101) closed connection to service test
[2002/02/15 12:07:57, 3] smbd/connection.c:yield_connection(48)
  Yielding connection to test
[2002/02/15 12:07:57, 2] smbd/close.c:close_normal_file(210)
  nobody closed file  (numopen=2) Unknown error 4294967295

-----Original Message-----
From: Tim Potter [mailto:tpot at samba.org]
Sent: Friday, February 15, 2002 12:34 PM
To: Esh, Andrew
Cc: Samba-Technical (E-mail)
Subject: Re: smb_receive problem with 2.2.3


On Fri, Feb 15, 2002 at 10:53:09AM -0600, Esh, Andrew wrote:

> While doing a number of tests, one of my associates found the cause
> of the failure of one our Samba file access torture tests. I am wondering
> why the code to return READ_ERROR was added to smb_receive.

This code was added to stop smbclient returning "error code 0" when the
remote server was failing to respond to keepalive packets.

It sounds like this is having unintended consequences so it should
probably be backed out.


Tim.
-------------- next part --------------
HTML attachment scrubbed and removed