Bug 1126094 - Infinite loop in gnome-mines
Summary: Infinite loop in gnome-mines
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-mines
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
low
Target Milestone: ---
Assignee: Yanko Kaneti
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-01 20:53 UTC by Stuart D Gathman
Modified: 2015-06-29 21:54 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-29 21:54:02 UTC


Attachments (Terms of Use)
Screenshot of hung/looping mines (151.66 KB, image/png)
2014-08-01 20:53 UTC, Stuart D Gathman
no flags Details
coredump tarball for gnome-mines loop (1.26 MB, application/x-gzip)
2014-08-06 22:45 UTC, Stuart D Gathman
no flags Details
thread apply all bt full (14.67 KB, text/plain)
2014-08-16 18:03 UTC, Stuart D Gathman
no flags Details
running thread (4.52 KB, text/plain)
2014-08-16 21:07 UTC, Stuart D Gathman
no flags Details

Description Stuart D Gathman 2014-08-01 20:53:04 UTC
Created attachment 923418 [details]
Screenshot of hung/looping mines

Description of problem:
infinite during game play

Version-Release number of selected component (if applicable):
gnome-mines-3.10.1-1.fc20.i686

How reproducible:
rarely

Steps to Reproduce:
1. play game
2. rarely, infinite loop results - screenshot attached
3.

Actual results:
screen freezes with 100% CPU after clicking on square

Expected results:
normal play

Additional info:
Yes, I could'a, should'a, would'a gotten a core dump with kill -6.  But I didn't.  I'll try to remember next time.  If there is a next time.  I did get a screenshot.

Comment 1 Stuart D Gathman 2014-08-01 20:56:08 UTC
Notice the empty square at the upper right.  That is where I had just clicked.  (50/50 of hitting a mine, but might as well find out right away.)

Comment 2 Michael Catanzaro 2014-08-01 22:54:02 UTC
(In reply to Stuart D Gathman from comment #0)
> Yes, I could'a, should'a, would'a gotten a core dump with kill -6.  But I
> didn't.  I'll try to remember next time.  If there is a next time.  I did
> get a screenshot.

Yeah, if this happens again, could you please post that core dump: that would be super.

Comment 3 Stuart D Gathman 2014-08-06 22:45:37 UTC
Created attachment 924639 [details]
coredump tarball for gnome-mines loop

What do you know!  It looped again.

This is the tarball abrt sent to backtrace server.

Comment 4 Stuart D Gathman 2014-08-06 22:49:55 UTC
This time I forgot the screenshot.  Sigh.

Comment 5 Michael Catanzaro 2014-08-07 01:14:34 UTC
Aaah I have a x86-64 machine so I can't do anything with the coredump as-is; could you please get a stack trace from it and post the stack trace? You can follow the instructions at [1] if you don't know how to do this. Thanks!

A link to the ABRT server report might suffice, but the full backtrace would be better.

[1] https://wiki.gnome.org/Community/GettingInTouch/Bugzilla/GettingTraces/Details#gdb-core-dump

Comment 6 Michael Catanzaro 2014-08-07 01:17:42 UTC
[1] doesn't mention it, but the command I'd like you to run inside gdb is 'bt full'. Run this on the 25.5 MB coredump in that folder:

gdb gnome-mines coredump
bt full

Comment 7 Stuart D Gathman 2014-08-13 01:26:08 UTC
(gdb) bt full
#0  _int_free (av=0xb6c07420 <main_arena>, p=0x903c1a0, have_lock=0)
    at malloc.c:3843
        idx = 2
        fd = <optimized out>
        old = <optimized out>
        old_idx = <optimized out>
        size = <optimized out>
        fb = <optimized out>
        nextchunk = <optimized out>
        nextsize = <optimized out>
        nextinuse = <optimized out>
        prevsize = <optimized out>
        bck = <optimized out>
        fwd = <optimized out>
        errstr = 0x0
        locked = 0
#1  0xb6c93e18 in INT_cairo_region_destroy (region=region@entry=0x903c1a8)
    at cairo-region.c:430
No locals.
#2  0xb71b9d77 in gdk_window_invalidate_maybe_recurse_full (window=0x8ef42f8, 
    region=<optimized out>, child_func=0xb71af8d0 <true_predicate>, 
    user_data=0x0) at gdkwindow.c:3931
        visible_region = 0x903c1a8
        r = {x = 0, y = 0, width = 906, height = 553}
---Type <return> to continue, or q <return> to quit--- 
        __PRETTY_FUNCTION__ = "gdk_window_invalidate_maybe_recurse_full"
#3  0xb71bcecd in gdk_window_invalidate_maybe_recurse (window=<optimized out>, 
    window@entry=0x8ef42f8, region=<optimized out>, region@entry=0x90c8460, 
    child_func=child_func@entry=0xb71af8d0 <true_predicate>, 
    user_data=user_data@entry=0x0) at gdkwindow.c:3965
No locals.
#4  0xb71bcf11 in gdk_window_invalidate_region (window=0x8ef42f8, 
    region=region@entry=0x90c8460, 
    invalidate_children=invalidate_children@entry=1) at gdkwindow.c:4016
No locals.
#5  0xb753fd22 in gtk_widget_real_queue_draw_region (widget=0x9008a08, 
    region=0x90c8460) at gtkwidget.c:5080
        priv = <optimized out>
#6  0xb75444a9 in gtk_widget_queue_draw_region (widget=widget@entry=0x9008a08, 
    region=region@entry=0x90c8460) at gtkwidget.c:5117
        w = 0x0
        __PRETTY_FUNCTION__ = "gtk_widget_queue_draw_region"
#7  0xb754457a in gtk_widget_queue_draw_area (widget=0x9008a08, x=799, y=15, 
    width=101, height=21) at gtkwidget.c:5155
        rect = {x = 799, y = 15, width = 101, height = 21}
        region = 0x90c8460
#8  0xb754dd84 in gtk_widget_queue_draw (widget=widget@entry=0x9008a08)
    at gtkwidget.c:5176
        rect = {x = 799, y = 15, width = 101, height = 21}
---Type <return> to continue, or q <return> to quit---
        __PRETTY_FUNCTION__ = "gtk_widget_queue_draw"
#9  0xb754dfc8 in gtk_widget_queue_resize (widget=widget@entry=0x9008a08)
    at gtkwidget.c:5204
No locals.
#10 0xb73d9468 in gtk_label_recalculate (label=label@entry=0x9008a08)
    at gtklabel.c:2125
        priv = 0x9008938
        keyval = 16777215
#11 0xb73da15d in gtk_label_set_text (label=label@entry=0x9008a08, 
    str=str@entry=0x90d6948 "Time: 00:04:43") at gtklabel.c:2150
        __PRETTY_FUNCTION__ = "gtk_label_set_text"
#12 0x0804ddbd in mines_tick_cb (self=<optimized out>) at gnome-mines.c:2297
        elapsed = <optimized out>
        _tmp0_ = <optimized out>
        hours = <optimized out>
        _tmp4_ = <optimized out>
        minutes = 4
        _tmp5_ = <optimized out>
        seconds = 43
        _tmp6_ = <optimized out>
        _tmp7_ = 0x9008a08
        _tmp8_ = <optimized out>
        _tmp9_ = 0x90d6948 "Time: 00:04:43"
        _tmp10_ = 0x90d6948 "Time: 00:04:43"
---Type <return> to continue, or q <return> to quit---
        __PRETTY_FUNCTION__ = "mines_tick_cb"
#13 0xb6ea44d3 in g_cclosure_marshal_VOID__VOID (closure=0x9066970, 
    return_value=0x0, n_param_values=1, param_values=0xbf9ac0c0, 
    invocation_hint=0xbf9ac068, marshal_data=0x0) at gmarshal.c:85
        callback = <optimized out>
        cc = 0x9066970
        data1 = 0x9039e18
        data2 = <optimized out>
        __PRETTY_FUNCTION__ = "g_cclosure_marshal_VOID__VOID"
#14 0xb6ea27de in g_closure_invoke (closure=0x9066970, 
    return_value=return_value@entry=0x0, n_param_values=1, 
    param_values=param_values@entry=0xbf9ac0c0, 
    invocation_hint=invocation_hint@entry=0xbf9ac068) at gclosure.c:777
        marshal = 0x804c920 <g_cclosure_marshal_VOID__VOID@plt>
        marshal_data = 0x0
        in_marshal = 0
        real_closure = 0x9066960
        __PRETTY_FUNCTION__ = "g_closure_invoke"
#15 0xb6eb556e in signal_emit_unlocked_R (node=node@entry=0x90cf580, 
    detail=detail@entry=0, instance=0x9039e18, 
    emission_return=emission_return@entry=0x0, instance_and_params=0xbf9ac0c0)
    at gsignal.c:3586
        tmp = <optimized out>
        handler = 0x903b020
---Type <return> to continue, or q <return> to quit---
        accumulator = 0x0
        emission = {next = 0x0, instance = 0x9039e18, ihint = {
            signal_id = 278, detail = 0, run_type = G_SIGNAL_RUN_FIRST}, 
          state = EMISSION_RUN, chain_type = 4}
        handler_list = 0x903b020
        return_accu = 0x0
        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 = 278
        max_sequential_handler_number = 2782
        return_value_altered = 0
#16 0xb6ebd3c1 in g_signal_emit_valist (instance=instance@entry=0x9039e18, 
    signal_id=signal_id@entry=278, detail=detail@entry=0, 
    var_args=var_args@entry=0xbf9ac288 "\340M\005\b\030\236\003\t K\005\b")
    at gsignal.c:3330
        instance_and_params = 0xbf9ac0c0
        signal_return_type = <optimized out>
        param_values = 0xbf9ac0d4
        node = <optimized out>
        i = <optimized out>
        n_params = <optimized out>
---Type <return> to continue, or q <return> to quit---
        __PRETTY_FUNCTION__ = "g_signal_emit_valist"
        __FUNCTION__ = "g_signal_emit_valist"
#17 0xb6ebdb81 in g_signal_emit_by_name (instance=instance@entry=0x9039e18, 
    detailed_signal=detailed_signal@entry=0x805c0ef "tick") at gsignal.c:3426
        var_args = 0xbf9ac288 "\340M\005\b\030\236\003\t K\005\b"
        detail = 0
        signal_id = 278
        itype = 196
        __PRETTY_FUNCTION__ = "g_signal_emit_by_name"
#18 0x08054da4 in minefield_timeout_cb (self=0x9039e18) at minefield.c:1733
        elapsed = <optimized out>
        _tmp0_ = <optimized out>
        _tmp1_ = <optimized out>
        next = <optimized out>
        wait = <optimized out>
        _tmp2_ = <optimized out>
#19 0xb6dad262 in g_timeout_dispatch (source=source@entry=0x901af18, 
    callback=0x8054de0 <_minefield_timeout_cb_gsource_func>, 
    user_data=0x9039e18) at gmain.c:4451
        timeout_source = 0x901af18
        again = <optimized out>
#20 0xb6dac556 in g_main_dispatch (context=0x8ee1490) at gmain.c:3066
        dispatch = 0xb6dad240 <g_timeout_dispatch>
        was_in_call = 0
---Type <return> to continue, or q <return> to quit---
        user_data = 0x9039e18
        callback = 0x8054de0 <_minefield_timeout_cb_gsource_func>
        cb_funcs = 0xb6e944bc <g_source_callback_funcs>
        cb_data = <optimized out>
        need_destroy = <optimized out>
        current_source_link = {data = 0x901af18, next = 0x0}
        source = 0x901af18
        current = 0x8f00b18
        i = 28
#21 g_main_context_dispatch (context=context@entry=0x8ee1490) at gmain.c:3642
No locals.
#22 0xb6dac920 in g_main_context_iterate (context=context@entry=0x8ee1490, 
    block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>)
    at gmain.c:3713
        max_priority = 0
        timeout = 0
        some_ready = 1
        nfds = <optimized out>
        allocated_nfds = <optimized out>
        fds = <optimized out>
#23 0xb6dac9e9 in g_main_context_iteration (context=0x8ee1490, 
    context@entry=0x0, may_block=may_block@entry=1) at gmain.c:3774
        retval = <optimized out>
#24 0xb6fae7ac in g_application_run (application=application@entry=0x9006108, 
---Type <return> to continue, or q <return> to quit---
    argc=argc@entry=0, argv=argv@entry=0x0) at gapplication.c:1635
        arguments = 0x8f69230
        status = 0
        i = <optimized out>
        __PRETTY_FUNCTION__ = "g_application_run"
#25 0x08051c27 in mines_main (args=args@entry=0xbf9ac4f4, 
    args_length1=args_length1@entry=1) at gnome-mines.c:2914
        result = 0
        context = 0x8ec6248
        _tmp0_ = 0x8ec6248
        _tmp1_ = 0x8ec6248
        _tmp2_ = 0x8ec6248
        _tmp3_ = <optimized out>
        app = 0x9006108
        _tmp8_ = 0x9006108
        _tmp9_ = 0x9006108
        _tmp10_ = 0
        _inner_error_ = 0x0
#26 0x0804cf11 in main (argc=1, argv=0xbf9ac4f4) at gnome-mines.c:2924
No locals.

Comment 8 Michael Catanzaro 2014-08-13 02:45:09 UTC
Seems unlikely that we're looping in that thread. :/  'thread apply all bt full' might help; I should have asked for that the first time. (But to be honest, this looks bleak. :(

If you have a GNOME Bugzilla account, you can CC yourself on https://bugzilla.gnome.org/show_bug.cgi?id=734700

Comment 9 Stuart D Gathman 2014-08-16 18:03:24 UTC
Created attachment 927355 [details]
thread apply all bt full

That thread is the only one running.  The others are sitting on poll().  I'm pretty sure the game was about show me I had clicked on a mine, and the loop is in gtk, or perhaps free space is corrupted and loop is in free().  When it happens again, we'll see if it is looping in the same place.

Comment 10 Stuart D Gathman 2014-08-16 21:07:40 UTC
Created attachment 927378 [details]
running thread

Here is another dump of the loop.  There was only one running thread.  The rest were at poll().

Comment 11 Fedora End Of Life 2015-05-29 12:32:31 UTC
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 12 Fedora End Of Life 2015-06-29 21:54:02 UTC
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


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