6:51 p.m.
Hi folks! At today's blocker review meeting, a couple of bugs came up
where we thought it would be helpful to get more testing to see if
other people see the bugs in question. Here they are:
https://bugzilla.redhat.com/show_bug.cgi?id=1439282 (Firefox tabs
crashing on certain sites)
https://bugzilla.redhat.com/show_bug.cgi?id=1429711 (setroubleshoot
crashing on first boot after install)
For the first one, if you run Firefox (from the Fedora package) on
Fedora 26, if you see tabs crashing unexpectedly, can you look at the
bug report (and some of the instructions for getting more information
on the crashes) and see if your experience matches any of the reporters
in the bug, and if so add a comment to the bug? On the other hand, if
you run Firefox (from the Fedora package) on Fedora 26 and you have
*not* had issues with tabs crashing regularly, please reply to this
mail and say so.
For the second one, it'd be great if after any Fedora 26 install you do
(e.g. for validation testing) you could run gnome-abrt, abrt-cli, or
any other way to check if ABRT has caught a crash in setroubleshoot
right after boot. If so, either run through the abrt reporting process
(and see if the crash comes up as a dupe of that bug), or add a comment
to the bug that you're also seeing setroubleshootd crash after a clean
install. On the other hand, if you've run several Fedora 26 installs
and have *not* seen the crash, that's useful information too.
Thanks a lot, folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
12:58 a.m.
2017-04-25 1:51 GMT+02:00 Adam Williamson <adamwill(a)fedoraproject.org>:
https://bugzilla.redhat.com/show_bug.cgi?id=1439282 (Firefox tabs
crashing on certain sites)
For the first one, if you run Firefox (from the Fedora package) on
Fedora 26, if you see tabs crashing unexpectedly, can you look at the
bug report (and some of the instructions for getting more information
on the crashes) and see if your experience matches any of the reporters
in the bug, and if so add a comment to the bug? On the other hand, if
you run Firefox (from the Fedora package) on Fedora 26 and you have
*not* had issues with tabs crashing regularly, please reply to this
mail and say so.
I used Firefox 51.0.1 on Fedora 26 Alpha 1.7, Firefox 52.0.2 and 53.0 on
Fedora 26 and Fedora 25, all on a 64bit machine, and I have never
encountered any of the problems reported in such bugzilla ticket.
My 2 cents,
A.
6:21 a.m.
On Mon, 24 Apr 2017 16:51:22 -0700, Adam Williamson wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1439282 (Firefox tabs
crashing on certain sites)
For the first one, if you run Firefox (from the Fedora package) on
Fedora 26, if you see tabs crashing unexpectedly, can you look at the
bug report (and some of the instructions for getting more information
on the crashes) and see if your experience matches any of the reporters
in the bug, and if so add a comment to the bug? On the other hand, if
you run Firefox (from the Fedora package) on Fedora 26 and you have
*not* had issues with tabs crashing regularly, please reply to this
mail and say so.
The latter request is not so helpful, since it turns this into a popularity
contest and may depend on which websites are visited.
The comments in the ticket are very confusing. There number is growing.
Where exactly can clear instructions be found?
For me it's Fedora 25 x86_64 that suffers badly from the tab crashing
problem. Upon visiting ordinary newspaper articles, such as
http://www.spiegel.de/fotostrecke/nordkorea-feiert-seine-armee-fotostreck...
I get "Gah. Your tab just crashed.", and the following SELinux Alert.
Is it related?
SELinux is preventing Chrome_ChildThr from 'read, write' accesses on the file
2F686F6D652F706572736F6E616C5F746D702F6D6F7A696C6C612D74656D702D393439353034363331202864656C6574656429.
***** Plugin mozplugger (93.0 confidence) suggests ************************
If you want to use the plugin package
Then you must turn off SELinux controls on the Firefox plugins.
Do
# setsebool -P unconfined_mozilla_plugin_transition 0
***** Plugin catchall_labels (6.67 confidence) suggests *******************
If you want to allow Chrome_ChildThr to have read write access on the
2F686F6D652F706572736F6E616C5F746D702F6D6F7A696C6C612D74656D702D393439353034363331202864656C6574656429
file
Then you need to change the label on
2F686F6D652F706572736F6E616C5F746D702F6D6F7A696C6C612D74656D702D393439353034363331202864656C6574656429
Do
# semanage fcontext -a -t FILE_TYPE
'2F686F6D652F706572736F6E616C5F746D702F6D6F7A696C6C612D74656D702D393439353034363331202864656C6574656429'
where FILE_TYPE is one of the following: afs_cache_t, cache_home_t, config_home_t,
data_home_t, dbus_home_t, gconf_home_t, gkeyringd_gnome_home_t, gnome_home_t,
gstreamer_home_t, home_cert_t, icc_data_home_t, mozilla_home_t, mozilla_plugin_tmp_t,
mozilla_plugin_tmpfs_t, mplayer_home_t, pulseaudio_home_t, puppet_tmp_t, texlive_home_t,
tmpfs_t, user_cron_spool_t, user_fonts_cache_t, user_tmp_t.
Then execute:
restorecon -v
'2F686F6D652F706572736F6E616C5F746D702F6D6F7A696C6C612D74656D702D393439353034363331202864656C6574656429'
***** Plugin catchall (1.73 confidence) suggests **************************
If you believe that Chrome_ChildThr should be allowed read write access on the
2F686F6D652F706572736F6E616C5F746D702F6D6F7A696C6C612D74656D702D393439353034363331202864656C6574656429
file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'Chrome_ChildThr' --raw | audit2allow -M my-ChromeChildThr
# semodule -X 300 -i my-ChromeChildThr.pp
Additional Information:
Source Context unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c
0.c1023
Target Context unconfined_u:object_r:unlabeled_t:s0
Target Objects 2F686F6D652F706572736F6E616C5F746D702F6D6F7A696C6C
612D74656D702D393439353034363331202864656C65746564
29 [ file ]
Source Chrome_ChildThr
Source Path Chrome_ChildThr
Port <Unknown>
Host localhost.localdomain
Source RPM Packages
Target RPM Packages
Policy RPM selinux-policy-3.13.1-225.11.fc25.noarch
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Host Name noname
Platform Linux noname 4.10.6-200.fc25.x86_64 #1 SMP Mon Mar
27 14:06:23 UTC 2017 x86_64 x86_64
Alert Count 14
First Seen 2017-04-06 22:44:05 CEST
Last Seen 2017-04-25 13:15:16 CEST
Local ID 05e95128-fead-4227-a0e9-eed46600a63c
Raw Audit Messages
type=AVC msg=audit(1493118916.89:232): avc: denied { read write } for pid=2099
comm="Chrome_ChildThr"
path=2F686F6D652F706572736F6E616C5F746D702F6D6F7A696C6C612D74656D702D393439353034363331202864656C6574656429
dev="dm-4" ino=265855
scontext=unconfined_u:unconfined_r:mozilla_plugin_t:s0-s0:c0.c1023
tcontext=unconfined_u:object_r:unlabeled_t:s0 tclass=file permissive=0
Hash: Chrome_ChildThr,mozilla_plugin_t,unlabeled_t,file,read,write
10:25 a.m.
On Tue, 2017-04-25 at 13:21 +0200, Michael Schwendt wrote:
On Mon, 24 Apr 2017 16:51:22 -0700, Adam Williamson wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1439282 (Firefox tabs
> crashing on certain sites)
> For the first one, if you run Firefox (from the Fedora package) on
> Fedora 26, if you see tabs crashing unexpectedly, can you look at the
> bug report (and some of the instructions for getting more information
> on the crashes) and see if your experience matches any of the reporters
> in the bug, and if so add a comment to the bug? On the other hand, if
> you run Firefox (from the Fedora package) on Fedora 26 and you have
> *not* had issues with tabs crashing regularly, please reply to this
> mail and say so.
The latter request is not so helpful, since it turns this into a popularity
contest and may depend on which websites are visited.
A popularity contest is precisely what I want, in this instance. We're
deciding on whether the bug is a release blocker. The primary
consideration for that decision is how commonly it is encountered.
The comments in the ticket are very confusing. There number is
growing.
Where exactly can clear instructions be found?
Focus on the earlier comments from the original reporters. There aren't
'clear instructions' exactly, though, it's not a "Step 1. Foo, Step 2.
Bar, Step 3. CRASH!" bug.
For me it's Fedora 25 x86_64 that suffers badly from the tab
crashing
problem. Upon visiting ordinary newspaper articles, such as
http://www.spiegel.de/fotostrecke/nordkorea-feiert-seine-armee-fotostreck...
I get "Gah. Your tab just crashed.", and the following SELinux Alert.
Is it related?
From the message, this looks a lot like Firefox plugins are involved.
Can you try turning off your plugins one by one to try and identify the
significant one?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10:33 a.m.
On Tue, 25 Apr 2017 08:25:06 -0700, Adam Williamson wrote:
> For me it's Fedora 25 x86_64 that suffers badly from the tab
crashing
> problem. Upon visiting ordinary newspaper articles, such as
>
>
http://www.spiegel.de/fotostrecke/nordkorea-feiert-seine-armee-fotostreck...
>
> I get "Gah. Your tab just crashed.", and the following SELinux Alert.
> Is it related?
From the message, this looks a lot like Firefox plugins are involved.
Can you try turning off your plugins one by one to try and identify the
significant one?
Absolutely no plugins installed. "about:plugins" refers to a disabled
"OpenH264 Video Codec provided by Cisco Systems, Inc." somewhere below
~/.mozilla, but deleting that doesn't change anything.
3:52 p.m.
On Tue, 2017-04-25 at 17:33 +0200, Michael Schwendt wrote:
On Tue, 25 Apr 2017 08:25:06 -0700, Adam Williamson wrote:
> > For me it's Fedora 25 x86_64 that suffers badly from the tab crashing
> > problem. Upon visiting ordinary newspaper articles, such as
> >
> >
http://www.spiegel.de/fotostrecke/nordkorea-feiert-seine-armee-fotostreck...
> >
> > I get "Gah. Your tab just crashed.", and the following SELinux
Alert.
> > Is it related?
>
> From the message, this looks a lot like Firefox plugins are involved.
> Can you try turning off your plugins one by one to try and identify the
> significant one?
Absolutely no plugins installed. "about:plugins" refers to a disabled
"OpenH264 Video Codec provided by Cisco Systems, Inc." somewhere below
~/.mozilla, but deleting that doesn't change anything.
Hum, that's interesting, then - I was going on the source context:
unconfined_u:unconfined_r:mozilla_plugin_t
I guess maybe some other files in Firefox have that context, even
though it looks specific to plugins?
Anyhow, there's an obvious thing to do since you have an AVC: try with
SELinux in permissive mode. If that makes the crash go away, seems like
a good indicator your crash is caused by the denial, so then go ahead
and file a bug for the denial using setroubleshoot...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
7:20 p.m.
On Tue, 25 Apr 2017 13:52:09 -0700, Adam Williamson wrote:
> Absolutely no plugins installed. "about:plugins"
refers to a disabled
> "OpenH264 Video Codec provided by Cisco Systems, Inc." somewhere below
> ~/.mozilla, but deleting that doesn't change anything.
Hum, that's interesting, then - I was going on the source context:
unconfined_u:unconfined_r:mozilla_plugin_t
I guess maybe some other files in Firefox have that context, even
though it looks specific to plugins?
The file the alert refers to is shown as hex numbers, which looks like
some unrelated bug in the tool, and converting it to ASCII, it refers to a
temporary file:
/home/personal_tmp/mozilla-temp-5642305 (deleted)
The beginning of that path is based on a redirected $TMPDIR, but
this SELinux issue is not related to the Firefox tab crashes.
7:58 p.m.
On Wed, 2017-04-26 at 02:20 +0200, Michael Schwendt wrote:
On Tue, 25 Apr 2017 13:52:09 -0700, Adam Williamson wrote:
> > Absolutely no plugins installed. "about:plugins" refers to a
disabled
> > "OpenH264 Video Codec provided by Cisco Systems, Inc." somewhere
below
> > ~/.mozilla, but deleting that doesn't change anything.
>
> Hum, that's interesting, then - I was going on the source context:
>
> unconfined_u:unconfined_r:mozilla_plugin_t
>
> I guess maybe some other files in Firefox have that context, even
> though it looks specific to plugins?
The file the alert refers to is shown as hex numbers, which looks like
some unrelated bug in the tool, and converting it to ASCII, it refers to a
temporary file:
/home/personal_tmp/mozilla-temp-5642305 (deleted)
That's the *target* file / context. I was looking at the *source*
context. Nice catch about the hex number, though, I thought it was just
a cryptically-named temporary file. That's definitely worth reporting
(against setroubleshoot, I think).
The beginning of that path is based on a redirected $TMPDIR, but
this SELinux issue is not related to the Firefox tab crashes.
You tried with permissive and it doesn't crash?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
1:22 p.m.
On Apr 25, 2017 13:22, "Michael Schwendt" <mschwendt(a)gmail.com> wrote:
The latter request is not so helpful, since it turns this into a popularity
contest and may depend on which websites are visited.
Well, it is true that this request could easily turn into a contest. But
looking at the bug report, it seems this is an always reproducible issue.
But if a big part of us are not affected, maybe we need more investigation,
but the bug should not be considered as a blocking one.
As stated before if I visit Twitter (as reported in bugzilla) or the link
you have posted, I don't hit any Firefox crash under various installations
of Fedora.
Ciao
A.
7:15 p.m.
On Tue, 25 Apr 2017 20:22:45 +0200, Alessio Ciregia wrote:
Well, it is true that this request could easily turn into a contest.
But
looking at the bug report, it seems this is an always reproducible issue.
That remains to be seen. There are websites, which make Firefox crash
reproducible for the user, who is affected by the bug, but it cannot be
guaranteed that the contents served at the URL are the same for everyone
at every location and 24/7, too.
Private browsing seems to have an influence.
But if a big part of us are not affected,
It's a fallacy to hope for such conclusions. The sample isn't large enough
for anyone to conclude that "a big part" of the users isn't affected.
There seem to be some bugzilla tickets about "Gah. Your tab just crashed.",
such as https://bugzilla.redhat.com/1440569 but how many users take
the time to submit such a problem report manually?
maybe we need more investigation,
but the bug should not be considered as a blocking one.
Only somebody with enough insight (such as intimate knowledge of Firefox)
should decide on that. It would be silly to release a broken Firefox,
which crashes early for users depending on what websites they visit first
or where on this world they live to be affected by ad banners/videos or
anything that causes these crashes.
9:43 a.m.
I had the 'gah' message *once* when I was using Firefox 52,
but since upgrading to Firefox 53, I have not not experienced
it at all.
[It was a big problem in Fedora 25, though.]
Adam Williamson wrote:
Hi folks! At today's blocker review meeting, a couple of
bugs came up
where we thought it would be helpful to get more testing to
see if
other people see the bugs in question. Here they are:
https://bugzilla.redhat.com/show_bug.cgi?id=1439282 (Firefox
tabs
crashing on certain sites)
https://bugzilla.redhat.com/show_bug.cgi?id=1429711
(setroubleshoot
crashing on first boot after install)
For the first one, if you run Firefox (from the Fedora
package) on
Fedora 26, if you see tabs crashing unexpectedly, can you
look
at the
bug report (and some of the instructions for getting more
information
on the crashes) and see if your experience matches any of
the
reporters
in the bug, and if so add a comment to the bug? On the other
hand, if
you run Firefox (from the Fedora package) on Fedora 26 and
you
have
*not* had issues with tabs crashing regularly, please reply
to
this
mail and say so.
For the second one, it'd be great if after any Fedora 26
install you do
(e.g. for validation testing) you could run gnome-abrt,
abrt-cli, or
any other way to check if ABRT has caught a crash in
setroubleshoot
right after boot. If so, either run through the abrt
reporting
process
(and see if the crash comes up as a dupe of that bug), or
add
a comment
to the bug that you're also seeing setroubleshootd crash
after a clean
install. On the other hand, if you've run several Fedora 26
installs
and have *not* seen the crash, that's useful information
too.
Thanks a lot, folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT
happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- test(a)lists.fedoraproject.org
To unsubscribe send an email to test-
leave(a)lists.fedoraproject.org
9:46 a.m.
Is working WiFi going to be a requirement for Fedora 26?
https://bugzilla.redhat.com/show_bug.cgi?id=1435793
I sure hope so. This morning's kernel has done nothing.
Adam Williamson wrote:
Hi folks! At today's blocker review meeting, a couple of
bugs came up
where we thought it would be helpful to get more testing to
see if
other people see the bugs in question. Here they are:
https://bugzilla.redhat.com/show_bug.cgi?id=1439282 (Firefox
tabs
crashing on certain sites)
https://bugzilla.redhat.com/show_bug.cgi?id=1429711
(setroubleshoot
crashing on first boot after install)
For the first one, if you run Firefox (from the Fedora
package) on
Fedora 26, if you see tabs crashing unexpectedly, can you
look
at the
bug report (and some of the instructions for getting more
information
on the crashes) and see if your experience matches any of
the
reporters
in the bug, and if so add a comment to the bug? On the other
hand, if
you run Firefox (from the Fedora package) on Fedora 26 and
you
have
*not* had issues with tabs crashing regularly, please reply
to
this
mail and say so.
For the second one, it'd be great if after any Fedora 26
install you do
(e.g. for validation testing) you could run gnome-abrt,
abrt-cli, or
any other way to check if ABRT has caught a crash in
setroubleshoot
right after boot. If so, either run through the abrt
reporting
process
(and see if the crash comes up as a dupe of that bug), or
add
a comment
to the bug that you're also seeing setroubleshootd crash
after a clean
install. On the other hand, if you've run several Fedora 26
installs
and have *not* seen the crash, that's useful information
too.
Thanks a lot, folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT
happyassassin . net
http://www.happyassassin.net
_______________________________________________
test mailing list -- test(a)lists.fedoraproject.org
To unsubscribe send an email to test-
leave(a)lists.fedoraproject.org
10:29 a.m.
On Wed, Apr 26, 2017 at 8:46 AM, Peter Gueckel <pgueckel(a)gmail.com> wrote:
Is working WiFi going to be a requirement for Fedora 26?
https://bugzilla.redhat.com/show_bug.cgi?id=1435793
I sure hope so. This morning's kernel has done nothing.
If a significant minority were having this problem, I imagine it'd be
a blocker. But I'm not having this problem with any 4.10 kernel on two
totally different laptops with different wireless makes. And I haven't
heard of anyone else having this problem.
First step is to see if anyone has filed a bug upstream against the
same wireless hardware you have. And then you can track that.
If there isn't an upstream bug yet, the unfortunate reality is that
you'll have to file one if you want to get it fixed. Upstream is
pretty good about responding to regressions like this so long as you
narrow it down to a specific kernel version where the regression first
happened; and they're even more responsive when you do a bisect to
narrow down the commit that's likely to blame (probably because a
specific commit puts the regression blame on a specific person, haha).
Anyway, somebody has to do it. If no one does it, it likely won't get
fixed on its own. Also for Fedora 26, we're on 4.11rc8 so you could
just test that and see if the regression is already fixed.
--
Chris Murphy
2583
days inactive
2585
days old
12 comments
5 participants
participants (5)
-
Adam Williamson -
Alessio Ciregia -
Chris Murphy -
Michael Schwendt -
Peter Gueckel