C6 Firefox 45.1 Segmentation Faults

Home » CentOS » C6 Firefox 45.1 Segmentation Faults
CentOS 45 Comments

on updated C6 x86_64 Firefox ESR 45.1.0 is seg faulting on various sites, mainly media sites. Tried uninstalling flash-plugin 11.2.202.616 but problem persists.

Work around: installed Seamonkey from epel repo

Anyone else experiencing unstable behaviour of FF 45.1 on C6?

45 thoughts on - C6 Firefox 45.1 Segmentation Faults

  • Day it was out I got the same. Since I already had some difficulties with RH6/C6 upgrades changing the way things worked (or didn’t, such as telinit), I just did a yum downgrade FF and and kept using my tools as tools.

    Bill

  • –HKDKUl6V0dwo8HHR0bBDJXhJAJPAfeJd3
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    Well, that update is critical for security, so I would try to help find the issues (we can feed back to RH and help them fix) .. rather than using something with critical security issues to browse the web.

    Some things that can help here:

    1. A site where you always get a crash.

    2. If you also have access to RHEL-6, test the firefox from RHEL-6 on the same site to verify if this is a RHEL or CentOS issue.

    Thanks, Johnny Hughes

    –HKDKUl6V0dwo8HHR0bBDJXhJAJPAfeJd3

  • Paired with nux’s ffmpeg on C6, I have this problem. Clear out of nux RPMS, and no such problem. Have yet to properly investigate the cause and feedback, as it’s a bank holiday. Was going to look properly next week.

    jh

  • I also have this problem. Am still running previous FF version. So ffmpeg appears to be at fault, need to see if it’s a version thing or something.

  • –VQDsDJ4x1kq25ocDlBSbDVgfLhL3RFCPg Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    There is a very new nspr/nss with the new firefox .. that probably is OK
    and not impacting anything.

    They have a gcc which they use also in the firefox package.

    Not sure about things like cairo/glib/gtk stuff without looking .. but maybe some of the things they do statically in the firefox is not happy with one of the system libraries for the plugins.

    Thanks, Johnny Hughes

    –VQDsDJ4x1kq25ocDlBSbDVgfLhL3RFCPg

  • huh, that file is a fairly normal looking H264 Mpeg4 AVC1 format,
    190×240 (ok, thats an odd aspect ratio), with a 33.333 frame/second frame rate (also a bit unusual), the video encoding is planar 4:4:4 YUV, also pretty normal.

  • On a fully updated CentOS 7 installation, firefox tells me “Video can’t be played because the file is corrupt.”

    VLC plays the video, but there is no sound. Is there supposed to be?

    I get the following output on the console:

    [0000000000df7118] core libvlc: Running vlc with the default interface. Use ‘cvlc’ to use vlc without interface.
    [00007fcb50044d38] vdpau_avcodec generic error: unsupported codec 28 or profile 244
    Failed to open VDPAU backend libvdpau_va_gl.so: cannot open shared object file: No such file or directory
    [00007fcb50062d28] freetype spu text error: Breaking unbreakable line

  • same on fully updated F23, ff 45.02

    also plays with no sound on the chrome browser on above F23 setup

    HTH

  • ===>

    what video player do you have selected to play video?

    here, with VLC as video player, video plays without problem.

  • I have uninstalled flash. It should just not play the video (with a message the plugin is not installed), not seg fault.

  • I know it is irrelevant, but just to add external data point: plays perfectly on FreeBSD 10.3, firefox-46.0_1,1

    Valeri

    ++++++++++++++++++++++++++++++++++++++++
    Valeri Galtsev Sr System Administrator Department of Astronomy and Astrophysics Kavli Institute for Cosmological Physics University of Chicago Phone: 773-702-4247
    ++++++++++++++++++++++++++++++++++++++++

  • Nux! wrote:
    Datum: CentOS 6.7, under firefox, 38, it opened movie player, and it played. I just updated firefox, I’m on 45.1.0, and streaming media is working as before, and I clicked on the link, and once I told noscript to allow it, it played the video in a tab.

    mark

  • On C5.11 with FF 45.1.0 patched, using M-Player plug-in = no problem.

    It appears to be a low resolution ultra-sound picture of a baby in the womb. Same effects when viewed with Xine.

  • I see the same crash on my RHEL-6 box. This one causes the crash consistently:

    https://twitter.com/motcho_tw/status/724960561302102016
    (it’s the official emblem of the 2020 Tokyo Olympics)

    Yes, ffmpeg (or ffmpeg-libs) seems to be involved. More particularly, according to:

    https://bugzilla.mozilla.org/show_bug.cgi?id46467

    a newer version of libavcodec might fix the issue. PUIAS (springdale)
    seems to provide it for EL6 but this has yet to be confirmed.

    Akemi

  • on C5.11 using FF 45.1.0 No video has been loaded Error Code: PLAYER_ERR_NO_SRC

  • I would like to, but since CentOS got integrated with RH I got the feeling that a non-CentOS problem didn’t get help here?

    With the upgrade to … 6.6 I, and others, reported problems with X vs. run-level changes causing issues.

    Starting here https://lists.CentOS.org/pipermail/CentOS/2014-November/148180.html

    Dec 7 2014 bug report: https://bugs.CentOS.org/view.php?idy72

    Nothing happened even though I took the time to post a bug and collect pertinent data and things discovered into a pastebin file with links for everything.

    So I made a guess that sans a RH subscription I had no way to pursue a non-CentOS issue.

    N.B. I’m operating based on a (faulty?) memory that prior to absorption into RH we used to post bugs on CentOS and someone at CentOS would examine, do whatever else, maybe request more info, and then put a bug
    (or requesst the reporter to do so?) on RH if appropriate and post tracking # to the list.

    That did not happen in this case even though the defect was obviously upstream, some potential causes were identified, based on what I had enough knowledge to investigate, and so I just adapted myself to what I
    thought the new environment was by not expending time & effort that would lead nowhere.

    This was reasonable for me since I had “worked around” the conflict between where X starts up by default and the assumed available VTs in the new-fangled start-up stuff.

    In the past I had tried to use the crash reporting thingy that Gnome provides, but I never had a clue where/how to send that stuff.

    As far as the security concerns, I’m a careful user and seldom “click through” on things I don’t recognize in e-mails or browsers. That’s given me decent results for over a decade now.

    I have it easier than many of you folks since I don’t admin anything but my own self-built & configured LAN behind an IPCop box and have only a few users: me, myself and I. And my wife & relatives might use my WAP to get to the net on the IPhones & such.

    That would be tough – when I open FF it’s on five desktops with multiple tabs open to myltiple sites in each instance.

    I can say this though. It acted the same on two CentOS-6.7 fully updated
    (identically) boxes (different hardware) that open (mostly) different sets of tabs. But in both cases there’s some similarity in that sites with javascript and on which server-provided java applications (my boxes are fully updated with the latest “official” java plugins) are activated early (Investorshub, part of the Advfn financial services network).

    ISTR that’s where the crash happened in each case as I RealVNC into the secondary box to ran the java app in the browser and display results on my primary unit.

    Don’t have RH subscription or installation.

    Thanks for responding, Bill

  • Maybe the same – I have 1 Windows 10 box up and on FF 45.02 there it just gives a very dark panel with a small squared outline within the tab.

    Bill

  • Plays with the downgraded FF version – a bit jerky. Might be my load though.

    Ditto: ffmpeg.x86_64 0.10.4-2.el6.nux
    @nux-dextop

    The “… pregnancy” plays on the downgraded FF, but no sound.

    Bill

  • Yes, that clip does not have sound.

    I’ll try to upgrade ffmpeg in the following days, see if that helps FF.

    If anyone has other ideas, I’m listening.

  • What I’m intending to do is to rebuild ffmpeg from PUIAS/springdale
    (see my earlier post). Specifically, ffmpeg-2.1.1-1.sdl6.src.rpm. It requires a lot of other packages though. :-)

    Akemi

  • Akemi,

    Most of the packages should already be in my repo, EPEL or PUIAS. If this works, I’ll look at incorporating it in nux-dextop.

    Lucian

  • With my short test, so far, so good. No crash with the site that used to bomb out.

    I needed the latest version of soxr(-devel) and xvidcore(-devel) from PUIAS to run (build) ffmpeg-2.1.1-1.sdl6. All other dependencies were available from EPEL and nux.

    Akemi

  • Morning,

    Thanks for testing Akemi, I’ll work towards upgrading ffmpeg then and the deps. Will be fun. :-)

  • To add to your fun, let me present my wish list:

    mplayer-gui and libquicktime (latest version from PUIAS) and mlt >= 0.9.4

    Thanks!
    Akemi

  • Akemi Yagi wrote:
    Ummm, NO. NOT the latter, under any circumstance… or hadn’t you missed the huge announcements that Apple would no longer support quicktime, and every organization, at least here in the States, and all the trade press, are saying uninstall quicktime yesterday!!!

    And yes, we have been told to make it go away here at work… and I work for a US federal gov’t agency (civilian sector).

    mark

  • Akemi Yagi wrote:
    >
    I understood that it’s not Apples (I wouldn’t expect them to release an rpm for us); however, I don’t know that the team building libquicktime is going to continue to upgrade and enhance, now that Apple’s ended all support for it, and everyone’s being pushed, at least in all organizations, to get rid of it, or if they might wind down the project;
    that is why I was emphatic about not wanting it.

    mark

  • Akemi,

    Noted, thanks. I am trying to rebuild all packages which require ffmpeg. Already hit problems with gstreamer-ffmpeg, had to give up and resort to using its internal ffmpeg.

    I’ll let you guys know when stuff is ready so we can test.

  • Ok, managed to rebuild most the stuff; had to retire gstreamer-vaapi though.

    yum –enablerepo=nux-dextop-testing update

    Should fix the Firefox issue, let me know if it causes any problems or other requests.

  • Thanks for the hard work!

    I got the following errors:

    –> Finished Dependency Resolution Error: Package: ffmpeg-libs-2.6.8-3.el6.nux.x86_64 (nux-dextop-testing)
    Requires: libx265.so.79()(64bit)
    Error: Package: mlt-0.9.6-2.el6.nux.x86_64 (nux-dextop-testing)
    Requires: opencv-core Error: Package: ffmpeg-libs-2.6.8-3.el6.nux.x86_64 (nux-dextop-testing)
    Requires: libsoxr.so.0()(64bit)

    Akemi

  • That’s because it’s not in the testing repo, it’s in the main one. :-)

    Make sure the main repo is enabled and perhaps run yum with –noplugins to make rule out other stuff.

  • My bad. Since the main repo is enabled by default, I thought it was ON. I apparently must have disabled it at some point.

    All is well now. The “crash” site no longer crashes. Will continue testing.

    Thanks a bunch!

    Akemi

  • –uBoNW2T0C3q6fIPDbvjADh6Eff0Q9E5XV
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    Nothing has changed .. we never fixed non CentOS problems and rolled those into the main tree. We have (and still do .. see http://people.CentOS.org/hughesjr/firefox-45.1.0-1.1.el5.CentOS/) .. sometimes provide some temporary things while fixes are being done by the outstanding RHEL engineers to fix issues.

    CentOS Linux is now what it always has been, a rebuild of the RHEL
    source code .. warts and all .. modified to remove branding to comply with the redistribution requirements. We don’t .. nor have we ever .. added in fixes to the main line trees that are not upstream in the RHEL
    source code.

    We do have many repositories where we manage content an try to fix problems: Extras, CentOSPlus, Special Interest Group content, etc. We do try to fix issues there as the come up.

    If one finds that there is a non-CentOS caused issue (but it is a RHEL
    issue), then they can open a bug on bugzilla.redhat.com. If you don’t have a RHEL subscription, it might be better if someone else opens the bug there, but someone from the community who can verify it is a RHEL
    bug can certainly open up a report. The RH Engineers want to make RHEL
    better, they want to fix real issues. There will obviously NOT be any kind of SLA to get it fixed by a deadline, but they absolutely want to fix RHEL issues.

    That is the actually the whole point of bugs.CentOS.org. We need ‘the community’ to look at bugs.CentOS.org and see if they can determine if bugs are CentOS related or RHEL related. If RHEL related, opening bugs on bugzilla.redhat.com. If CentOS related, help us fix them and test them, etc. by creating patches.

    We only have 5 total people on the CentOS team to do things. These things include building all the packages that get released for the 3
    base distos, QA those packages, manage all the Special Interest Group interactions, maintain a build infrastructure fr the base distros, maintain the Community Build System infrastructure for SIG builds, maintain the Mirror infrastructure, maintain all the QA / CI
    infrastructure, maintain all the overhead infrastructure (email servers, DNS servers, domain registrations, mailing list machines, IRC channels, authentication servers for all those things, etc). So we are managing hundreds of servers all over the world.

    We are also managing alternative architectures like i686, armhfp
    (arm32), aarch64 (arm64).

    Then there is all the cloud image things going on so there are cloud images for AWS, Oracle, Azure, vagrant boxes, docker images, vendor clouds, etc. etc. etc.

    The bottom line is .. CentOS needs community members, like our outstanding QA team and Forum Moderators (thanks guys and girls !!!) to be able to make things better. We need those community members to do lots of things.

    All the mailing list, forums, bugs databases .. they are all there to help facilitate for ‘the community’ to help itself and make CentOS Linux better .. by making RHEL better. If you can also use CentOS Linux for things that you want and it works for you, excellent. It is open source and free and that is what its for.

    In the case of this particular issue , it seems to have been an add on repo (Nux!) that did not work. And thru discussion on this list, it got fixed. I absolutely love the Nux! repo .. I use it on all my CentOS desktops .. thank you Nux! .. and the way this got fixed is exactly what I am talking about. Nux! has things not in the RHEL source code and not in EPEL that are necessary (IMHO for good desktops. He is an active list member and he (as a member of the community) provides invaluable help on this list as well as an outstanding service to the CentOS community with his repos.

    We want other things, even things in CentOS Linux where the issue is in RHEL. to be handled the same way as this issue. Start a discussion on the list, then if necessary report it at bugs.CentOS.org and try to determine if it is a RHEL or CentOS introduced issue (or maybe an EPEL
    or Nux! issue).

    While you are at bugs.CentOS.org .. look thorough open bugs. If you
    (you is anyone, not you Bill .. anywhere you is used in this reply :D)
    know how to fix something, propose a fix. If you can determine an open problem is a RHEL source issue and not something added by CentOS .. search the Red Hat bugzilla and see if it is reported. If it is reported, link the bug in the Red Hat bugzilla to the CentOS bug. Put a link back the the Red Hat bugzilla in the CentOS bug in the commments section. Feed Back info if you have any. That sends an email to people who might look at the bug in either place.

    Do this for bugs that you file .. and for any open bug that you might have some knowledge about.

    Thanks, Johnny Hughes

    –uBoNW2T0C3q6fIPDbvjADh6Eff0Q9E5XV

  • That part is as I remeber it. What I was remembering is that a possible bug would get reported, interaction possibly requesting more info would occur, and someone would possibly confirm and issue. The either the OP
    or CentOS flks(?) would post a bug in CentOS for tracking and someone would post a bug at RH, etc.

    As mentione in my post, my memory could be faulty, but what I just described is how I remeber it working.

    Then if RH fixed it the usual would occur.

    This is the part that, *if* my memory was correct, seems to have changed in that ISTR CentOS folks and/or other community members would have done what my memory (described above) describes and we would have seen a follow-up with a bug opened at RH.

    I can’t emphasize enough, it’s from my memoery of what used to occur.

    One additional person was kind enough to update my CentOS bug report confirming the same problem. That was the last action AFAICT though.

    Don’t misunderstand – the contribution you and all the CentOS members make is invaluable and well appreciated by me. It is one of the primary reasons I choose CentOS.

    The only point of my original post about the lack of follow up on the bug I posted was that it *appeared* that the behavior when a bug was reported *may* have changed (keeping in mind possibly faulty memory by me).

    I did all these things, within the limits of my current technical capabilities. And my bug report, as well as the start of this thred, suggested it was an upstream issue, which I thought might result in someone being able to promote it to RH’s bug system.

    To wrap up, I would like to again mention how much the efforts the CentOS team and community members expend.

    Thanks for taking the time to reply Johnny!

    Bill

  • Ah did a yum clean all and I see them now. Thank you Nux! from all of us using your great repo.