Date: Mon, 20 Jul 2015 20:59:21 +0000 From: bugzilla-noreply@freebsd.org To: chromium@FreeBSD.org Subject: [Bug 201543] www/chromium: chrome processes stuck at 100% cpu Message-ID: <bug-201543-28929-4oTgiOAB2V@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-201543-28929@https.bugs.freebsd.org/bugzilla/> References: <bug-201543-28929@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201543 --- Comment #5 from pete@nomadlogic.org --- (In reply to pete from comment #4) I have built a kernel with DDB support enabled. Here is the output from ddb invoked once chromium hit's the %100 CPU utilization bug: db> show proc 1061 Process 1061 (chrome) at 0xfffff8000303a000: state: NORMAL uid: 1001 gids: 1001, 0 parent: pid 1059 at 0xfffff8000303a4c0 ABI: FreeBSD ELF64 arguments: chrome: threads: 21 100630 S uwait 0xfffff8000e33eb80 chrome 100620 S uwait 0xfffff800a856b500 chrome 100576 S uwait 0xfffff801209f7480 chrome 100575 S uwait 0xfffff800afb82600 chrome 100573 S uwait 0xfffff8012065d480 chrome 100572 S uwait 0xfffff801209f6380 chrome 100571 S uwait 0xfffff800affae580 chrome 100564 S uwait 0xfffff800a83ffb80 chrome 100563 S uwait 0xfffff80120afb380 chrome 100552 S uwait 0xfffff800afbf6200 chrome 100528 S uwait 0xfffff80002fea400 chrome 100527 S uwait 0xfffff80120a57a80 chrome 100524 S uwait 0xfffff801209dab80 chrome 100521 S uwait 0xfffff80003111e80 chrome 100520 S uwait 0xfffff80120524c00 chrome 100515 Run CPU 1 chrome 100514 S uwait 0xfffff80003d29400 chrome 100513 S uwait 0xfffff800aff1f700 chrome 100512 S uwait 0xfffff80003112a00 chrome 100511 S piperd 0xfffff8005036a2e8 chrome 100308 S uwait 0xfffff800a82c8100 chrome db> tr 1061 Tracing pid 1061 tid 100630 td 0xfffff8000e856490 sched_switch() at sched_switch+0x2b3/frame 0xfffffe0000274850 mi_switch() at mi_switch+0xe1/frame 0xfffffe0000274890 sleepq_catch_signals() at sleepq_catch_signals+0xab/frame 0xfffffe0000274910 sleepq_wait_sig() at sleepq_wait_sig+0xf/frame 0xfffffe0000274940 _sleep() at _sleep+0x27d/frame 0xfffffe00002749c0 umtxq_sleep() at umtxq_sleep+0x125/frame 0xfffffe0000274a20 do_wait() at do_wait+0x329/frame 0xfffffe0000274aa0 __umtx_op_wait_uint_private() at __umtx_op_wait_uint_private+0x83/frame 0xfffffe0000274ae0 amd64_syscall() at amd64_syscall+0x351/frame 0xfffffe0000274bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0000274bf0 --- syscall (454, FreeBSD ELF64, sys__umtx_op), rip = 0x8098038cc, rsp = 0x7ffffbbdde88, rbp = 0x7ffffbbddeb0 --- db> show thread 1061 KDB: reentering KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00003320b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfffffe0000332160 kdb_reenter() at kdb_reenter+0x33/frame 0xfffffe0000332170 trap() at trap+0x54/frame 0xfffffe0000332380 calltrap() at calltrap+0x8/frame 0xfffffe0000332380 --- trap 0xc, rip = 0xffffffff8034cc52, rsp = 0xfffffe0000332440, rbp = 0xfffffe0000332470 --- db_show_thread() at db_show_thread+0x22/frame 0xfffffe0000332470 db_command() at db_command+0x26d/frame 0xfffffe0000332540 db_command_loop() at db_command_loop+0x64/frame 0xfffffe0000332550 db_trap() at db_trap+0xe0/frame 0xfffffe00003325e0 kdb_trap() at kdb_trap+0x129/frame 0xfffffe0000332630 trap() at trap+0x463/frame 0xfffffe0000332840 calltrap() at calltrap+0x8/frame 0xfffffe0000332840 --- trap 0x3, rip = 0xffffffff80970991, rsp = 0xfffffe0000332900, rbp = 0xfffffe0000332930 --- kdb_sysctl_enter() at kdb_sysctl_enter+0x91/frame 0xfffffe0000332930 sysctl_root() at sysctl_root+0x24e/frame 0xfffffe0000332980 userland_sysctl() at userland_sysctl+0x1d8/frame 0xfffffe0000332a30 sys___sysctl() at sys___sysctl+0x74/frame 0xfffffe0000332ae0 amd64_syscall() at amd64_syscall+0x351/frame 0xfffffe0000332bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe0000332bf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x80096529a, rsp = 0x7fffffffd9f8, rbp = 0x7fffffffda30 --- I will leave this system in ddb and can run additional commands as needed. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-201543-28929-4oTgiOAB2V>