Re: [gentoo-user] Firefox crashes on some www-pages on a newer Gentoo system

[gevisz]

2018-07-27 12:44 GMT+03:00 Mick <michaelkintzios@×××××.com>:
> On Friday, 27 July 2018 09:16:30 BST gevisz wrote:
>> I have two Gentoo systems on the same AMD Athlon 64 X2 computer.
>>
>> The old one was installed in July 2013 with
>> default/linux/amd64/13.0/desktop/gnome (stable)
>> profile and was updated till the middle of
>> July 2017. Initially it hosted Gnome2
>> but later I have switched to XFCE4.
>>
>> The new one was installed in January-February 2018
>> with default/linux/amd64/17.0/desktop (stable)
>> profile and was last updated yesterday. From the
>> very beginning it hosted no DE, only Awesome WM
>> and dbus.
>>
>> The home directory is the same and still remembers
>> Ubuntu 6.04 installation in 2006.
>>
>> On the old system, I had the problem that chromium
>> very often (but not always!) asked me for some
>> (keyring?) password when I opened a new www-page.
>>
>> Recompilation of it with different user flags did not help.
>
> Go to:
>
> chrome://settings/passwords
>
> Then disable "Offer to save passwords".  It should not ask
> you to save passwords thereafter.

Thank you for your reply.

Chromium asked for a password to keyring or something like
that and did it on opening almost any page, even that that
definitely did not need any password authentication.

So, it was something else than just saving password for pages.

But it does not matter much now because I currently do not
use Chromium any more because it compiles more than 26 hours
on my computer.

>> I thought that that was because of the gnome-keyring,
>> consolekit or policykit packages but without any proof.
>
> From what I understand Chrome/ium will ask the desktop
> password manager to handle the saving of website passwords.

I guess he [Chromium] asked me for the password from
a password manager I may be used in previous intallation
of Ubuntu 5 or 10 years ago. However, I never give him
that password (because did not remember any such
password or even when I could create it in the past), so
he asked almost every time he opened new page. :)

> Policykit/polkit provides a centralised mechanism for
> non-privileged processes to communicate with privileged
> ones; e.g. when a plain user wants to hibernate/shutdown,
> disable NICs, etc.
>
>  https://lwn.net/Articles/258592/
>
> Consolekit tracks user sessions and allows switching between
> users on the same PC without logging out.

I am using my computer alone, so I guess that I do not need it.

> As far as I know with the switch to systemd and its built-in
> seat/user/session management mechanisms Consolekit
> is no longer maintained.

I do not use systemd.

>> So, while installing the new Gentoo system, I decided
>> to avoid installing any package that needs gnome-keyring,
>> consolekit or policykit packages.
>
> I think you shouldn't have needed to do all this.
>
>> I have also set -pam -consolekit and -policykit in my
>> /etc/portage/make.conf
>
> PAM is used to separate applications from the underlying
> authentication mechanisms.  It checks OS user/account/passwd/session
> authentications when required by applications.  This is the backbone
> of managing Linux authentications today, although some applications
> retain their own application level authentication mechanism (e.g. SSH).

So, do you think that global -pam use flag can cause Firefox
and QupZilla to crash on loging web-pages?

> I don't think setting USE="-pam" is advisable for most dekstop use cases.
>
>> Chromium indeed never asked me for the mentioned
>> above password on the new Gentoo system.
>>
>> But I get another problem on the new Gentoo system:
>> Firefox and Qupzilla both crash on some (login) www-pages.
>>
>> Namely, Firefox shows the "Gah. Your tab just crashed"
>> when I try to log into my Yahoo e-mail account.
>>
>> This happens only after entering login and password,
>> so not good enough to reproduce.
>>
>> However, it shows the same message just after staying
>> about 3-5 seconds on the following internet banking
>> login page: https://www.privat24.ua/#login
>> No login or password needed. :)
>>
>> The last error messages sent to terminal by FF while I
>> try to open the last www-page are the following:
>>
>> [Parent 4099] WARNING: pipe error (56): Connection reset by peer:
>
> The server disconnected you.
>
>
>> file
>> /var/tmp/portage/www-client/firefox-52.8.0/work/firefox-52.8.0esr/ipc/chromi
>> um/src/chrome/common/ipc_channel_posix.cc, line 322
>
> I'm not sure if your firefox build is the same like shown here,

Yes, the same.

> but line 322 shows a I/O message loop where it checks if a connection
> is running so that it can respond.
>
> The page in question pops up a couple of things, after loading the initial
> page, including geolocation.

Geolocation frame pops up, but on the old Gentoo system
it does not lead to the tab crash.

> It may have something to do with this.
>
>> ###!!! [Parent][MessageChannel] Error:
>> (msgtype=0x2C0083,name=PBrowser::Msg_Destroy) Channel error: cannot
>> send/recv
>
> It seems the connection has been reset by the server, two processes running on
> your browser using IPC can't go anywhere and are torn down, but I'm no
> developer to know for sure.
>
>
>> As to the Qupzilla, it crashes on the page https://www.privat24.ua/#login
>> completely, with the following messages sent to terminal:
>>
>> [4376:4387:0727/105105.178569:ERROR:nss_ocsp.cc(591)] No
>> URLRequestContext for NSS HTTP handler. host: ocsp.digicert.com
> [snip ...]
>
> The browser is trying to check ocsp.digicert.com for the validity of the
> certificate, but there is some error with the URL.  Then (I'm guessing)
> there's some pop up in the browser to inform you of this error, which causes a
> mesa rendering fault with the output shown below:
>
>> r300 FP: Compiler Error:
>> /var/tmp/portage/media-libs/mesa-17.3.9/work/mesa-17.3.9/src/gallium/drivers
>> /r300/compiler/r300_fragprog_emit.c::translate_rgb_opcode():
>> translate_rgb_opcode: Unknown opcode DDY
>> Using a dummy shader instead.
>> QupZilla: Crashed :( Saving backtrace in
>> /home/user/.config/qupzilla/crashlog ...
>> Backtrace successfully saved in
>> /home/user/.config/qupzilla/crashlog/Crash-2018-07-27T10:51:11.txt
>>
>> The mentioned above crashlog file contains only the following:
>>
>> Time: Fri Jul 27 10:51:11 2018
>> Qt version: 5.9.6 (compiled with 5.9.4)
>> QupZilla version: 2.2.5
>> Rendering engine: QtWebEngine
>>
>> ============== BACKTRACE ==============
>> #0: qupzilla(+0x355b) [0x55691e37055b]
>> #1: /lib64/libc.so.6(+0x35c60) [0x7f3a568c3c60]
>> #2: [0x7f3a3c18d2c9]
>
> I wouldn't know why the rendered content causes a mesa fault with the gallium
> driver, which brings down the browser.  Are you running the browser in a
> container?  Does it have enough memory allocated to it?

No, I do not run browser in a container. There is also plenty of memory.
Here is the output from top with FF running:
$ top

top - 13:02:44 up  2:50,  1 user,  load average: 0.16, 0.26, 0.35
Tasks:  95 total,   1 running,  94 sleeping,   0 stopped,   0 zombie
%Cpu(s):  3.2 us,  6.5 sy,  0.0 ni, 90.3 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :   7721.3 total,   5504.1 free,    614.2 used,   1603.1 buff/cache
MiB Swap:  12000.0 total,  12000.0 free,      0.0 used.   6946.5 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+
COMMAND
 3648 root      20   0  450736  66136  46024 S  13.3   0.8   4:40.45 X
 5463 gevis     20   0 1957104 401300 121472 S   6.7   5.1   1:04.86
Web Content
    1 root      20   0    4328   1588   1488 S   0.0   0.0   0:01.22
init
    2 root      20   0       0      0      0 S   0.0   0.0   0:00.00
kthreadd
    3 root      20   0       0      0      0 S   0.0   0.0   0:00.03
ksoftirqd/0
    5 root       0 -20       0      0      0 S   0.0   0.0   0:00.00
kworker/0:0H

>> Strange enough, but on the old Gentoo system Firefox does not crash on
>> the said www-pages.
>>
>> I initially thought that all that because
>> I have set -consolekit and -policykit use
>> flags in my /etc/portage/make.conf on my
>> new Gentoo system but unsetting them
>> does not lead to any recompilation while running
>> # emerge --update --deep --with-bdeps=y --newuse --backtrack=100 --ask world
>>
>> Any thoughts about this?