On Tue, 2004-02-03 at 06:42, Jeremy Allison wrote: > On Mon, Feb 02, 2004 at 07:28:14PM +0100, Tarjei Huse wrote: > > Feb 2 19:11:50 grisen smbd[26068]: [2004/02/02 19:11:50, 0] > > lib/util.c:smb_panic(1408) > > Feb 2 19:11:50 grisen smbd[26068]: BACKTRACE: 17 stack frames: > > Feb 2 19:11:50 grisen smbd[26068]: #0 > > /usr/sbin/smbd(smb_panic+0x1ab) [0x81c6627] > > Feb 2 19:11:50 grisen smbd[26068]: #1 /usr/sbin/smbd [0x81b5231] > > Feb 2 19:11:50 grisen smbd[26068]: #2 /usr/sbin/smbd [0x81b5292] > > Feb 2 19:11:50 grisen smbd[26068]: #3 /lib/libc.so.6 [0x402293a8] > > Feb 2 19:11:50 grisen smbd[26068]: #4 /lib/libc.so.6 [0x402775a7] > > Feb 2 19:11:50 grisen smbd[26068]: #5 /lib/libc.so.6(malloc+0x98) > > [0x40276388] > > Feb 2 19:11:50 grisen smbd[26068]: #6 /usr/sbin/smbd [0x8092ad5] > > Feb 2 19:11:50 grisen smbd[26068]: #7 /usr/sbin/smbd [0x80930be] > > Feb 2 19:11:51 grisen smbd[26068]: #8 /usr/sbin/smbd [0x809332d] > > Feb 2 19:11:51 grisen smbd[26068]: #9 > > /usr/sbin/smbd(reply_trans+0xbb4) [0x8093f56] > > Feb 2 19:11:51 grisen smbd[26068]: #10 /usr/sbin/smbd [0x80d6d26] > > Feb 2 19:11:51 grisen smbd[26068]: #11 /usr/sbin/smbd [0x80d6dd6] > > Feb 2 19:11:51 grisen smbd[26068]: #12 > > /usr/sbin/smbd(process_smb+0x1fb) [0x80d712b] > > Feb 2 19:11:51 grisen smbd[26068]: #13 > > /usr/sbin/smbd(smbd_process+0x170) [0x80d7c6b] > > Feb 2 19:11:51 grisen smbd[26068]: #14 /usr/sbin/smbd(main+0x81e) > > [0x8230b59] > > Feb 2 19:11:51 grisen smbd[26068]: #15 > > /lib/libc.so.6(__libc_start_main+0xc7) [0x40215857] > > Feb 2 19:11:51 grisen smbd[26068]: #16 > > /usr/sbin/smbd(ldap_msgfree+0x71) [0x807fc71] > > Feb 2 19:11:51 grisen smbd[26068]: > > > > > > Is this of any help? Can you tell what is failing. I'll be compiling > > samba 3.0.2-rc2 tonight, but I would appreciate if someone can tell me > > where the problem is. > > Unfortunately this backtrace doesn't tell us much. We need a backtrace > with symbols and line numbers included to really help. Compile with -g > to get this.
This is almost certainly malloc pool corruption too. As Jeremy mentions in the next mail: > This is a corrupted malloc pool. If you have a malloc with checking > ability (such as the GNU one) you could try running for a while > with the environment variable MALLOC_CHECK_=2. This will make Samba > a little slower but will help track down the memory problem. > > Jeremy. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
signature.asc
Description: This is a digitally signed message part
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba