Created attachment 1875542 [details] journal Description of problem: Because of 2079654,I have to scroll down to find a video,but totem crashed everytime. Version-Release number of selected component (if applicable): totem-42.0-1.fc36.x86_64 gnome-shell-42.0-3.fc36.x86_64 How reproducible: always Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 1875544 [details] screencast
Proposed as a Blocker for 36-final by Fedora user lnie using the blocker tracking app because: https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality
Created attachment 1875545 [details] backtrace unable to report this bug using Abrt,it is claiming low-information
I cannot reproduce this problem in a virtual machine where scrolling and playing videos work normally. Totem keeps crashing on my bare metal with Nvidia card and no Videos can be played, but this is a different story connected to the specific hardware and I am going to report it separately.
Please note you need to search first(or just open the search bar) and then try to scroll down to find the video,I can reproduce this every time,even on bare metal.
Created attachment 1875718 [details] better backtrace I was actually able to reproduce this on my system. coredumpctl provided a more useful backtrace, attached.
Also note I get these two errors on the console when running totem on console and hitting the bug: (totem:291313): GLib-GObject-CRITICAL **: 08:53:15.333: g_param_values_cmp: assertion 'G_IS_VALUE (value1)' failed (totem:291313): GLib-GObject-CRITICAL **: 08:53:15.333: g_param_values_cmp: assertion 'G_IS_VALUE (value1)' failed
From the backtrace it looks like the problem is that, when totem-grilo.c `get_search_options` does this: grl_source_get_caps (GRL_SOURCE (self->search_source), GRL_OP_SEARCH), the source it uses - `GRL_SOURCE (self->search_source)` - is coming out as NULL. Not sure why that would be. We seem to be on the path where `search_more` is called from the `adjustment_value_changed_cb` callback. `self->search_source` is set at the start of `search`, and there's another callback - `source_removed_cb` - which can do `self->search_source = NULL;`. So I guess the two possibilities are that the `adjustment_value_changed_cb` callback can get called before `search` has set `self->search_source` at all, or that it can get called after the `source_removed_cb` has been called and decided to set it back to NULL?
In today's Go/No-Go meeting, we agreed to reject this as a blocker but grant a freeze exception. This bug falls outside "basic functionality" but is worth fixing if possible. https://meetbot.fedoraproject.org/fedora-meeting/2022-04-28/f36-final-go_no_go-meeting.2022-04-28-17.01.log.html#l-579
(In reply to Adam Williamson from comment #8) > From the backtrace it looks like the problem is that, when totem-grilo.c > `get_search_options` does this: > > grl_source_get_caps (GRL_SOURCE (self->search_source), GRL_OP_SEARCH), > > the source it uses - `GRL_SOURCE (self->search_source)` - is coming out as > NULL. Not sure why that would be. > > We seem to be on the path where `search_more` is called from the > `adjustment_value_changed_cb` callback. `self->search_source` is set at the > start of `search`, and there's another callback - `source_removed_cb` - > which can do `self->search_source = NULL;`. So I guess the two possibilities > are that the `adjustment_value_changed_cb` callback can get called before > `search` has set `self->search_source` at all, or that it can get called > after the `source_removed_cb` has been called and decided to set it back to > NULL? Going from what I remember, without looking at the code, it's likely that the fact that a search wasn't already performed before the "scroll more" signal was received was the problem. I'm absolutely positive that this problem probably exists since the redesign that took place in around 2013, so not a new bug.
(In reply to Bastien Nocera from comment #10) > I'm absolutely positive that this problem probably exists since the redesign > that took place in around 2013, so not a new bug. Bug was there since 2014. Fixed upstream in https://gitlab.gnome.org/GNOME/totem/-/merge_requests/277