Bug 574203 - [abrt] crash in firefox-3.6.1-1.fc13: Process /usr/lib64/firefox-3.6/firefox was killed by signal 11 (SIGSEGV)
Summary: [abrt] crash in firefox-3.6.1-1.fc13: Process /usr/lib64/firefox-3.6/firefox ...
Keywords:
Status: CLOSED DUPLICATE of bug 543165
Alias: None
Product: Fedora
Classification: Fedora
Component: firefox
Version: rawhide
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Gecko Maintainer
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:570dc1950d64e935b61192644ee...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-16 20:41 UTC by Joel
Modified: 2010-05-08 15:10 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-05-08 15:10:24 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
File: backtrace (34.82 KB, text/plain)
2010-03-16 20:41 UTC, Joel
no flags Details

Description Joel 2010-03-16 20:41:55 UTC
abrt 1.0.8 detected a crash.

architecture: x86_64
Attached file: backtrace
cmdline: /usr/lib64/firefox-3.6/firefox -P default
comment: just  basic usage all day, then closing the browser and telling it to save open tabs.
component: firefox
executable: /usr/lib64/firefox-3.6/firefox
kernel: 2.6.33-1.fc13.x86_64
package: firefox-3.6.1-1.fc13
rating: 4
reason: Process /usr/lib64/firefox-3.6/firefox was killed by signal 11 (SIGSEGV)
release: Fedora release 13 (Rawhide)

How to reproduce
-----
1.Launch firefox and use it all day
2.Close firefox and tell it to save open tabs
3.watch it crash

Comment 1 Joel 2010-03-16 20:41:57 UTC
Created attachment 400566 [details]
File: backtrace

Comment 2 Kurt Driver 2010-03-18 18:04:25 UTC

How to reproduce
-----
1.It did not crash as far as I know of. 
2.
3.


Comment
-----
I was using it as the time and didn't know it had crashed.

Comment 3 Joel 2010-03-18 21:12:32 UTC

How to reproduce
-----
1.Use firefox all day
2.close firefox at the end of the day
3.crash


Comment
-----
nothing special, just seems that firefox crashes semi-consistently when closing

Comment 4 Gene Snider 2010-03-19 19:31:12 UTC

How to reproduce
-----
1.Start firefox with mutlitple tabs open.
2.Close firefox with the close button.
3.


Comment
-----
I started a firefox session with about 10 tabs open.  When I closed the window, this segfault occurred.

Comment 5 Joel 2010-03-19 23:23:04 UTC

How to reproduce
-----
1.Close firefox after a full day of use.
2.
3.


Comment
-----
Closed each tab one at a time, then hit the close button on the top right of the window with the last tab open.

Comment 6 ghostwik 2010-03-20 10:40:32 UTC

How to reproduce
-----
a) "Restart firefox" after updating "noscript" extension
b) "Reboot" with firefox turned on

Comment 7 Joel 2010-03-25 00:01:19 UTC

How to reproduce
-----
1.Use firefox all day
2.Close firefox
3.Boom!


Comment
-----
Nothing special.  Last open window was a nytimes.com article.  Went to close firefox, and it crashed.

Comment 8 Gene Snider 2010-03-25 00:26:54 UTC
Firefox updated to 3.6.2 on F13 today.  So far, no crashes on exit.

Gene

Comment 9 Gene Snider 2010-03-25 17:24:14 UTC
Forget Comment 8, Firefox 3.6.2 on F13 still crashes on closing.

Gene

Comment 10 Gene Snider 2010-04-07 17:56:59 UTC
I'm not sure what fixed this problem, but I haven't seen it for over a week now.  I've been updating kernels as soon as they hit koji, but otherwise I've been getting updates from updates-testing.  Something, perhaps a kernel update, fixed this bug for me.  I think kernel-2.6.33.1-24.fc13.x86_64 or -26 was installed around the time the FF crashes stopped.

Gene

Comment 11 leon Cogs 2010-05-01 22:22:43 UTC
Been having this for a while now abrt says process /usr/lib64/firefox-3.6 killed by signal 11
uname -r
2.6.33.2-57.fc13.x86_64

Comment 12 Chris Campbell 2010-05-08 15:10:03 UTC
#2  <signal handler called>
No symbol table info available.
#3  IA__g_type_check_instance (type_instance=0x7fae9b072780) at gtype.c:4026
        node = <value optimized out>
#4  0x0000003db942004d in IA__g_signal_handlers_disconnect_matched (
    instance=0x7fae9b072780, mask=24, signal_id=0, detail=0, 
    closure=<value optimized out>, func=<value optimized out>, 
    data=0x7fae89ca3400) at gsignal.c:2670
        _g_boolean_var_ = <value optimized out>
        n_handlers = 0
        __PRETTY_FUNCTION__ = "IA__g_signal_handlers_disconnect_matched"
#5  0x00007faeb7bfce83 in update_client_widget (context_xim=0x7fae89ca3400, 
    client_window=<value optimized out>) at gtkimcontextxim.c:1641
        new_client_widget = 0x0
#6  set_ic_client_window (context_xim=0x7fae89ca3400, 
    client_window=<value optimized out>) at gtkimcontextxim.c:654
No locals.
#7  0x00007faeb7bfcf1b in xim_info_display_closed (display=0x7faec9a93190, 
    is_error=<value optimized out>, info=0x7faeb9502ef0)
    at gtkimcontextxim.c:402
        ics = 0x7faeb73c8f00
        tmp_list = 0x7fae8a83bea0
#8  0x0000003db940b94e in IA__g_closure_invoke (closure=0x7faebccdf880, 
    return_value=0x0, n_param_values=2, param_values=0x7fae7a309040, 
    invocation_hint=0x7fff4dec6450) at gclosure.c:767
        marshal = <value optimized out>
        marshal_data = <value optimized out>
        in_marshal = <value optimized out>
        __PRETTY_FUNCTION__ = "IA__g_closure_invoke"
#9  0x0000003db94228e9 in signal_emit_unlocked_R (node=<value optimized out>, 
    detail=<value optimized out>, instance=<value optimized out>, 
    emission_return=<value optimized out>, 
    instance_and_params=<value optimized out>) at gsignal.c:3248
        tmp = <value optimized out>
        handler = 0x7faebccdf850
        accumulator = <value optimized out>
        emission = {next = 0x0, instance = 0x7faec9a93190, ihint = {
            signal_id = 3, detail = 0, run_type = G_SIGNAL_RUN_FIRST}, 
          state = EMISSION_RUN, chain_type = 4}
        class_closure = <value optimized out>
        handler_list = 0x7faebc255a00
        return_accu = <value optimized out>
        accu = {g_type = 0, data = {{v_int = 0, v_uint = 0, v_long = 0, 
              v_ulong = 0, v_int64 = 0, v_uint64 = 0, v_float = 0, 
              v_double = 0, v_pointer = 0x0}, {v_int = 0, v_uint = 0, 
              v_long = 0, v_ulong = 0, v_int64 = 0, v_uint64 = 0, 
              v_float = 0, v_double = 0, v_pointer = 0x0}}}
        signal_id = <value optimized out>
        max_sequential_handler_number = <value optimized out>
        return_value_altered = <value optimized out>



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

Comment 13 Chris Campbell 2010-05-08 15:10:24 UTC
Thank you for taking the time to submit this bug report.

This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.



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

*** This bug has been marked as a duplicate of bug 543165 ***


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