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. Mike
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. Mike
please send me the log files <jerry@samba.org>. 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 backslashs */ + ZERO_STRUCT(notify_cli); + if(!spoolss_connect_to_client(¬ify_cli, client_ip, unix_printer)) return False;
patch commited to 3.0 cvs tree. Please test.
The bug is fixed. Thanks, Mike
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.
database cleanup