One of my windows 2000 machines, named wolverine(windows 2000 SP4), is causing a
Signal 11 within Samba when I browse my Samba server printers share. Here's how
it happens. I open network neighborhood in wolverine, and browse my way to my
samba server (named cerebro running on linux-2.4.21-bk30). I open up the
Printers share, and no printers are shown. Looking in my log.wolverine on the
server, I see that I've gotten a Signal 11 pid 1866 (Samba 3.0.0rc1). This
happens every time I open the printers share. The other W2K clients in our
network see all four network printers when the Cerebro Printers share is opened,
and no Signal 11 is generated. The Samba version I have is the CVS version of
3.0 as of Monday August 11 at 2100 hours EDT. I've got a log.wolverine and all
the other important files, which I can send if you provide an email address.
Ok, I did a little more digging and found out why only the wolverine W2K client
was affected, and not the other W2K client computers. Wolverine had "File and
Printer Sharing for Microsoft Networks" unchecked under the properties dialog of
the Local Area Connection. When I checked this box, then I no longer get the
Signal 11, and all four printers are visibile under the server printers share.
I hope this additional info will make the problem reproducible for you.
please send me the log files <email@example.com>. I've tried but
I can reproduce this locally.
Here's the stace trace.
error connecting to 192.168.2.128:445 (Connection refused)
Connecting to 192.168.2.128 at port 139
INTERNAL ERROR: Signal 11 in pid 1866 (3.0.0rc1)
Please read the appendix Bugs of the Samba HOWTO collection
PANIC: internal error
BACKTRACE: 26 stack frames:
#0 smbd(smb_panic+0xc9) [0x817fe51]
#1 smbd [0x817189e]
#2 /lib/libc.so.6 [0x402a8d48]
#3 smbd(cli_nt_session_close+0x23) [0x80c1d6f]
#4 smbd(cli_close_connection+0x10) [0x80c1de8]
#5 smbd(cli_initialise+0x281) [0x80c1cc9]
#6 smbd(attempt_netbios_session_request+0xec) [0x80c4c40]
#7 smbd [0x80fbb2d]
#8 smbd [0x80fbfc4]
#9 smbd(_spoolss_rffpcnex+0xda) [0x80fc1e6]
#10 smbd [0x80f3c14]
#11 smbd(api_rpcTNP+0x13a) [0x811f8a2]
#12 smbd(api_pipe_request+0x203) [0x811f6eb]
#13 smbd [0x8119e6d]
#14 smbd [0x811a158]
#15 smbd [0x811a4fb]
#16 smbd(write_to_pipe+0xc7) [0x811a46f]
#17 smbd [0x80864c3]
#18 smbd(reply_trans+0x48a) [0x8086ce2]
#19 smbd [0x80b7ea9]
#20 smbd [0x80b809f]
#21 smbd(process_smb+0x74) [0x80b824c]
#22 smbd(smbd_process+0x198) [0x80b8d58]
#23 smbd(main+0x404) [0x81d2b08]
#24 /lib/libc.so.6(__libc_start_main+0xa9) [0x402975cd]
#25 smbd(chroot+0x31) [0x8075d7d]
From a quick 10 minute look it sounds like the notify_cli global in
srv_spoolss_nt.c is not being set to something sensible if we can't make a
spoolss back channel connection. I've seen this before when trying to do a
cli_initialise on an uninitialised cli_struct.
*** srv_spoolss_nt.c.~1.277.2.72.~ Sat Aug 16 03:34:01 2003
--- srv_spoolss_nt.c Sat Aug 16 04:05:07 2003
*** 2668,2673 ****
--- 2668,2675 ----
fstrcpy(unix_printer, printer+2); /* the +2 is to strip the leading 2
if(!spoolss_connect_to_client(¬ify_cli, client_ip, unix_printer))
patch commited to 3.0 cvs tree. Please test.
The bug is fixed.
originally reported against 3.0.0beta3. CLeaning out
non-production release versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.