Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 17 Nov 2006 17:14:40 +0100
From:      Vincent Blondel <vincent@xtra-net.org>
To:        freebsd-stable@freebsd.org
Cc:        vincent@xtra-net.org, kris@obsecurity.org
Subject:   Re: kernel crash ...
Message-ID:  <1163780080.2697.6.camel@wbemfkaa.net.xtra-net.be>
In-Reply-To: <20061116214237.GA69412@xor.obsecurity.org>
References:  <1163621364.85632.12.camel@wbemfkaa.net.xtra-net.be> <1163692748.2792.10.camel@wbemfkaa.net.xtra-net.be> <20061116161706.GB65054@xor.obsecurity.org> <1163695124.2792.16.camel@wbemfkaa.net.xtra-net.be> <20061116210151.GA68673@xor.obsecurity.org> <1163712849.8157.5.camel@wbemfkaa.net.xtra-net.be> <20061116214237.GA69412@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2006-11-16 at 16:42 -0500, Kris Kennaway wrote:
> On Thu, Nov 16, 2006 at 10:34:09PM +0100, Vincent Blondel wrote:
> > Kris,
> > 
> > You are speaking about backtrace but sorry I do not know what does
> > exactly this command.
> 
> Check the developers handbook, there's a whole chapter about this
> topic :-)

thanks :-)

> 
> > Anyway, I see I did not give you result of backtrace for the second
> > kernel panic (this one I had this morning ..) so maybe are you waiting
> > for this result :
> 
> OK, this backtrace at least seems to be legitimate :-)
> 
> I'm not sure about the cause though, does it happen every time you run
> mailwrapper, or only under load?

sendmail_enable is defined to "NONE" so I can suppose I do not use
mailwrapper. 

How can I know it

> 
> Kris
> 
> P.S. Please don't top-post, it's already destroyed context from your
> posts so I have no idea whether you've already provided this
> information without reviewing your older emails.
> 
> > Unread portion of the kernel message buffer:
> > x0, limit 0xfffff, type 0x1b
> >                         = DPL 0, pres 1, def32 1, gran 1
> > processor eflags        = interrupt enabled, resume, IOPL = 0
> > current process         = 14294 (mailwrapper)
> > trap number             = 12
> > panic: page fault
> > cpuid = 0
> > Uptime: 6h23m20s
> > Dumping 1023 MB (2 chunks)
> >   chunk 0: 1MB (159 pages) ... ok
> >   chunk 1: 1023MB (261760 pages) 1007 991 975 959 943 927 911 895 879
> > 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 591
> > 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303
> > 287 271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
> > 
> > #0  doadump () at pcpu.h:165
> > 165     pcpu.h: No such file or directory.
> >         in pcpu.h
> > (kgdb) backtrace
> > #0  doadump () at pcpu.h:165
> > #1  0xc04e3436 in boot (howto=260)
> > at /usr/src/sys/kern/kern_shutdown.c:409
> > #2  0xc04e375d in panic (fmt=0xc064447a "%s")
> > at /usr/src/sys/kern/kern_shutdown.c:565
> > #3  0xc062bd30 in trap_fatal (frame=0xe71cf9f4, eva=2378418688)
> > at /usr/src/sys/i386/i386/trap.c:837
> > #4  0xc062ba6f in trap_pfault (frame=0xe71cf9f4, usermode=0,
> > eva=2378418688) at /usr/src/sys/i386/i386/trap.c:745
> > #5  0xc062b6c9 in trap (frame=
> >       {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 135012352, tf_esi =
> > 176128, tf_ebp = -417531336, tf_isp = -417531360, tf_ebx = -999349952,
> > tf_edx = -968498816, tf_ecx = 4, tf_eax = 1, tf_trapno = 12, tf_err = 0,
> > tf_eip = -1067261688, tf_cs = 32, tf_eflags = 66050, tf_esp =
> > -1057182640, tf_ss = -417531320}) at /usr/src/sys/i386/i386/trap.c:435
> > #6  0xc061810a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
> > #7  0xc062e108 in sf_buf_free (sf=0xc46f2140)
> > at /usr/src/sys/i386/i386/vm_machdep.c:783
> > #8  0xc05e1d6c in vm_imgact_unmap_page (sf=0x1)
> > at /usr/src/sys/vm/vm_glue.c:307
> > #9  0xc04b3ca8 in elf32_load_section (vmspace=0xc4dc1b90,
> > object=0xc7c3a084, offset=490048, vmaddr=0x80c0a40 <Address 0x80c0a40
> > out of bounds>,
> >     memsz=180788, filsz=9344, prot=3 '\003', pagesize=4096)
> > at /usr/src/sys/kern/imgact_elf.c:434
> > #10 0xc04b424b in exec_elf32_imgact (imgp=0xe71cfbe8)
> > at /usr/src/sys/kern/imgact_elf.c:694
> > #11 0xc04c808e in do_execve (td=0xc645e180, args=0xe71cfcb4, mac_p=0x0)
> > at /usr/src/sys/kern/kern_exec.c:426
> > #12 0xc04c7d94 in kern_execve (td=0xc645e180, args=0xe71cfcb4,
> > mac_p=0x0) at /usr/src/sys/kern/kern_exec.c:264
> > #13 0xc04c7c9a in execve (td=0xc645e180, uap=0x1)
> > at /usr/src/sys/kern/kern_exec.c:188
> > #14 0xc062c077 in syscall (frame=
> >       {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 134525001, tf_esi =
> > 134524992, tf_ebp = -1077940664, tf_isp = -417530524, tf_ebx =
> > -1077940692, tf_edx = 1, tf_ecx = 134529024, tf_eax = 59, tf_trapno =
> > 12, tf_err = 2, tf_eip = 671913639, tf_cs = 51, tf_eflags = 514, tf_esp
> > = -1077940732, tf_ss = 59})
> >     at /usr/src/sys/i386/i386/trap.c:983
> > #15 0xc061815f in Xint0x80_syscall ()
> > at /usr/src/sys/i386/i386/exception.s:200
> > #16 0x00000033 in ?? ()
> > Previous frame inner to this frame (corrupt stack?)
> > (kgdb) quit
> > root@sbepfkaa [/usr/obj/usr/src/sys/S2468GN] #
> > 
> > ---
> > 
> > Vincent
> > 
> > On Thu, 2006-11-16 at 16:01 -0500, Kris Kennaway wrote:
> > > On Thu, Nov 16, 2006 at 05:38:44PM +0100, Vincent Blondel wrote:
> > > > 
> > > > Hello Kris,
> > > > 
> > > > You can find below a generic make.conf I use to compile src/ports on my
> > > > all machines ( only AMD Athlon XP/MP ).
> > > > 
> > > > .CPUTYPE != sysctl hw.model |sed 's/ //g'
> > > > .if ${.CPUTYPE:M*AMDAthlon(tm)XP*}
> > > >     CFLAGS= -march=athlon-xp
> > > > .endif
> > > > .if ${.CPUTYPE:M*AMDAthlon(tm)MP*}
> > > >     CFLAGS= -march=athlon-mp
> > > > .endif
> > > > CFLAGS+= -O -pipe
> > > > CFLAGS+= -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3
> > > > .if ${.CURDIR:M/usr/src/*}
> > > >     CFLAGS+= -fno-strict-aliasing
> > > > .endif
> > > > .if ${.CURDIR:M/usr/ports/*}
> > > >     CFLAGS+= -Os -fomit-frame-pointer
> > > > .endif
> > > > COPTFLAGS= -O -pipe
> > > 
> > > I think you have the -fno-strict-aliasing backwards, BTW: /usr/src
> > > should be safe to compile with -fstrict-aliasing (but it's only
> > > enabled by default at -O2, so that's a NOP for you anyway), but ports
> > > definitely are not in general.
> > > 
> > > Also you might as well use CPUTYPE instead of manually setting CFLAGS
> > > to do the same thing.
> > > 
> > > Anyway, this doesn't seem to be the cause of your problems so I don't
> > > know why your backtraces are garbage.  Maybe you can try backtracing
> > > in DDB when you get a panic and see what that says instead.
> > > 
> > > Kris
> > 
> > 




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1163780080.2697.6.camel>