Created attachment 755562 [details]
File: backtrace

Created attachment 755563 [details]
File: cgroup

Created attachment 755564 [details]
File: core_backtrace

Created attachment 755565 [details]
File: dso_list

Created attachment 755566 [details]
File: environ

Created attachment 755567 [details]
File: limits

Created attachment 755568 [details]
File: maps

Created attachment 755569 [details]
File: open_fds

Created attachment 755570 [details]
File: proc_pid_status

Created attachment 755571 [details]
File: var_log_messages

Created attachment 755572 [details]
File: xsession_errors

I don't understand why this bug was closed for insufficient data. I see no indication that the users encountering this bug were ever asked to provide any additional data. What is it that you need to know? This crash just happened to me.

(In reply to Jonathan Kamens from comment #12)
> I don't understand why this bug was closed for insufficient data. I see no
> indication that the users encountering this bug were ever asked to provide
> any additional data. What is it that you need to know? This crash just
> happened to me.

No steps to reproduce = closed bug

Why should we have to ask as it takes valuable time?

I had rhythmbox playing. I turned the volume. I clicked on the little musical note icon in my panel and used the slider on the pop-up to turn the volume down to 0%. When I tried to turn the volume back up a few seconds later, Cinnamon crashed.

Sorry. I misspoke in the previous I meant to say:

I had rhythmbox playing. I clicked on the little musical note icon in my panel and used the slider on the pop-up to turn the volume down to 0%. When I tried to turn the volume back up a few seconds later, Cinnamon crashed.

(In reply to Jonathan Kamens from comment #15)
> ... Cinnamon crashed.

Could you be more specific?
What did you see?
Could you move the pointer?
Did you get an abrt notification?

If you can reboot, try starting abrt and seeing if you have any crash dumps.

(In reply to Steve Tyler from comment #16)
> (In reply to Jonathan Kamens from comment #15)
> > ... Cinnamon crashed.
> 
> Could you be more specific?

Cinnamon crashed. Abrt told me about it. I reported the issue with Abrt. It claimed that the issue I was reporting was the same as this one we're currently discussing and therefore didn't open a new issue about it.

> What did you see?

I'm not sure what more detail you are looking for. Cinnamon crashed and restarted and Abrt told me about the crash and asked if I wanted to report it. Is there some more detail than that you're looking for me to provide?

The crash dump is gone by now; alas, things crash often enough in Fedora that crashes don't stay around for long before they get reaped because they're taking up too much space.

But as I said, Abrt though the crash I saw was the same as this one.

I suppose that looking at the back trace and other information uploaded by Abrt to try to figure out what might have gone wrong, like for example I did recently for bug 986612 which is about a package I don't even maintain, is too much trouble for Leigh Scott.

I am currently unable to reproduce the issue. But of course the fact that such issues are often intermittent is exactly why we have Abrt to report them and provide as much information as possible to increase the likelihood that the package maintainers might be able to figure out what's going wrong.

Thanks, Jonathan. That's exactly what I needed to know.

Normally, abrt will create a new comment for a duplicate and add the reporter to the CC list. I don't why that didn't happen here -- maybe because this bug is closed.

In the future, if your abrt bug report is detected as a duplicate, feel free to attach a backtrace, anyway. Sometimes dupes are not entirely identical ...

Superficially, it looks like cinnamon is aborting on an assertion failure in gtkicontheme.c due to a missing file or directory.

Jonathan: Do you know what icon theme you are using? Default?

This may not be a cinnamon bug:
Bug 954702 - [faf] gnome-shell-3.7.4.1-1.fc19.x86_64 SIGABRT in proxy_symbolic_pixbuf_destroy 

That has a link to a very similar backtrace on the retrace server:
https://retrace.fedoraproject.org/faf/problems/230486/

Snippet from attached backtrace:
...
Core was generated by `cinnamon --replace'.
...
56	../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
...
#2  0x00000034e646bc66 in g_assertion_message (domain=domain@entry=0x34f8d07d28 "Gtk", file=file@entry=0x34f8d2f0e2 "gtkicontheme.c", line=line@entry=3734, func=func@entry=0x34f8d2faf0 <__PRETTY_FUNCTION__.36218> "proxy_symbolic_pixbuf_destroy", message=<optimized out>) at gtestutils.c:1912
        lstr = "3734\000\177\000\000\300\032\324\354\377\177\000\000\320z\023\003\000\000\000\000\305\361\322\370\064\000\000"
        s = 0x3f346a0 ""
#3  0x00000034e646bcc4 in g_assertion_message_expr (domain=domain@entry=0x34f8d07d28 "Gtk", file=file@entry=0x34f8d2f0e2 "gtkicontheme.c", line=line@entry=3734, 
...

(In reply to Steve Tyler from comment #19)
> Jonathan: Do you know what icon theme you are using? Default?

To my knowledge, I have never changed my icon theme, but it's a very old system that has been upgraded many times, so it's possible that whatever icon theme is configured was the default once and is no more. If there is more information I can pull from my system somewhere to help debug this, let me know and I will dig it up.

Well, I'm not going to debug this -- that is what the developers get paid the big bucks to do ... :-)

For the record, could you post the versions you are using? The original report shows an older version of cinnamon (1.8.6-2):
$ rpm -qa cinnamon gtk3 kernel rhythmbox | sort

Here are two suggestions:
1. Create a new user account and use that instead. That should create new, default config files.
2. Better yet, do a clean install. Fedora suffers from bit rot if it gets upgraded too many times -- from old config files, for example. If you have /home on a separate partition or LV that is fairly easy to do.

==
$ sudo repoquery cinnamon --requires | grep gtk
libgtk-3.so.0()(64bit)

$ sudo repoquery cinnamon gtk3 kernel rhythmbox --archlist=x86_64
cinnamon-0:1.9.1-16.fc19.x86_64
gtk3-0:3.8.2-2.fc19.x86_64
kernel-0:3.9.9-302.fc19.x86_64
rhythmbox-0:2.99.1-1.fc19.x86_64

Here is the line in the gtk3 code where the assertion failure is occurring:
   3734   g_assert (symbolic_cache != NULL);

From the attached backtrace:
        symbolic_cache = 0x0

gtk+-3.8.2 source is here:
http://ftp.gnome.org/pub/gnome/sources/gtk+/3.8/

==
$ less -N gtk+-3.8.2/gtk/gtkicontheme.c
...
   3718 static void
   3719 proxy_symbolic_pixbuf_destroy (guchar *pixels, gpointer data)
   3720 {
   3721   GtkIconInfo *icon_info = data;
   3722   GtkIconTheme *icon_theme = icon_info->in_cache;
   3723   SymbolicPixbufCache *symbolic_cache;
   3724 
   3725   for (symbolic_cache = icon_info->symbolic_pixbuf_cache;
   3726        symbolic_cache != NULL;
   3727        symbolic_cache = symbolic_cache->next)
   3728     {
   3729       if (symbolic_cache->proxy_pixbuf != NULL &&
   3730           gdk_pixbuf_get_pixels (symbolic_cache->proxy_pixbuf) == pixels)
   3731         break;
   3732     }
   3733 
   3734   g_assert (symbolic_cache != NULL);
   3735   g_assert (symbolic_cache->proxy_pixbuf != NULL);
   3736 
   3737   symbolic_cache->proxy_pixbuf = NULL;
   3738 
   3739   /* Keep it alive a bit longer */
   3740   if (icon_theme != NULL)
   3741     ensure_in_lru_cache (icon_theme, icon_info);
   3742 
   3743   g_object_unref (icon_info);
   3744 }
...

You can also open a bug upstream against gtk referring to this one:
https://bugzilla.gnome.org/

(In reply to Steve Tyler from comment #18)
...
> Normally, abrt will create a new comment for a duplicate and add the
> reporter to the CC list. I don't why that didn't happen here -- maybe
> because this bug is closed.
...

Confirmed. I submitted a duplicate for an unrelated, closed bug and no new comment was created.

Leigh: Could you please reopen this bug? People are obviously still hitting it, and you have AMPLE data to triage it correctly.

BTW: You might want to look at this thread:
Subject: What does one do about a package maintainer with an attitude problem?
http://thread.gmane.org/gmane.linux.redhat.fedora.testers/107795

(In reply to Steve Tyler from comment #24)
> (In reply to Steve Tyler from comment #18)

> Leigh: Could you please reopen this bug? People are obviously still hitting
> it, and you have AMPLE data to triage it correctly.
> 

I will re-open it but don't expect me to fix it as I'm busy with cinnamon-2.0 .
As far F19 cinnamon don't expect me to prioritize a minor (only two reporters) bug like this.
F19 cinnamon is basically a dead end development wise as cinnamon-2.0 is going to forks of gjs, gnome-session, control-center, gnome-settings-daemon and gnome-screensaver.

> BTW: You might want to look at this thread:
> Subject: What does one do about a package maintainer with an attitude
> problem?
> http://thread.gmane.org/gmane.linux.redhat.fedora.testers/107795

You love to shit stir :-(

FYI my sponsor is Rex Dieter (rdieter).

(In reply to leigh scott from comment #25)
> I will re-open it but don't expect me to fix it as I'm busy with
> cinnamon-2.0 .

Not all open bugs get fixed. The question of whether a bug should remain open is almost entirely orthogonal to whether the maintainer intends, at this time, to fix it. There are numerous reasons for this, but the most obvious one in this case is...

> As far F19 cinnamon don't expect me to prioritize a minor (only two
> reporters) bug like this.

...that you actually have no idea how many people this bug is affecting, because you closed it, and ABRT doesn't add people to closed bugs.

> You love to shit stir :-(

Indeed. I'm sorry. I have a major beef with how you're handling your bugs, but I was hoping to find out how to address that in an appropriate way, without any public shaming. I thought I made that clear when I started the thread, and while most people respected it, a couple of people took it upon themselves to unnecessarily reveal details which I had explicitly and intentionally omitted. I should have anticipated that not everyone could be relied upon to understand that not all information which can be revealed, should be revealed. Again, I'm sorry.

(In reply to leigh scott from comment #25)
...
> I will re-open it but don't expect me to fix it as I'm busy with
> cinnamon-2.0 .
...

Thanks for reopening. You don't need to fix it. This is a gtk3 bug (Comment 22). You can change the component to gtk3 yourself.

...
> FYI my sponsor is Rex Dieter (rdieter).
...

Rex: I am CCing you, because the handling of this bug raises several issues:
1. How to triage a bug using a backtrace.
2. How to solicit more information from reporters using the NEEDINFO flag.
3. How to explain bug status changes to reporters and commenters.
4. How to deal with a large number of bug reports.
5. What language is appropriate to use in bug report comments.

Flagging with a "needinfo" from Jonathan ...

Jonathan: Could you post the versions of these packages that you had installed when cinnamon crashed?

$ rpm -qa cinnamon gtk3 kernel rhythmbox | sort

Developers need the versions to know what version to debug and to be able to say whether a bug has been fixed in a later version.

For future reference, it is more efficient for everyone, if you put the versions at the end of the comment where you are reporting your steps to reproduce, so they are all reported together.

(In reply to Steve Tyler from comment #28)
> Jonathan: Could you post the versions of these packages that you had
> installed when cinnamon crashed?
> 
> $ rpm -qa cinnamon gtk3 kernel rhythmbox | sort

cinnamon-1.9.1-16.fc19.x86_64
gtk3-3.8.2-2.fc19.x86_64
kernel-3.9.9-302.fc19.x86_64
rhythmbox-2.99.1-1.fc19.x86_64

Thanks, Jonathan. That is helpful, because it shows you have the latest packages:

$ sudo repoquery --arch=x86_64 cinnamon gtk3 kernel rhythmbox
cinnamon-0:1.9.1-16.fc19.x86_64
gtk3-0:3.8.2-2.fc19.x86_64
kernel-0:3.9.9-302.fc19.x86_64
rhythmbox-0:2.99.1-1.fc19.x86_64

*** Bug 989105 has been marked as a duplicate of this bug. ***

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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 19 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.