www/chromium crashing whole system

[Garrett Cooper]

On Sat, Nov 13, 2010 at 4:47 AM, Alexander Best <arundel at freebsd.org> wrote:
> 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.

If userland hasn't completely locked up, you could login remotely,
i.e. ssh, and poke at the box (if even for a brief period of time
before it goes down).
HTH,
-Garrett