Date: Sat, 13 Nov 2010 14:28:53 +0200 From: Kostik Belousov <kostikbel@gmail.com> To: Alexander Best <arundel@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: www/chromium crashing whole system Message-ID: <20101113122853.GG2392@deviant.kiev.zoral.com.ua> In-Reply-To: <20101113115900.GA14975@freebsd.org> References: <20101112223715.GA1356@freebsd.org> <20101113112447.GF2392@deviant.kiev.zoral.com.ua> <20101113115900.GA14975@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--ECRja8HA1lJ2QMij
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
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,
> > >=20
> > > i'm having an issue with www/chromium. sometimes it will completely l=
ock up my
> > > system without producing a core dump. i'm running HEAD (r215102; amd6=
4).
> > Core dump of the kernel or the process ?
>=20
> a kernel core dump never gets produced. and this is the first time a proc=
ess
> dump made it to disk.
>=20
> >=20
> > You probably should follow the usual procedure for the deadlock
> > debugging, see dev handbook.
>=20
> 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.
>=20
> >=20
> > >=20
> > > this time however chrome.core made it to disk somehow:
> > >=20
> > ...
> >=20
> > > Loaded symbols for /libexec/ld-elf.so.1
> > > #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__sys_=
sigreturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7fffffbfe=
160, ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld.c:2=
675
> > Please show the output of "info locals" in the frame 0.
>=20
> (gdb) frame 0
> #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__sys_sigr=
eturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7fffffbfe160,=
ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld.c:2675
> 2675 symp =3D symlook_list(name, hash, &list_main, &obj, ventry, flags,
> (gdb) info locals
> donelist =3D {objs =3D 0x7fffffbfde90, num_alloc =3D 64, num_used =3D 0}
> def =3D (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 !=3D 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.
> symp =3D (const Elf_Sym *) 0x7fffffbfe0e0
> obj =3D Variable "obj" is not available.
>=20
> cheers.
> alex
>=20
> >=20
> > > 2675 symp =3D symlook_list(name, hash, &list_main, &obj, ventry, fla=
gs,
> > > [New Thread 2ee6b40 (LWP 100245)]
> > > [New Thread 2ee6000 (LWP 100212)]
> > > (gdb) bt
> > > #0 0x00000008026d76a2 in symlook_default (name=3D0x806797dbc "__sys_=
sigreturn", hash=3D92647454, refobj=3D0x802722c00, defobj_out=3D0x7fffffbfe=
160, ventry=3D0x802717790, flags=3D1) at /usr/src/libexec/rtld-elf/rtld.c:2=
675
> > > #1 0x00000008026d815c in find_symdef (symnum=3D217, refobj=3D0x80272=
2c00, defobj_out=3D0x7fffffbfe1a8, flags=3D1, cache=3D0x0) at /usr/src/libe=
xec/rtld-elf/rtld.c:1205
> > > #2 0x00000008026d8233 in _rtld_bind (obj=3D0x802722c00, reloff=3DVar=
iable "reloff" is not available.
> > > ) at /usr/src/libexec/rtld-elf/rtld.c:557
> > > #3 0x00000008026d487d in _rtld_bind_start () at /usr/src/libexec/rtl=
d-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=3DVariable "actp" is no=
t available.
> > > ) at /usr/src/lib/libthr/thread/thr_sig.c:254
> > > #18 0x000000080679fd5f in thr_sighandler (sig=3D20, info=3D0x7fffffbf=
ea00, _ucp=3D0x7fffffbfe690) 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=3D15, buf=3D0x7fffffbfef84, nbyt=
es=3D4) at /usr/src/lib/libthr/thread/thr_syscalls.c:460
> > > #22 0x000000000043871f in (anonymous namespace)::ShutdownDetector::Th=
readMain ()
> > > #23 0x0000000000984caa in ThreadFunc ()
> > > #24 0x000000080679b81e in thread_start (curthread=3D0x2ee6b40) at /us=
r/src/lib/libthr/thread/thr_create.c:273
> > > #25 0x0000000000000000 in ?? ()
> > > Cannot access memory at address 0x7fffffbff000
> > >=20
> > > cheers.
> > > alex
> > >=20
> > > --=20
> > > 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"
>=20
>=20
>=20
> --=20
> a13x
--ECRja8HA1lJ2QMij
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (FreeBSD)
iEYEARECAAYFAkzehIQACgkQC3+MBN1Mb4ihHgCgun/dmo5GllvdM82ix2RcKEUh
uPEAoKFmDGT+OUaf9uVJZyJzBKqhqsb3
=V+1A
-----END PGP SIGNATURE-----
--ECRja8HA1lJ2QMij--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101113122853.GG2392>