Bug 1200559

Created attachment 1000141 [details]
File: backtrace

Created attachment 1000142 [details]
File: cgroup

Created attachment 1000143 [details]
File: core_backtrace

Created attachment 1000144 [details]
File: dso_list

Created attachment 1000147 [details]
File: environ

Created attachment 1000149 [details]
File: limits

Created attachment 1000150 [details]
File: maps

Created attachment 1000151 [details]
File: open_fds

Created attachment 1000153 [details]
File: proc_pid_status

Created attachment 1000154 [details]
File: var_log_messages

Occurs when I try find codec in Software.

This happens I run totem without any other parameter from console or try to run it from Activities. When I run totem with some video as argument it runs correctly (even though it segfaults after it's closed).

I tested this with clean installation of F22 Workstation Live Beta RC3.

I propose this as final blocker because it violates final criterion: "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."

Discussed at today's blocker review meeting [1].

This bug was accepted as Final Blocker - clear violation of criterion "All applications that can be launched using the standard graphical mechanism of a release-blocking desktop after a default installation of that desktop must start successfully and withstand a basic functionality test."

[1] http://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-20/

Discussed at the 2015-04-28 blocker review meeting.[1]

Bastien, any news on this?

[1]: http://meetbot.fedoraproject.org/fedora-blocker-review/2015-04-28/

It's a known bug in Tracker, offering audio files as videos. It's existed in Fedora 21 as well, and the crash is dependent on the user's files.

See the upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=730028

Please do not close release blocker bugs without actually fixing the bug, it messes up tracking. Release blocker bugs *must* remain open until fixed.

It is 'dependent on the user's files' indeed, but multiple testers (including myself) have confirmed that on F22, one 'user files' configuration that triggers the bug is *no* files (or, 'whatever files are there out of the box') - if you do a clean install of F22 and try to launch totem, it crashes.

(In reply to Adam Williamson from comment #16)
> if you do a clean install of F22 and try to launch
> totem, it crashes.

It doesn't using the current Beta (Beta 3, from Fedora-Live-Workstation-x86_64-22_Beta-3.iso).

https://bugzilla.gnome.org/show_bug.cgi?id=730028#c19 contains a command to run to unbreak it. I don't plan on making any changes related to this, as the bug has existed in grilo-plugins' Tracker plugin for 3 GNOME releases, and 1 (very soon 2) Fedora releases.

Better remove it from the blockers.

I can reproduce this as well. I am running F22 with latest updates from updates-testing, originally installed from Fedora-Live-Workstation-x86_64-22_Beta-3.iso.

$ tracker sparql -q "SELECT  ?url WHERE { ?x a nfo:Video . ?x a nfo:Image . ?x nie:url ?url }"
Results:
  None

$ totem

(totem:2294): GLib-GObject-WARNING **: The property GtkCellRendererPixbuf:follow-state is deprecated and shouldn't be used anymore. It will be removed in a future version.

... <snip> ...

(totem:2294): GLib-GObject-WARNING **: The property SoupSession:ssl-ca-file is deprecated and shouldn't be used anymore. It will be removed in a future version.

(totem:2294): Gdk-ERROR **: The program 'totem' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 694 error_code 8 request_code 72 (core protocol) minor_code 0)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the GDK_SYNCHRONIZE environment
   variable to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Trace/breakpoint trap (core dumped)

It looks like abrt has been messing with us here. The 'dupes' of this bug from testers running clean installs are likely not the same as the original bug at all: that BadMatch error is something different.

Running totem or Maps from a fresh live instance in a KVM or with LIBGL_ALWAYS_SOFTWARE=1 seems to always crash with a BadMatch error; with hardware accel it works. I've repurposed https://bugzilla.redhat.com/show_bug.cgi?id=1206960 to cover that.  This one we can set back to CLOSED UPSTREAM and remove as a blocker.