1 |
Hi! |
2 |
|
3 |
On 18/9/19 3:40 μ.μ., Mick wrote: |
4 |
> On Wednesday, 18 September 2019 08:51:54 BST Emmanuel Vasilakis wrote: |
5 |
>> On 18/9/19 1:19 π.μ., Walter Dnes wrote: |
6 |
>>> On Tue, Sep 17, 2019 at 06:16:22PM +0300, Emmanuel Vasilakis wrote |
7 |
>>> |
8 |
>>>> I've compiled firefox using these use flags: |
9 |
>>>> |
10 |
>>>> clang custom-cflags custom-optimization dbus gmp-autoupdate hwaccel lto |
11 |
>>>> pgo screenshot startup-notification system-av1 system-harfbuzz |
12 |
>>>> system-icu system-jpeg system-libevent system-libvpx system-sqlite |
13 |
>>>> system-webp |
14 |
>>>> |
15 |
>>>> (Didn't really change anything from previous firefox versions I |
16 |
>>>> compiled). |
17 |
>>>> |
18 |
>>> You may not have changed, but the ebuild defaults changed to use |
19 |
>>> |
20 |
>>> system libs, and some people have reported crashes, etc with Firefox 68. |
21 |
>>> Try disabling the system-av1 system-harfbuzz system-icu system-jpeg |
22 |
>>> system-libevent system-libvpx system-sqlite system-webp USE flags. This |
23 |
>>> will force Firefox to build with its own internal versions of these |
24 |
>>> libs. The build may take longer. |
25 |
>>> |
26 |
>>>> firefox-bin (69.0) behaves ok. |
27 |
>>>> |
28 |
>>> firefox-bin is self-contained, and uses its own internal libs... hmmm. |
29 |
>> |
30 |
>> Hi, thanks. |
31 |
>> |
32 |
>> I've always used system-% use flags for firefox, never had a problem, |
33 |
>> but yeah things could have changed in this version. |
34 |
> |
35 |
> Things have definitely changed with this version. From a previous thread on |
36 |
> FF 68 posted in this M/L and some experimentation on my systems it seems the |
37 |
> way addons are processed in FF 68 could cause FF to barf when being launched. |
38 |
> The fact FF works fine when launched with --safe-mode pointed to this and |
39 |
> (re)moving addonStartup.json.lz4 fixed the problem here. |
40 |
|
41 |
Did that, no change. I'm also using a fresh profile, so it should |
42 |
exclude things like that. |
43 |
|
44 |
> |
45 |
> |
46 |
>> Right now I'm compiling with disabled custom-cflags. Next will be to |
47 |
>> disable custom-optimization and if those don't help, I'll start |
48 |
>> disabling system-% flags. |
49 |
>> |
50 |
>> I've done an strace and it seems to hang waiting for a futex... |
51 |
> |
52 |
> So the browser is waiting for some value in memory to change or to be released |
53 |
> from some other process before it can be used by FF ... I think. |
54 |
> |
55 |
> |
56 |
>> Only problem is each try is gonna take ~5 hours on my poor machine. :-) |
57 |
>> |
58 |
>> We'll see! |
59 |
> |
60 |
> The high CPU could be indicating a graphics issue, where the browser cannot |
61 |
> use hardware acceleration for some reason on your system and it falls back on |
62 |
> software rendering. It may be worth running some browser rendering tests to |
63 |
> confirm this. |
64 |
> |
65 |
|
66 |
Well, the browsing itself seems fine (i.e. navigating pages). It's when |
67 |
I use it's UI that I experience these slowdowns. |
68 |
|
69 |
I have disabled custom-cflags & custom-optimization, did a build with |
70 |
clang 8 instead of 7, no change... |
71 |
|
72 |
I've also killed compton, and messed with the browser's acceleration |
73 |
settings with no luck. |
74 |
|
75 |
Next try I'll disable system-libevent & system-sqlite and see what |
76 |
happens... |
77 |
|
78 |
Emmanuel |