Internal error being generated in LSA_LOOKUPSIDS

[Luke Kenneth Casson Leighton]

On Tue, 17 Feb 1998, Andre Gerhard wrote:

> Hello,
> 
> 
> I am getting the following error in my NT Wksta machine log file
> (the NT workstation is denying access to any domain user after this
> error occurs):
> 
> It appears to be coming from the LSA_LOOKUPSIDS RPC call
> 
> debug level 3:
> 
> api_rpc_command:
> LSA_LOOKUPSIDS
> =============================================================
> ==
> INTERNAL ERROR: Signal 11 in pid 768 (ntdom-1.9.18alpha14)
> Please read
> the file BUGS.txt in the
> distribution
> ===============================================================
> 
> chdir to /
> Closing connections
> 02/16/1998 11:08:11 1micro1
> (143.107.70.218) closed connection to service IPC$
> Yielding connection to
> 12 IPC$
> 02/16/1998 11:08:11 1micro1 (143.107.70.218) closed connection to
> service aluno3
> Yielding connection to 58 aluno3
> Yielding connection to 58
> STATUS.
> Yield successful
> 02/16/1998 11:08:11 1micro1 (143.107.70.218)
> closed connection to service winsrv
> Yielding connection to 72
> winsrv
> Yielding connection to 72 STATUS.
> Yield successful
> fd_attempt_close
> on file_fd_struct 0, fd = 6, dev = 808, inode = 245cb, open_flags = 0,
> ref_count = 1.
> 02/16/1998 11:08:11 aluno3 closed file
> MSOffice/Access/SOA300.DLL (numopen=0)
> Last message was
> SMBtrans
> size=188
> smb_com=0x25
> smb_rcls=0
> smb_reh=0
> smb_err=0
> smb_flg=24
> smb
> _flg2=3
> smb_tid=12
> smb_pid=51966
> smb_uid=101
> smb_mid=11712
> smt_wct=16
> smb_vw
> v[0]=0 (0x0)
> smb_vwv[1]=112 (0x70)
> smb_vwv[2]=0 (0x0)
> smb_vwv[3]=1024
> (0x400)
> smb_vwv[4]=0 (0x0)
> smb_vwv[5]=0 (0x0)
> smb_vwv[6]=0
> (0x0)
> smb_vwv[7]=0 (0x0)
> smb_vwv[8]=0 (0x0)
> smb_vwv[9]=0
> (0x0)
> smb_vwv[10]=76 (0x4C)
> smb_vwv[11]=112 (0x70)
> 
> 
> Increasing the debug level to 5:
> 
> 
> api_rpc_command: api_ntlsa_rpc op 0xf - api_rpc_command:
> LSA_LOOKUPSIDS
> 000018 lsa_io_q_lookup_sids 
>         000018 data: 00 00 00
> 00 04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 
>         00002c
> num_entries : 00000002
>         000030 ptr_sid_enum: 00154238
>         000034
> num_entries2: 00000002
>         000038 ptr_sid[0]: 00154e20
>         00003c
> ptr_sid[1]: 00154e44
>             000040 num_auths: 00000006
> 
> 000044 sid_rev_num: 01
>                 000045 num_auths  : 06
> 
>   000046 id_auth[0] : 00
>                 000047 id_auth[1] : 00
> 
>     000048 id_auth[2] : 00
>                 000049 id_auth[3] : 00
> 
>       00004a id_auth[4] : 00
>                 00004b id_auth[5] : 05
> 
>         00004c sub_auths : 00000015 0000007b 000001c8 00000315 0000007b
> 000005dc 
>             000064 num_auths: 00000006
>                 000068
> sid_rev_num: 01
>                 000069 num_auths  : 06
> 
> 00006a id_auth[0] : 00
>                 00006b id_auth[1] : 00
> 
>   00006c id_auth[2] : 00
>                 00006d id_auth[3] : 00
> 
>     00006e id_auth[4] : 00
>                 00006f id_auth[5] : 05
> 
>       000070 sub_auths : 00000015 0000007b 000001c8 00000315 0000007b
> 000005dc 
>         000088 num_entries    : 00000000
>         00008c
> ptr_trans_names: 00000000
>         000090 num_entries2   :
> 000f0002
> ===============================================================
> INT
> ERNAL ERROR: Signal 11 in pid 533 (ntdom-1.9.18alpha14)
> Please read the
> file BUGS.txt in the
> distribution
> ===============================================================

> ===============================================================
> Core
> limits now 4194304 2147483647
> Dumping core in /usr/local/samba/var/corefiles

> No core file are being generated in /usr/local/samba/var/corefiles

> Unfortunately, I don't know what I have done to cause this problem,
> so currently I am not being able to reproduce in a precise way what is
> happening.
> 
> If anyone have any hint in how to debug more precisely this,
> I would be glad to know ...

this is the kind of detailed report that i like to see: thanks, andre.

ok.  under these circumstances, what i usually do is gdb smbd [process
number] then continue.  make sure you attach to the right smbd process,
i.e _after_ a connection has been established.  don't leave the process
paused for too long, or the nt wksta will time out, and you'll have to
start again.

then when the error occurs, it will trap on exactly the right line number.
well, that's assuming that the stack isn't overwritten (x86), and assuming
you've compiled with -g -g.

try looking elsewhere for the core dump, by the way: it sometimes lies
about the location.

what else...  oh, yes: just add lots of DEBUG(5,("trans_names(%d): %d\n",
__LINE__, num_entries or other useful debug info)); statements, doing a
binary search on the problem.  if it's reproducible, that is.  in this
instance, andre, you say it isn't.

however, if you are accessing a file on your local system (or a profile) 
then the NT wksta looks up the RID (i've seen this happen, but only once
or twice).  as it does this, it sends a LsaLookupSids call, to the PDC
(the samba server). 

unfortunately, something's going wrong with this call.  gotta sort it out,
too...

lukes