Bug 1461878 - crash in gst_plugin_loader_try_helper (@ gstpluginloader.c:431 of gst-plugin-scanner)
crash in gst_plugin_loader_try_helper (@ gstpluginloader.c:431 of gst-plugin-...
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gstreamer1 (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: rc
: ---
Assigned To: Wim Taymans
Desktop QE
Depends On:
  Show dependency treegraph
Reported: 2017-06-15 10:00 EDT by Matěj Cepl
Modified: 2018-06-20 22:35 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
backtrace (abrt fails to do anything for me) (5.83 KB, text/plain)
2017-06-15 10:00 EDT, Matěj Cepl
no flags Details

  None (edit)
Description Matěj Cepl 2017-06-15 10:00:26 EDT
Created attachment 1288081 [details]
backtrace (abrt fails to do anything for me)

Description of problem:
When I start new gnome-session I quite often get few core dumps in my $HOME. They are all (according to file core.*) from /usr/libexec/tracker-extract, but when looking at the backtrace, it seems the crash itself is in gst-plugin-scanner run from inside tracker-extract.

I have no idea what's is the cause of this by wtay suggested that switch to using g_spawn_async_with_pipes may be the culprit.

Version-Release number of selected component (if applicable):

How reproducible:
there is usually a streak (three to five or something like that) of coredumps after  start of new gnome-session (evidently as tracker rechecks content of the followed directories), then it ceases to happen until tracker is rerun.

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