Re: www/chromium crashing whole system

From: Kostik Belousov <kostikbel_at_gmail.com>
Date: Sat, 13 Nov 2010 14:41:46 +0200
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.

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_at_freebsd.org mailing list
> > > > > http://lists.freebsd.org/mailman/listinfo/freebsd-current
> > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> > > 
> > > 
> > > 
> > > -- 
> > > a13x
> 
> 
> 
> -- 
> a13x

Received on Sat Nov 13 2010 - 11:41:51 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:09 UTC