When a user print, sometimes, samba fail. Here : the backtrace #0 0x420ae169 in wait4 () from /lib/i686/libc.so.6 #1 0x4212a2d0 in __DTOR_END__ () from /lib/i686/libc.so.6 #2 0x42041fc4 in do_system () from /lib/i686/libc.so.6 #3 0x08180942 in smb_panic (why=0x8225c3d "internal error") at lib/util.c:1391 #4 0x081722ab in fault_report (sig=11) at lib/fault.c:41 #5 <signal handler called> #6 0x4207a4f3 in strlen () from /lib/i686/libc.so.6 #7 0x4207a2a5 in strdup () from /lib/i686/libc.so.6 #8 0x08185c5e in alloc_sub_basic (smb_name=0x8266e60 "NVE", str=0x0) at lib/substitute.c:494 #9 0x08076cdf in lp_string (s=0x0) at param/loadparm.c:1563 #10 0x080bb51f in make_connection (service_in=0xbfffeb30 "IPC$", password= {data = 0x8355948 "", length = 1, free = 0x817ea74 <free_data_blob>}, pdev=0xbfffea20 "IPC", vuid=100, status=0xbfffe61c) at smbd/service.c:827 #11 0x08094c86 in reply_tcon_and_X (conn=0x0, inbuf=0x404ac008 "", outbuf=0x404cd008 "", length=67, bufsize=2920) at smbd/reply.c:268 #12 0x080b8471 in switch_message (type=117, inbuf=0x404ac008 "", outbuf=0x404cd008 "", size=67, bufsize=2920) at smbd/process.c:767 #13 0x080b85d1 in construct_reply (inbuf=0x404ac008 "", outbuf=0x404cd008 "", size=67, bufsize=2920) at smbd/process.c:797 #14 0x080b8796 in process_smb (inbuf=0x404ac008 "", outbuf=0x404cd008 "") at smbd/process.c:897 #15 0x080b925c in smbd_process () at smbd/process.c:1323 #16 0x081d47c8 in main (argc=2, argv=0x1) at smbd/server.c:887 #17 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 * The pathes for DEST null string can be correct this ?
Created attachment 226 [details] The extract of log file
I think that is only on win9x system when samba reload conf or the client hasn't make action since long time (sleeping, no action from the user).
Can you reproduce this against the latest SAMBA_3_0 cvs code? I know there were a couple of fixes post 3.0.0 that were in code sections related to this backtrace.
*** Bug 853 has been marked as a duplicate of this bug. ***
I've added in some protection against this NULL source string, but need to figure out the root cause. At least we won't crash now.
reseting target milestone. 3.0.1 has been frozen. WIll have to re-evaluate these.
I just fixed a crash bug on big endian boxes (e.g. Sparc). I'm betting this is fixed now.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.
I think I now have fixed the root cause of this problem - which was found by Coverity. The underlying issue was pointer aliases not being updated after a realloc. Jeremy.