1 |
On Saturday 25 June 2011 18:38:10 András Csányi did opine thusly: |
2 |
> On 2 June 2011 11:21, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
3 |
> > Chromium is not the problem, Flash is the problem. |
4 |
> > |
5 |
> > Flash is a piece of shit that has never worked right and Adobe |
6 |
> > are a bunch of fools that cannot code properly or securely. I |
7 |
> > can comfortably say this based on long hard bitter experience |
8 |
> > by the entire Linux community. |
9 |
> > |
10 |
> > If you choose to use Flash, you get to put up with the resulting |
11 |
> > problems. |
12 |
> |
13 |
> I'm not sure the Flash is the problem. Chromium uses Flash through |
14 |
> nspluginwrapper. I removed nspluginwrapper package and I recompiled |
15 |
> few package which depended on nspluginwrapper package. And Chromium |
16 |
> freezin and creating a D process as you can see on this picture. [1] |
17 |
> |
18 |
> http://sayusi.hu/blog/picture_about_htop |
19 |
> |
20 |
> I asked my friends - they are *nix administrators, and they told me |
21 |
> this below could be helpful. However, I don't have any idea what it |
22 |
> means. |
23 |
|
24 |
Flash is still the root cause, nspluginwrapper is only a symptom. |
25 |
|
26 |
Flash is notorious for having to fix the same issues over and over |
27 |
again in different bits of their code. Not only that, but they keep |
28 |
making the same mistakes repeatedly - a very common problem with |
29 |
proprietary code driven by deadline and profit-motivated managers. |
30 |
|
31 |
nspluginwrapper does it's best to cope with this ever-changing |
32 |
landscape, but you can't really blame it when things go wrong - Flash |
33 |
changes something and don't publish what has now changed. |
34 |
nspluginwrapper can't deal with the change, so it breaks. |
35 |
|
36 |
This will never change, because you can't pick up a turd by the clean |
37 |
end. |
38 |
|
39 |
You could submit your stacktrace below to a bug entry at b.g.o. and |
40 |
let the gentoo dev look at it. Most likely he will refer it upstream. |
41 |
|
42 |
|
43 |
|
44 |
> |
45 |
> sa-home sayusi # cat /proc/6725/wchan |
46 |
> call_rwsem_down_read_failed |
47 |
> sa-home sayusi # |
48 |
> |
49 |
> The callstack look like this (the copied just a part of it): |
50 |
> Jun 25 18:33:38 sa-home eep+0x7c/0x80 |
51 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8142017b>] |
52 |
> system_call_fastpath+0x16/0x1b |
53 |
> Jun 25 18:33:38 sa-home kernel: chrome S ffff8800b334b790 |
54 |
> 0 6923 6730 0x00000000 |
55 |
> Jun 25 18:33:38 sa-home kernel: ffff8800a6c47c48 0000000000000086 |
56 |
> ffff8800a6c47b18 ffffffff8109fe4a |
57 |
> Jun 25 18:33:38 sa-home kernel: ffff8800a6c47fd8 ffff8800a6c46010 |
58 |
> 0000000000000001 ffff8800b334b9a0 |
59 |
> Jun 25 18:33:38 sa-home kernel: 0000000000004000 000000000000d580 |
60 |
> ffff8800a6c47fd8 00000001a6c47d48 |
61 |
> Jun 25 18:33:38 sa-home kernel: Call Trace: |
62 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8109fe4a>] ? |
63 |
> zone_watermark_ok+0x1a/0x20 |
64 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8120a330>] ? |
65 |
> timerqueue_add+0x60/0xb0 |
66 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff81054aef>] ? |
67 |
> __hrtimer_start_range_ns+0x1df/0x3d0 |
68 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff810600fa>] ? |
69 |
> get_futex_key+0x15a/0x1c0 |
70 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff810603b5>] |
71 |
> futex_wait_queue_me+0xc5/0x100 |
72 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff810605fc>] |
73 |
> futex_wait+0x1ac/0x290 |
74 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff81053e40>] ? |
75 |
> update_rmtp+0x80/0x80 |
76 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff810624b1>] |
77 |
> do_futex+0x101/0xac0 |
78 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff810b6ee0>] ? |
79 |
> handle_mm_fault+0x120/0x230 |
80 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff81026a6c>] ? |
81 |
> do_page_fault+0x1ac/0x430 |
82 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff810be7b4>] ? |
83 |
> do_mmap_pgoff+0x344/0x390 |
84 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff81062ee6>] |
85 |
> sys_futex+0x76/0x170 |
86 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff810be900>] ? |
87 |
> sys_mmap_pgoff+0x100/0x190 |
88 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8142017b>] |
89 |
> system_call_fastpath+0x16/0x1b |
90 |
> Jun 25 18:33:38 sa-home kernel: chrome S 0000000000000001 |
91 |
> 0 6927 6730 0x00000000 |
92 |
> Jun 25 18:33:38 sa-home kernel: ffff8800a6d0bda8 0000000000000086 |
93 |
> 0000000000000001 ffff88013f4c1710 |
94 |
> Jun 25 18:33:38 sa-home kernel: ffff8800a6d0bfd8 ffff8800a6d0a010 |
95 |
> 0000000000000001 ffff8800a6c8eec0 |
96 |
> Jun 25 18:33:38 sa-home kernel: 0000000000004000 000000000000d580 |
97 |
> ffff8800a6d0bfd8 000000018171eec8 |
98 |
> Jun 25 18:33:38 sa-home kernel: Call Trace: |
99 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8136daad>] ? |
100 |
> sock_aio_read+0x16d/0x180 |
101 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8141e360>] ? |
102 |
> __mutex_lock_slowpath+0x1c0/0x260 |
103 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8136d4f5>] ? |
104 |
> sock_poll+0x15/0x20 |
105 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8141ec55>] |
106 |
> schedule_hrtimeout_range_clock+0x115/0x130 |
107 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8141e199>] ? |
108 |
> mutex_unlock+0x9/0x10 |
109 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff81106ea3>] ? |
110 |
> ep_scan_ready_list+0x183/0x190 |
111 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8141ec7e>] |
112 |
> schedule_hrtimeout_range+0xe/0x10 |
113 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff811071bc>] |
114 |
> ep_poll+0x2ec/0x350 |
115 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff81031b10>] ? |
116 |
> try_to_wake_up+0x120/0x120 |
117 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff811072e5>] |
118 |
> sys_epoll_wait+0xc5/0xe0 |
119 |
> Jun 25 18:33:38 sa-home kernel: [<ffffffff8142017b>] |
120 |
> system_call_fastpath+0x16/0x1b |
121 |
> Jun 25 18:33:38 sa-home kernel: SignalSender S ffff8800b3f079d0 |
122 |
> 0 6928 6730 0x00000000 |
123 |
> Jun 25 18:33:38 sa-home kernel: ffff8800a6c85c48 0000000000000086 |
124 |
> 0000000000000000 ffffffff81611020 |
125 |
> Jun 25 18:33:38 sa-home kernel: ffff8800a6c85fd8 ffff8800a6c84010 |
126 |
> 0000000000000000 ffff8800b3f07be0 |
127 |
> Jun 25 18:33:38 sa-home kernel: 0000000000004000 000000000000d580 |
128 |
> ffff8800a6c85fd8 0000000000000000 |
129 |
> |
130 |
> My question is that, should I report it on bugs.gentoo.org? By the |
131 |
> way, this bug is not depend on the version. |
132 |
-- |
133 |
alan dot mckinnon at gmail dot com |