Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 598787 - [abrt] crash in firefox-3.6.3-4.fc13: Process /usr/lib/firefox-3.6/firefox was killed by signal 11 (SIGSEGV)
[abrt] crash in firefox-3.6.3-4.fc13: Process /usr/lib/firefox-3.6/firefox wa...
Status: CLOSED INSUFFICIENT_DATA
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
13
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Gecko Maintainer
Fedora Extras Quality Assurance
abrt_hash:2f4c4cc739ac31bc6b4b57ae44a...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-01 23:23 EDT by Justin O'Brien
Modified: 2010-06-03 09:11 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-06-03 09:11:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: backtrace (161.50 KB, text/plain)
2010-06-01 23:23 EDT, Justin O'Brien
no flags Details

  None (edit)
Description Justin O'Brien 2010-06-01 23:23:24 EDT
abrt 1.1.0 detected a crash.

architecture: i686
Attached file: backtrace
cmdline: /usr/lib/firefox-3.6/firefox
comment: this actually happened twice in a row
component: firefox
crash_function: nsProfileLock::FatalSignalHandler
executable: /usr/lib/firefox-3.6/firefox
global_uuid: 2f4c4cc739ac31bc6b4b57ae44a00d17dcb859f9
kernel: 2.6.33.4-95.fc13.i686
package: firefox-3.6.3-4.fc13
rating: 4
reason: Process /usr/lib/firefox-3.6/firefox was killed by signal 11 (SIGSEGV)
release: Fedora release 13 (Goddard)

How to reproduce
-----
1. add javascript button from http://www.reclaimprivacy.org/
2. try to check facebook privacy
3. report crash
Comment 1 Justin O'Brien 2010-06-01 23:23:29 EDT
Created attachment 418886 [details]
File: backtrace
Comment 2 Chris Campbell 2010-06-02 08:27:43 EDT
#3  <signal handler called>
No symbol table info available.
#4  0x0249d689 in nsContentUtils::ComparePosition (aNode1=0xa4ecf880, 
    aNode2=0x0) at nsContentUtils.cpp:1580
        parents1 = {<nsTPtrArray<nsINode>> = {<nsTArray<nsINode*>> = {<nsTArray_base> = {static sEmptyHdr = {mLength = 0, mCapacity = 0, mIsAutoArray = 0}, 
                mHdr = 0xbff7b228}, <No data fields>}, <No data fields>}, 
          mAutoBuf = "\000\000\000\000 \000\000\200\271\245N\002\300\221\303\245$K\205\245l\262\367\277p\351x\267\000x \243\002\000\000\000\\\262\367\277B\000\000\000\304\337w\000\000\364\060\003\001\000\000\000x\262\367\277\343\tw\000\004\000\000\000\374\364\060\003@\237\b\246\001\000\000\000\214\262\367\277U}\254\002\374\364\060\003@\237\b\246\001\000\000\000\254\262\367\277\017~\254\002\000\330P\267@\237\b\246\234\201\t\246\234\201\t\246\360}\254\002\374\364\060\003\314\262\367\277"}
        pos2 = <value optimized out>
        top1 = <value optimized out>
        parent = <value optimized out>
        len = <value optimized out>
        parents2 = {<nsTPtrArray<nsINode>> = {<nsTArray<nsINode*>> = {<nsTArray_base> = {static sEmptyHdr = {mLength = 0, mCapacity = 0, mIsAutoArray = 0}, 
                mHdr = 0xbff7b19c}, <No data fields>}, <No data fields>}, 
          mAutoBuf = "\000\000\000\000 \000\000\200\300\334\060\245\000K\205\245\314\261\367\277\224\207\063\002\240\322\017\243 U\016\245\320\343\273\245\320\343\273\245 U\016\245\000\370\363\244\334\262\367\277\037^4\002\000\370\363\244 U\016\245 U\016\245 U\016\245\000K\205\245\000\000\000\000\034\262\367\277\061\357L\002\024K\205\245\000K\205\245\000\000\000\000\000K\205\245\000K\205\245P\262\367\277,\262\367\277\356\006w\000\000K\205\245\300\221\303\245<\262\367\277(L\250\002"}
        attr1 = 0x0
        pos1 = <value optimized out>
        top2 = <value optimized out>
#5  0x02492a8d in PositionIsBefore (this=0xa6098180, aDocument=0xa46e2000, 
    aContainer=0xa50e5520, aNewIndexInContainer=58)
    at ../../../dist/include/nsContentUtils.h:284
No locals.
#6  nsContentList::ContentAppended (this=0xa6098180, aDocument=0xa46e2000, 
    aContainer=0xa50e5520, aNewIndexInContainer=58) at nsContentList.cpp:611
        ourLastContent = <value optimized out>
        ourCount = <value optimized out>
        appendToList = 0
        count = <value optimized out>
#7  0x024dd53f in nsNodeUtils::ContentAppended (aContainer=0xa50e5520, 
    aNewIndexInContainer=58) at nsNodeUtils.cpp:133
        iter_ = {<nsAutoTObserverArray<nsIMutationObserver*, 0u>::Iterator> = {<nsTObserverArray_base::Iterator_base> = {mPosition = 5, mNext = 0x0}, 
            mArray = @0xa50e5388}, <No data fields>}
        obs_ = {<nsCOMPtr_base> = {mRawPtr = 0xa609819c}, <No data fields>}
        slots = <value optimized out>
        node = 0xa46e2000
        doc = 0xa46e2000
#8  0x024d325f in nsGenericElement::doInsertChildAt (aKid=0xa5854b00, 
    aIndex=58, aNotify=1, aParent=0xa50e5520, aDocument=0xa46e2000, 
    aChildArray=...) at nsGenericElement.cpp:3238
        rv = 0
        container = 0xa50e5520
        isAppend = 1
        updateBatch = {mDocument = {<nsCOMPtr_base> = {
              mRawPtr = 0xa46e2000}, <No data fields>}, mUpdateType = 1}
        childCount = 58



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 3 Chris Campbell 2010-06-02 08:33:25 EDT
Reporter, is this reproducible on your system (happen every time)? I am unable to reproduce it on my own system.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 4 Justin O'Brien 2010-06-02 20:33:45 EDT
No this isn't happening anymore. Not sure what I did differently but it is working now.  thanks for following up :)
Comment 5 Chris Campbell 2010-06-03 09:11:53 EDT
Thank you for your speedy response. Going to close this one. Feel free to re-open at any time.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Note You need to log in before you can comment on or make changes to this bug.