On Saturday 25 June 2011 18:38:10 András Csányi did opine thusly: > On 2 June 2011 11:21, Alan McKinnon <alan.mckin...@gmail.com> wrote: > > Chromium is not the problem, Flash is the problem. > > > > Flash is a piece of shit that has never worked right and Adobe > > are a bunch of fools that cannot code properly or securely. I > > can comfortably say this based on long hard bitter experience > > by the entire Linux community. > > > > If you choose to use Flash, you get to put up with the resulting > > problems. > > I'm not sure the Flash is the problem. Chromium uses Flash through > nspluginwrapper. I removed nspluginwrapper package and I recompiled > few package which depended on nspluginwrapper package. And Chromium > freezin and creating a D process as you can see on this picture. [1] > > http://sayusi.hu/blog/picture_about_htop > > I asked my friends - they are *nix administrators, and they told me > this below could be helpful. However, I don't have any idea what it > means.
Flash is still the root cause, nspluginwrapper is only a symptom. Flash is notorious for having to fix the same issues over and over again in different bits of their code. Not only that, but they keep making the same mistakes repeatedly - a very common problem with proprietary code driven by deadline and profit-motivated managers. nspluginwrapper does it's best to cope with this ever-changing landscape, but you can't really blame it when things go wrong - Flash changes something and don't publish what has now changed. nspluginwrapper can't deal with the change, so it breaks. This will never change, because you can't pick up a turd by the clean end. You could submit your stacktrace below to a bug entry at b.g.o. and let the gentoo dev look at it. Most likely he will refer it upstream. > > sa-home sayusi # cat /proc/6725/wchan > call_rwsem_down_read_failed > sa-home sayusi # > > The callstack look like this (the copied just a part of it): > Jun 25 18:33:38 sa-home eep+0x7c/0x80 > Jun 25 18:33:38 sa-home kernel: [<ffffffff8142017b>] > system_call_fastpath+0x16/0x1b > Jun 25 18:33:38 sa-home kernel: chrome S ffff8800b334b790 > 0 6923 6730 0x00000000 > Jun 25 18:33:38 sa-home kernel: ffff8800a6c47c48 0000000000000086 > ffff8800a6c47b18 ffffffff8109fe4a > Jun 25 18:33:38 sa-home kernel: ffff8800a6c47fd8 ffff8800a6c46010 > 0000000000000001 ffff8800b334b9a0 > Jun 25 18:33:38 sa-home kernel: 0000000000004000 000000000000d580 > ffff8800a6c47fd8 00000001a6c47d48 > Jun 25 18:33:38 sa-home kernel: Call Trace: > Jun 25 18:33:38 sa-home kernel: [<ffffffff8109fe4a>] ? > zone_watermark_ok+0x1a/0x20 > Jun 25 18:33:38 sa-home kernel: [<ffffffff8120a330>] ? > timerqueue_add+0x60/0xb0 > Jun 25 18:33:38 sa-home kernel: [<ffffffff81054aef>] ? > __hrtimer_start_range_ns+0x1df/0x3d0 > Jun 25 18:33:38 sa-home kernel: [<ffffffff810600fa>] ? > get_futex_key+0x15a/0x1c0 > Jun 25 18:33:38 sa-home kernel: [<ffffffff810603b5>] > futex_wait_queue_me+0xc5/0x100 > Jun 25 18:33:38 sa-home kernel: [<ffffffff810605fc>] > futex_wait+0x1ac/0x290 > Jun 25 18:33:38 sa-home kernel: [<ffffffff81053e40>] ? > update_rmtp+0x80/0x80 > Jun 25 18:33:38 sa-home kernel: [<ffffffff810624b1>] > do_futex+0x101/0xac0 > Jun 25 18:33:38 sa-home kernel: [<ffffffff810b6ee0>] ? > handle_mm_fault+0x120/0x230 > Jun 25 18:33:38 sa-home kernel: [<ffffffff81026a6c>] ? > do_page_fault+0x1ac/0x430 > Jun 25 18:33:38 sa-home kernel: [<ffffffff810be7b4>] ? > do_mmap_pgoff+0x344/0x390 > Jun 25 18:33:38 sa-home kernel: [<ffffffff81062ee6>] > sys_futex+0x76/0x170 > Jun 25 18:33:38 sa-home kernel: [<ffffffff810be900>] ? > sys_mmap_pgoff+0x100/0x190 > Jun 25 18:33:38 sa-home kernel: [<ffffffff8142017b>] > system_call_fastpath+0x16/0x1b > Jun 25 18:33:38 sa-home kernel: chrome S 0000000000000001 > 0 6927 6730 0x00000000 > Jun 25 18:33:38 sa-home kernel: ffff8800a6d0bda8 0000000000000086 > 0000000000000001 ffff88013f4c1710 > Jun 25 18:33:38 sa-home kernel: ffff8800a6d0bfd8 ffff8800a6d0a010 > 0000000000000001 ffff8800a6c8eec0 > Jun 25 18:33:38 sa-home kernel: 0000000000004000 000000000000d580 > ffff8800a6d0bfd8 000000018171eec8 > Jun 25 18:33:38 sa-home kernel: Call Trace: > Jun 25 18:33:38 sa-home kernel: [<ffffffff8136daad>] ? > sock_aio_read+0x16d/0x180 > Jun 25 18:33:38 sa-home kernel: [<ffffffff8141e360>] ? > __mutex_lock_slowpath+0x1c0/0x260 > Jun 25 18:33:38 sa-home kernel: [<ffffffff8136d4f5>] ? > sock_poll+0x15/0x20 > Jun 25 18:33:38 sa-home kernel: [<ffffffff8141ec55>] > schedule_hrtimeout_range_clock+0x115/0x130 > Jun 25 18:33:38 sa-home kernel: [<ffffffff8141e199>] ? > mutex_unlock+0x9/0x10 > Jun 25 18:33:38 sa-home kernel: [<ffffffff81106ea3>] ? > ep_scan_ready_list+0x183/0x190 > Jun 25 18:33:38 sa-home kernel: [<ffffffff8141ec7e>] > schedule_hrtimeout_range+0xe/0x10 > Jun 25 18:33:38 sa-home kernel: [<ffffffff811071bc>] > ep_poll+0x2ec/0x350 > Jun 25 18:33:38 sa-home kernel: [<ffffffff81031b10>] ? > try_to_wake_up+0x120/0x120 > Jun 25 18:33:38 sa-home kernel: [<ffffffff811072e5>] > sys_epoll_wait+0xc5/0xe0 > Jun 25 18:33:38 sa-home kernel: [<ffffffff8142017b>] > system_call_fastpath+0x16/0x1b > Jun 25 18:33:38 sa-home kernel: SignalSender S ffff8800b3f079d0 > 0 6928 6730 0x00000000 > Jun 25 18:33:38 sa-home kernel: ffff8800a6c85c48 0000000000000086 > 0000000000000000 ffffffff81611020 > Jun 25 18:33:38 sa-home kernel: ffff8800a6c85fd8 ffff8800a6c84010 > 0000000000000000 ffff8800b3f07be0 > Jun 25 18:33:38 sa-home kernel: 0000000000004000 000000000000d580 > ffff8800a6c85fd8 0000000000000000 > > My question is that, should I report it on bugs.gentoo.org? By the > way, this bug is not depend on the version. -- alan dot mckinnon at gmail dot com
