Bug 591014 - [abrt] crash in firefox-3.5.9-2.fc12: Process /usr/lib64/firefox-3.5/firefox was killed by signal 11 (SIGSEGV)
Summary: [abrt] crash in firefox-3.5.9-2.fc12: Process /usr/lib64/firefox-3.5/firefox ...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: 12
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Martin Stransky
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:47cd630cc5aaf87e94edbec1136...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-11 08:16 UTC by Sasan
Modified: 2010-07-16 07:37 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-07-16 07:37:18 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (29.06 KB, text/plain)
2010-05-11 08:16 UTC, Sasan
no flags Details
installed rpms. (1.40 KB, text/plain)
2010-06-08 10:16 UTC, Sasan
no flags Details
Output of gdb (10.03 KB, text/plain)
2010-06-08 10:20 UTC, Sasan
no flags Details

Description Sasan 2010-05-11 08:16:23 UTC
abrt 1.0.9 detected a crash.

architecture: x86_64
Attached file: backtrace
cmdline: /usr/lib64/firefox-3.5/firefox
component: firefox
crash_function: nsProfileLock::FatalSignalHandler
executable: /usr/lib64/firefox-3.5/firefox
global_uuid: 47cd630cc5aaf87e94edbec11367737e1752ee8f
kernel: 2.6.32.11-99.fc12.x86_64
package: firefox-3.5.9-2.fc12
rating: 4
reason: Process /usr/lib64/firefox-3.5/firefox was killed by signal 11 (SIGSEGV)
release: Fedora release 12 (Constantine)

comment
-----
Even using "firefox -safe-mode" ends up like this.
gdb reports:
Program received signal SIGSEGV, Segmentation fault.
0x00000038cb9329c8 in vtable for RDFXMLDataSourceImpl ()
   from /usr/lib64/xulrunner-1.9.1/libxul.so

How to reproduce
-----
1. Just tried to start firefox, and this happened.
2.
3.

Comment 1 Sasan 2010-05-11 08:16:29 UTC
Created attachment 413066 [details]
File: backtrace

Comment 2 Chris Campbell 2010-06-05 18:24:15 UTC
#2  <signal handler called>
No symbol table info available.
#3  0x00000038cb9329c8 in vtable for RDFXMLDataSourceImpl ()
   from /usr/lib64/xulrunner-1.9.1/libxul.so
No symbol table info available.
#4  0x00000038caf92ab1 in NS_NewRDFXMLDataSource (aResult=0x7fffc0205e28)
    at nsRDFXMLDataSource.cpp:423
        datasource = 0x7fd621735500
        rv = <value optimized out>
#5  0x00000038caf85788 in CreateNewRDFXMLDataSource (
    aOuter=<value optimized out>, aIID=<value optimized out>, aResult=
    0x7fffc0205eb8) at nsRDFModule.cpp:96
        inst = 0x0
        rv = <value optimized out>
#6  0x00000038cb0bff99 in nsComponentManagerImpl::CreateInstance (
    this=<value optimized out>, aClass=<value optimized out>, aDelegate=0x0, 
    aIID=..., aResult=0x7fffc0205eb8) at nsComponentManager.cpp:1601
        entry = <value optimized out>
        factory = 0x7fd62077b840
        rv = <value optimized out>
#7  0x00000038cb0958e0 in nsCreateInstanceByCID::operator() (this=
    0x7fffc0205ed0, aIID=..., aInstancePtr=0x38cb12988c)
    at nsComponentManagerUtils.cpp:199
        status = 0
#8  0x00000038cb09503e in nsCOMPtr_base::assign_from_helper (this=
    0x7fffc0205fa0, helper=..., iid=...) at nsCOMPtr.cpp:150
        newRawPtr = 0x0
#9  0x00000038caf90110 in operator= (this=0x7fd62c1c0e00, 
    aURI=<value optimized out>, aBlock=1, aDataSource=0x7fffc02062c8)
    at ../../../dist/include/xpcom/nsCOMPtr.h:707
No locals.
#10 RDFServiceImpl::GetDataSource (this=0x7fd62c1c0e00, 
    aURI=<value optimized out>, aBlock=1, aDataSource=0x7fffc02062c8)
    at nsRDFService.cpp:1471
        remote = {<nsCOMPtr_base> = {mRawPtr = 
    0x7fd6217e07c0}, <No data fields>}
        rv = <value optimized out>
        spec = {<nsFixedCString> = {<nsCString> = {<nsACString_internal> = {
                mData = 
    0x7fd621898358 "file:///home/sasan/.mozilla/firefox/scq7vq9n.default/extensions.rdf", mLength = 67, mFlags = 65541}, <No data fields>}, mFixedCapacity = 
    63, mFixedBuf = 0x7fffc0206040 ""}, mStorage = 
    "\000\000\000\000\000\000\000\000\333\303@\000\000\000\000\000D\000\000\000\000\000\000\000\333\303@\000\000\000\000\000 \000\000\000\000\000\000\000@@/,\326\177\000\000`\216u \326\177\000\000\314\261\016\004\000\000\000"}
        ds = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}
#11 0x00000038cb0d1071 in NS_InvokeByIndex_P (that=0x7fd62c1c0e00, 
    methodIndex=16, paramCount=2, params=<value optimized out>)
    at xptcinvoke_x86_64_linux.cpp:208
        nr_stack = <value optimized out>
        gpregs = {0, 140557644336992, 140736416735944, 0, 140557662641728, 
    140557662226660}
        d0 = <value optimized out>
        d5 = <value optimized out>
        result = <value optimized out>
        nr_gpr = 3
        d1 = <value optimized out>
        d6 = <value optimized out>
        nr_fpr = 0
        d2 = <value optimized out>
        d7 = <value optimized out>
        methodAddress = Cannot access memory at address 0x0



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

Comment 3 Chris Campbell 2010-06-05 18:26:12 UTC
Reporter, was this a one-time event, or reproducible?



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

Comment 4 Sasan 2010-06-06 05:47:02 UTC
Oh, It is happening alright. I could never use Mozilla again, since then. I even tried to remove the Flash plugin (The one & only plugin that is not in Fedora, and I was using it.) but nothing changed. It still crashes.

Comment 5 Chris Campbell 2010-06-06 13:17:09 UTC
Thank you for taking the time to submit this bug report.

We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue.

First of all, could we get output of the command, saved in a text file and attached to this bug:

 $ rpm -qa *xulrun* *firefox* *mozilla* *flash* *plugin*

Please also install firefox-debuginfo.

 # debuginfo-install firefox

Then run firefox inside the gdb debugger. Please do the following:

 $ firefox -g

Stuff will appear. Ignore this until you get the gdb command prompt, then do:

 (gdb) run

Now, firefox should start up. Use it and reproduce the crash. When firefox crashes, you should be back to the gdb prompt. Now do:

 (gdb) thread apply all back-trace

More screens of stuff will occur. Copy all of this part to your editor of choice, such as gedit, and save it as an uncompressed file and attach it to this bug report.

We will review this issue again once you've had a chance to attach this information.



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

Comment 6 Sasan 2010-06-08 10:16:29 UTC
Created attachment 422132 [details]
installed rpms.

output of the following command 
rpm -qa *xulrun* *firefox* *mozilla* *flash* *plugin*

Comment 7 Sasan 2010-06-08 10:20:35 UTC
Created attachment 422134 [details]
Output of gdb

output of following:
$ firefox -g
(gdb) set logging on
(gdb) run
(gdb) thread apply all backtrace
(gdb) quit

Comment 8 Chris Campbell 2010-06-08 18:05:03 UTC
Passing this on.

This bug has been triaged



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

Comment 9 Martin Stransky 2010-07-15 15:29:22 UTC
Can you try to run firefox in safe mode? (firefox -safe-mode) and check if it crashes?

Comment 10 Sasan 2010-07-15 22:31:32 UTC
(In reply to comment #9)
> Can you try to run firefox in safe mode? (firefox -safe-mode) and check if it
> crashes?    

It didn't come up (as I already mentioned in the bug report description).
However there was an update for firefox and xulrunner some weeks ago which solved this issue. I've totally forgotten about this request.

thank you anyway.

Comment 11 Martin Stransky 2010-07-16 07:37:18 UTC
Okay, thanks.


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