Date: Sat, 13 Nov 2010 12:47:58 +0000 From: Alexander Best <arundel@freebsd.org> To: Kostik Belousov <kostikbel@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system Message-ID: <20101113124758.GA23469@freebsd.org> In-Reply-To: <20101113124146.GH2392@deviant.kiev.zoral.com.ua> References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org> <20101113122853.GG2392@deviant.kiev.zoral.com.ua> <20101113123846.GA21390@freebsd.org> <20101113124146.GH2392@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat Nov 13 10, Kostik Belousov wrote:
> On Sat, Nov 13, 2010 at 12:38:46PM +0000, Alexander Best wrote:
> > On Sat Nov 13 10, Kostik Belousov wrote:
> > > On Sat, Nov 13, 2010 at 11:59:00AM +0000, Alexander Best wrote:
> > > > On Sat Nov 13 10, Kostik Belousov wrote:
> > > > > On Fri, Nov 12, 2010 at 10:37:15PM +0000, Alexander Best wrote:
> > > > > > hi there,
> > > > > >
> > > > > > i'm having an issue with www/chromium. sometimes it will completely lock up my
> > > > > > system without producing a core dump. i'm running HEAD (r215102; amd64).
> > > > > Core dump of the kernel or the process ?
> > > >
> > > > a kernel core dump never gets produced. and this is the first time a process
> > > > dump made it to disk.
> > > >
> > > > >
> > > > > You probably should follow the usual procedure for the deadlock
> > > > > debugging, see dev handbook.
> > > >
> > > > i have all those options in my kernel conf. still the computer just locks up
> > > > without any chance to enter the debugger. nothing works any longer.
> > > Do you use serial or firewire console ? Since you run chromium, you
> > > should run X server, and you cannot use syscons for ddb while in X.
> >
> > nope. all i have is a usb mouse and a usb keyboard. ;)
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > this time however chrome.core made it to disk somehow:
> > > > > >
> > > > > ...
> > > > >
> > > > > > Loaded symbols for /libexec/ld-elf.so.1
> > > > > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675
> > > > > Please show the output of "info locals" in the frame 0.
> > > >
> > > > (gdb) frame 0
> > > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675
> > > > 2675 symp = symlook_list(name, hash, &list_main, &obj, ventry, flags,
> > > > (gdb) info locals
> > > > donelist = {objs = 0x7fffffbfde90, num_alloc = 64, num_used = 0}
> > > > def = (const Elf_Sym *) 0x0
> > > Right, this is what I suspected. def is NULL, but the code path selected
> > > seems to be the one which happens when def != NULL. This is either a
> > > random memory corruption inside the process, or might be some other
> > > usermode issue. It is very unlikely that it has anything with kernel
> > > deadlock.
> >
> > hmmm...but isn't the concept of UNIX that user applications cannot cause a
> > system to crash (protected mode)?
> >
> > i tried detaching and attaching my keyboard after chromium crashed my system
> > and the lights of the keyboard didn't even went on. so in fact everything
> > crashed and not just X.
> If I said it unclear, let me repeat, the usermode crash dump you got
> probably has nothing common with the kernel issue.
oh sorry. indeed i misunderstood you there. well i guess this is the problem
most regular users have. we don't own any serial/firewire consoles. all i can
offer is to add kernel OPTIONS. however none of them seem to be able to prevent
the lock up and instead letting me enter the debugger or trigger a kernel core
dump.
i even have watchdog running, but without any sucess. i guess all i can hope
for is that maybe at some point a kernel dump does make it to disk.
cheers.
alex
>
> Kernel problem should be taken care of first, and we cannot move
> forward without proper debugging tools (see above).
> >
> > cheers.
> > alex
> >
> > >
> > > > symp = (const Elf_Sym *) 0x7fffffbfe0e0
> > > > obj = Variable "obj" is not available.
> > > >
> > > > cheers.
> > > > alex
> > > >
> > > > >
> > > > > > 2675 symp = symlook_list(name, hash, &list_main, &obj, ventry, flags,
> > > > > > [New Thread 2ee6b40 (LWP 100245)]
> > > > > > [New Thread 2ee6000 (LWP 100212)]
> > > > > > (gdb) bt
> > > > > > #0 0x00000008026d76a2 in symlook_default (name=0x806797dbc "__sys_sigreturn", hash=92647454, refobj=0x802722c00, defobj_out=0x7fffffbfe160, ventry=0x802717790, flags=1) at /usr/src/libexec/rtld-elf/rtld.c:2675
> > > > > > #1 0x00000008026d815c in find_symdef (symnum=217, refobj=0x802722c00, defobj_out=0x7fffffbfe1a8, flags=1, cache=0x0) at /usr/src/libexec/rtld-elf/rtld.c:1205
> > > > > > #2 0x00000008026d8233 in _rtld_bind (obj=0x802722c00, reloff=Variable "reloff" is not available.
> > > > > > ) at /usr/src/libexec/rtld-elf/rtld.c:557
> > > > > > #3 0x00000008026d487d in _rtld_bind_start () at /usr/src/libexec/rtld-elf/amd64/rtld_start.S:99
> > > > > > #4 0xffffffff91969eb2 in ?? ()
> > > > > > #5 0x0000000000000000 in ?? ()
> > > > > > #6 0x0000000000000000 in ?? ()
> > > > > > #7 0xfffffffffffffbd0 in ?? ()
> > > > > > #8 0x00007fffffbfe260 in ?? ()
> > > > > > #9 0x00007fffffbfe260 in ?? ()
> > > > > > #10 0x0000000000000000 in ?? ()
> > > > > > #11 0x0000000002ee6000 in ?? ()
> > > > > > #12 0x0000000002ee6cb8 in ?? ()
> > > > > > #13 0x0000000000000206 in ?? ()
> > > > > > #14 0x0000000000000000 in ?? ()
> > > > > > #15 0x0000000802722c00 in ?? ()
> > > > > > #16 0x0000000000000024 in ?? ()
> > > > > > #17 0x000000080679fc26 in handle_signal (actp=Variable "actp" is not available.
> > > > > > ) at /usr/src/lib/libthr/thread/thr_sig.c:254
> > > > > > #18 0x000000080679fd5f in thr_sighandler (sig=20, info=0x7fffffbfea00, _ucp=0x7fffffbfe690) at /usr/src/lib/libthr/thread/thr_sig.c:181
> > > > > > #19 <signal handler called>
> > > > > > #20 0x00000008069cad6c in read () at read.S:3
> > > > > > #21 0x000000080679dc70 in __read (fd=15, buf=0x7fffffbfef84, nbytes=4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460
> > > > > > #22 0x000000000043871f in (anonymous namespace)::ShutdownDetector::ThreadMain ()
> > > > > > #23 0x0000000000984caa in ThreadFunc ()
> > > > > > #24 0x000000080679b81e in thread_start (curthread=0x2ee6b40) at /usr/src/lib/libthr/thread/thr_create.c:273
> > > > > > #25 0x0000000000000000 in ?? ()
> > > > > > Cannot access memory at address 0x7fffffbff000
> > > > > >
> > > > > > cheers.
> > > > > > alex
> > > > > >
> > > > > > --
> > > > > > a13x
> > > > > > _______________________________________________
> > > > > > freebsd-current@freebsd.org mailing list
> > > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
> > > >
> > > >
> > > >
> > > > --
> > > > a13x
> >
> >
> >
> > --
> > a13x
--
a13x
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101113124758.GA23469>