|
Bugzilla – Full Text Bug Listing |
| Summary: | tracker-extract process generating core dumps through udev bad system call to socket() | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Forgotten User CsWSwYFOed <forgotten_CsWSwYFOed> |
| Component: | GNOME | Assignee: | Antonio Larrosa <alarrosa> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | afaerber, ailin.nemui, astieger, cshorler, deaven, dimstar, ecsos, fcrozat, forgotten_CsWSwYFOed, forgotten_EUhkD-ZdS8, forgotten_yIOt4M2AZ2, gboiko, hvdheuvel, jthumshirn, karl, linux, malcolmlewis, meissner, okurz, pkeller, shane.wims, sogal, sreeves, viniciusbrbio, yfjiang, zaitor |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Community User | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
tracker-extract core dump file
New tracker-extract core dump xcf file that lead tracker to crash File that triggers tracker coredump |
||
|
Description
Forgotten User CsWSwYFOed
2016-12-30 19:40:09 UTC
Created attachment 708119 [details]
tracker-extract core dump file
I too am experiencing this bug with the latest Tumbleweed per 2017-01-07, and I *don’t* use GNOME (but I do use tracker). It’s causing heavy disk thrashing and a CPU trending towards overheating (several systemd-coredump process are listed at the top of both ‘htop’ and ‘iotop’, and ‘dmesg’ reports ‘Package temperature above threshold, cpu clock throttled’). And yes, it seems to be related to tracker and gstreamer. ‘ps’ reports processes like root 11731 65.9 0.5 118992 97304 ? R 16:38 0:32 /usr/lib/systemd/systemd-coredump 11674 1000 100 31 1483803497 midiparse0:sink (and ‘midiparse’ seems to be part of gstreamer). Experiencing too this bug. I try to deactivate tracker without success though. I noticed that if I put the computer into sleep mode and waked it up after a few seconds, there is no more core dumps created for the ongoing session (don't know if it's relevant for now). The sad thing is that tracker is only suffering from underlying libs that generally crash. So in any case, we need sample files that tracker tries to extract and fails. Then we can identify the library causing the failure and fix them directly (tracker-extract has some logic built in trying to skip a file if it made the extractor crash three times in a row - so 'generally' speaking, tracker recovers from the issue, ignoring those files) In any case: please provide the files that make the task crash I would normally be happy to provide a file that causes this issue, but in this case the files are Apple iTunes music purchased from the iTunes store. I'm worried that there could be legal issues uploading the music here. I've been periodically checking the core dump files with GDB, and there doesn't seem to be any consistency in which song causes the issue. The core dump that I provided was generated while tracker was trying to process "Sticks and Stones" by moe. The most recent core dump was generated while tracker was trying to process "Come With Me Now" by KONGOS. From the command line, the file command reports that the music files are "ISO Media, Apple iTunes ALAC/AAC-LC (.M4A) Audio" (In reply to Dominique Leuenberger from comment #4) > The sad thing is that tracker is only suffering from underlying libs that > generally crash. > > So in any case, we need sample files that tracker tries to extract and > fails. Then we can identify the library causing the failure and fix them > directly I’ll try to submit a sample file, but I don’t how to find out *which* files make the library crash. (Though I think there are many such files, since tracker-extract generates coredumps *countinously* if I don’t disable it.) I have kept a few coredump files, but they are *huge* (e.g. several hundred MiB each). Are they of any use? How can I inspect them to figure out which file(s) caused the crashes? (In reply to Karl Ove Hufthammer from comment #6) > I’ll try to submit a sample file, but I don’t how to find out *which* files > make the library crash. (Though I think there are many such files, since > tracker-extract generates coredumps *countinously* if I don’t disable it.) > > I have kept a few coredump files, but they are *huge* (e.g. several hundred > MiB each). Are they of any use? How can I inspect them to figure out which > file(s) caused the crashes? Best is to extract a back trace directly on your machine; try with: coredumpctl gdb /usr/lib/tracker-extract then at the (gdb) prompt type "bt full"; if there are mentions of missing -debuginfo packages, please install them and reproduce the coredumpctl gdb command (there should be no '???' in the resulting dump. With this it might be possible to find some clues where it's happening. (In reply to Dominique Leuenberger from comment #7) > Best is to extract a back trace directly on your machine; try with: > > coredumpctl gdb /usr/lib/tracker-extract > > then at the (gdb) prompt type "bt full"; if there are mentions of missing > -debuginfo packages, please install them and reproduce the coredumpctl gdb > command (there should be no '???' in the resulting dump. > > With this it might be possible to find some clues where it's happening. coredumpctl couldn’t find any coredump files, but running gdb manually I managed to extract the information. First, tracker 1.10.4 became available just a moment ago, and that seemed to have cured most of the crashes. But running gdb on the *old* (tracker 1.10.3), I found this: #0 0x00007fabff6e3eb7 in munlock () at /lib64/libc.so.6 #1 0x00007fabbc93611f in delete_fluid_defsfont () at /usr/lib64/libfluidsynth.so.1 #2 0x00007fabbc936256 in fluid_defsfont_sfont_delete () at /usr/lib64/libfluidsynth.so.1 #3 0x00007fabbc94b7d2 in fluid_synth_sfont_unref () at /usr/lib64/libfluidsynth.so.1 #4 0x00007fabbc950ce0 in fluid_synth_sfunload () at /usr/lib64/libfluidsynth.so.1 #5 0x00007fabbcbee271 in () at /usr/lib64/gstreamer-1.0/libgstfluidsynthmidi.so #6 0x00007fabce3ed90e in gst_element_change_state () at /usr/lib64/libgstreamer-1.0.so.0 #7 0x00007fabce3ee07f in () at /usr/lib64/libgstreamer-1.0.so.0 libfluidsynth is a MIDI library, and the crashes seemed to be releated to extracting metadata from MIDI files (.mid files). With the new 1.10.4 version it doesn’t crash on MIDI files (or perhaps it’s just indexed all of them?), but I still get crashes, now on MP3 files, referencing the libmediaart library: #0 0x00007f4b3f6b6e97 in unlink () at /lib64/libc.so.6 #1 0x00007f4b4034af7b in () at /usr/lib64/libmediaart-2.0.so.0 #2 0x00007f4b4034cbf8 in media_art_process_file () at /usr/lib64/libmediaart-2.0.so.0 #3 0x00007f4a80095dc9 in tracker_extract_get_metadata (info=0x7f4b20033e60) at tracker-extract-mp3.c:2584 media_art_process = <optimized out> error = 0x7f4a90437390 Probably related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848842 (In reply to Karl Ove Hufthammer from comment #9) > Probably related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848842 Likely - and that one seems to have sorted with 0.4 The new one for mp3 >#0 0x00007f4b3f6b6e97 in unlink () at /lib64/libc.so.6 >#1 0x00007f4b4034af7b in () at /usr/lib64/libmediaart-2.0.so.0 >#2 0x00007f4b4034cbf8 in media_art_process_file () at /usr/lib64/libmediaart-2.0.so.0 >#3 0x00007f4a80095dc9 in tracker_extract_get_metadata (info=0x7f4b20033e60) > at tracker-extract-mp3.c:2584 > media_art_process = <optimized out> > error = 0x7f4a90437390 That one MIGHT be related to the fix for libmediaart2 we just prepared - possible the mp3 has not ARTIST set? (In reply to Dominique Leuenberger from comment #10) > (In reply to Karl Ove Hufthammer from comment #9) > > Probably related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848842 > > Likely - and that one seems to have sorted with 0.4 On Debian they disabled libmediaart completely, and that doesn’t seem to be done upstream (yet), AFAICS: https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=848842;filename=0001-Disable-libmediaart.patch;msg=41 > >#3 0x00007f4a80095dc9 in tracker_extract_get_metadata (info=0x7f4b20033e60) > > at tracker-extract-mp3.c:2584 > > media_art_process = <optimized out> > > error = 0x7f4a90437390 > > That one MIGHT be related to the fix for libmediaart2 we just prepared - > possible the mp3 has not ARTIST set? The MP3 file *does* have the ARTIST field set. Here’s one of the files that resulted in coredumps on my system: http://static1.squarespace.com/static/50844bb5c4aa1a31c6526430/t/551cc024e4b04e2cba241e28/1427947579776/GoodFortune_ep1.mp3 The culprit/provocateur here is the new seccomp feature of tracker.. I was able to reproduce tracker crashing. Do: tracker reset --hard (will nuke all your tracker settings and indexes) restart daemons (or just log out/in), watch tracker extract crash willy nilly on a multitude of files. ---- I rebuilt tracker without libseccomp br, same tracker reset dance, no coredumps at all. Now the real bug might be inside libmediaart, and the new sandboxing just exposes it, but I guess we need to discuss that with upstream. Hi reporters Could you please grab the tracker(s) that is in my branch, do the tracker reset --hard, reboot just for good measure, and verify that those packages does not crash for you? Grab them this way: 1. make sure you have osc installed 2. osc getbinaries home:Zaitor tracker Factory x86_64 3. If you have tracker-extras installed: osc getbinaries home:Zaitor tracker-extras Factory x86_64 4. Install/update as needed. 6. Report back here :-) Here's a new GDB output for my system with all the debug packages installed:
(gdb) bt
#0 0x00007f4fef626587 in socket () at ../sysdeps/unix/syscall-template.S:84
#1 0x00007f4fe9a83384 in udev_monitor_new_from_netlink_fd (udev=0x7f4fc415cfe0, name=<optimized out>, name@entry=0x7f4feb70efbf "udev", fd=fd@entry=-1) at src/libudev/libudev-monitor.c:207
#2 0x00007f4fe9a8343a in udev_monitor_new_from_netlink (udev=<optimized out>, name=name@entry=0x7f4feb70efbf "udev") at src/libudev/libudev-monitor.c:252
#3 0x00007f4feb70c3a2 in g_udev_client_constructed (object=0x7f4fc4144460 [GUdevClient]) at gudev/gudevclient.c:196
#4 0x00007f4fefe240d7 in g_object_new_internal (class=class@entry=0x7f4fc415ccc0, params=params@entry=0x7f4fd6265390, n_params=n_params@entry=1) at gobject.c:1823
#5 0x00007f4fefe25a6e in g_object_new_valist (object_type=object_type@entry=139980568906672, first_property_name=first_property_name@entry=0x7f4feb70ef7e "subsystems", var_args=var_args@entry=0x7f4fd62654e0)
at gobject.c:2042
#6 0x00007f4fefe25d11 in g_object_new (object_type=object_type@entry=139980568906672, first_property_name=first_property_name@entry=0x7f4feb70ef7e "subsystems") at gobject.c:1626
#7 0x00007f4feb70c537 in g_udev_client_new (subsystems=subsystems@entry=0x7f4fd5859ba0 <subsystems>) at gudev/gudevclient.c:332
#8 0x00007f4fd5646d3a in gst_v4l2_iterator_new () at v4l2-utils.c:51
#9 0x00007f4fd5624a53 in plugin_init (plugin=0x7f4fc4142420 [GstPlugin]) at gstv4l2.c:124
#10 0x00007f4fd5624a53 in plugin_init (plugin=0x7f4fc4142420 [GstPlugin]) at gstv4l2.c:233
#11 0x00007f4fd6cc70f7 in gst_plugin_register_func (plugin=0x7f4fc4142420 [GstPlugin], desc=0x7f4fd5859b00 <gst_plugin_desc>, user_data=0x0) at gstplugin.c:523
#12 0x00007f4fd6cc9068 in _priv_gst_plugin_load_file_for_registry (filename=filename@entry=0x7f4fc414cf60 "/usr/lib64/gstreamer-1.0/libgstvideo4linux2.so", registry=0x6e6f50 [GstRegistry], error=error@entry=0x0) at gstplugin.c:826
#13 0x00007f4fd6cd5c0e in gst_registry_scan_plugin_file (context=context@entry=0x7f4fd6265a70, filename=filename@entry=0x7f4fc414cf60 "/usr/lib64/gstreamer-1.0/libgstvideo4linux2.so", file_size=259088, file_mtime=1481275252) at gstregistry.c:1194
#14 0x00007f4fd6cd6d01 in gst_registry_scan_path_level (context=context@entry=0x7f4fd6265a70, path=path@entry=0x7f4fd6d2f7bc "/usr/lib64/gstreamer-1.0", level=level@entry=10) at gstregistry.c:1352
#15 0x00007f4fd6cd6ed6 in gst_registry_scan_path_internal (context=context@entry=0x7f4fd6265a70, path=path@entry=0x7f4fd6d2f7bc "/usr/lib64/gstreamer-1.0") at gstregistry.c:1379
#16 0x00007f4fd6cd8b24 in gst_update_registry (write_changes=1, error=0x7f4fd6265a68, registry_file=0x7f4fc400fe70 "/home/bwilson30/.cache/gstreamer-1.0/registry.x86_64.bin", default_registry=0x6e6f50 [GstRegistry]) at gstregistry.c:1675
#17 0x00007f4fd6cd8b24 in gst_update_registry (error=0x7f4fd6265a68) at gstregistry.c:1767
#18 0x00007f4fd6cd8b24 in gst_update_registry () at gstregistry.c:1843
#19 0x00007f4fd6c7341e in init_post (context=<optimized out>, group=<optimized out>, data=<optimized out>, error=<optimized out>) at gst.c:716
#20 0x00007f4fefb51998 in g_option_context_parse (context=context@entry=0x7f4fc40089c0, argc=argc@entry=0x0, argv=argv@entry=0x0, error=error@entry=0x7f4fd6265be0) at goption.c:2165
#21 0x00007f4fd6c73def in gst_init_check (argc=0x0, argv=0x0, err=0x7f4fd6265be0) at gst.c:353
#22 0x00007f4fd6c73e44 in gst_init (argc=argc@entry=0x0, argv=argv@entry=0x0) at gst.c:399
#23 0x00007f4fd75fa34b in tracker_extract_gstreamer (uri=uri@entry=0x7f4fc4008af0 "file:///home/bwilson30/Music/Compilations/What%20a%20Girl%20Wants/12%20Rock%20and%20Roll,%20Hootchie%20Koo.m4a", info=info@entry=0x829590, type=type@entry=EXTRACT_MIME_AUDIO) at tracker-extract-gstreamer.c:1341
#24 0x00007f4fd75fbb59 in tracker_extract_get_metadata (info=0x829590) at tracker-extract-gstreamer.c:1470
#25 0x000000000040ba86 in get_file_metadata (task=task@entry=0x7f4fd0004050, info_out=info_out@entry=0x7f4fd6265d10) at tracker-extract.c:326
#26 0x000000000040bb53 in get_metadata (task=0x7f4fd0004050) at tracker-extract.c:510
#27 0x000000000040bbb0 in single_thread_get_metadata (queue=0x82ab40) at tracker-extract.c:538
#28 0x00007f4fefb6d1d5 in g_thread_proxy (data=0x6ce800) at gthread.c:784
#29 0x00007f4fef8e2454 in start_thread (arg=0x7f4fd6266700) at pthread_create.c:333
#30 0x00007f4fef62537f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
(gdb)
It does seem that I'm having a slightly different issue than Karl Ove Hufthammer. Created attachment 712507 [details]
New tracker-extract core dump
After Update from 42.2 to 42.3 i have the same problem. Periodically systemd-coredump with tracker-extract and cpu-load 100% So i have deinstall tracker with dependencies nad now coredump is gone. Entry in Coredump: __CURSOR=s=2ef75d9d72f14676b2ef4fc83de09f11;i=69a21;b=dd796150bc144d14a85291fcf2934267;m=11228b2615;t=554fa31b07068;x=49a0084591164e52 __REALTIME_TIMESTAMP=1500808435757160 __MONOTONIC_TIMESTAMP=73593988629 _BOOT_ID=dd796150bc144d14a85291fcf2934267 _UID=[i have it delete] _GID=[i have it delete] _CAP_EFFECTIVE=0 _SYSTEMD_OWNER_UID=[i have it delete] _SYSTEMD_SLICE=user-[i have it delete].slice _MACHINE_ID=[i have it delete] _HOSTNAME=[i have it delete] PRIORITY=4 _TRANSPORT=stdout _COMM=dbus-daemon _EXE=/bin/dbus-daemon _CMDLINE=/bin/dbus-daemon --fork --print-pid 5 --print-address 15 --session SYSLOG_IDENTIFIER=org.freedesktop.Tracker1.Miner.Extract _SYSTEMD_CGROUP=/user.slice/user-[i have it delete].slice/session-85.scope _SYSTEMD_SESSION=85 _SYSTEMD_UNIT=session-85.scope _PID=15650 MESSAGE=(tracker-extract:19124): Tracker-WARNING **: Could not load module '/usr/lib64/tracker-1.0/extract-modules/libextract-gstreamer.so': /usr/lib64/tracker-1.0/extract-modules/libextract-gstreamer.so: Kann die Shared-Object-Datei nicht öffnen: Datei oder Verzeichnis nicht gefunden Created attachment 738108 [details]
xcf file that lead tracker to crash
I did experienced the same issue after 42.2 to 42.3 Leap upgrade. Symptoms are exactly the same. the first time I've noticed that was on a, correctly tagged (ARTIST tag was set) .ogg file. This morning, it was on a .xcf file (see attached file banniere_01.xcf) with the following output in journalctl : août 24 08:00:02 host systemd-coredump[8143]: Process 8142 (single) of user 1000 dumped core. août 24 08:00:03 host org.freedesktop.Tracker1.Miner.Extract[3790]: (tracker-extract:8168): GStreamer-WARNING **: External plugin loader failed. This most likely means that the plugin loader helper b inary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though. août 24 08:00:03 host systemd-coredump[8144]: Process 8121 (tracker-extract) of user 1000 dumped core. août 24 08:00:06 host systemd-coredump[8165]: Process 8164 (single) of user 1000 dumped core. août 24 08:00:06 host org.freedesktop.Tracker1.Miner.Extract[3790]: (tracker-extract:8234): Tracker-WARNING **: Failed to update ignored file 'file:///home/blabla/path/to/banniere_01.xcf': GDBus.Error:org.freedesktop.Tracker1.SparqlError.Parse: 1.267: syntax error, expected variable or term août 24 08:00:07 host systemd-coredump[8166]: Process 8146 (tracker-extract) of user 1000 dumped core. Regards I have found the same, for the first time this morning. I found the file: it is Licarayén.pnm file (attached). From the gdb output:
#15 0x00007f17d95c0f27 in gst_init () from /usr/lib64/libgstreamer-1.0.so.0
No symbol table info available.
#16 0x00007f17d9f4877d in tracker_extract_gstreamer (
---Type <return> to continue, or q <return> to quit---
uri=uri@entry=0x7f17c8008f00 "file:///home/pete/Documents/Licaray%C3%A9n.pnm", info=info@entry=0x7f17c8009000,
type=type@entry=EXTRACT_MIME_IMAGE, graph=<optimized out>) at tracker-extract-gstreamer.c:1636
metadata = 0x7f17e40119e0
preupdate = 0x7f17e4011960
postupdate = 0x7f17e40119a0
extractor = <optimized out>
buffer = <optimized out>
media_art_process = <optimized out>
#17 0x00007f17d9f4a773 in tracker_extract_get_metadata (info=0x7f17c8009000) at tracker-extract-gstreamer.c:1765
file = <optimized out>
uri = 0x7f17c8008f00 "file:///home/pete/Documents/Licaray%C3%A9n.pnm"
mimetype = 0x7f17c8000970 "image/x-portable-anymap"
#18 0x000000000040bd3e in get_file_metadata (task=task@entry=0x163fc00, info_out=info_out@entry=0x7f17d8bd0d98)
at tracker-extract.c:332
statements = <optimized out>
info = 0x7f17c8009000
file = 0x162ba20
mime_used = 0x7f17c8008e70 "image/x-portable-anymap"
items = 0
success = 0
#19 0x000000000040be55 in get_metadata (task=0x163fc00) at tracker-extract.c:532
info = 0x0
#20 0x000000000040bec0 in single_thread_get_metadata (queue=0x164a4c0) at tracker-extract.c:560
task = <optimized out>
__func__ = "single_thread_get_metadata"
#21 0x00007f180304ba85 in ?? () from /usr/lib64/libglib-2.0.so.0
No symbol table info available.
#22 0x00007f1802dc6744 in start_thread () from /lib64/libpthread.so.0
No symbol table info available.
#23 0x00007f1802b04aad in clone () from /lib64/libc.so.6
No symbol table info available.
Created attachment 738801 [details]
File that triggers tracker coredump
I'm having the same problem in Leap, here you can see my coredumpctl gdb tracker-extract http://susepaste.org/12359644 (In reply to Vinicius B. Rodrigues from comment #23) > I'm having the same problem in Leap, here you can see my coredumpctl gdb > tracker-extract http://susepaste.org/12359644 The new one: http://susepaste.org/12359644 I can also confirm that this is happening in Leap 42.3 but not 42.2 (as far as I've noticed). The files it chooses to not process varies at each startup. I managed to reproduce it on a fresh 42.3 install by simply downloading the attached files and by running `tracker index -f some-incriminated-file` for each if them. What seems to be taking all my CPU is `systemd-coredump` though, and by running coredumpctl I see many instances of tracker-extract and only that. (In reply to Adrien Plazas from comment #27) > What seems to be taking all my CPU is `systemd-coredump` though, and by > running coredumpctl I see many instances of tracker-extract and only that. yes, hence theneed to fix tracker / the libs it used that are crashing (one seems to be libmediaart, which we should likely update to the Version in TW); the 2nd trace crashes in v4l/gst - that might be even nastier I updated Tracker on 42.3 from 1.8.3 to 1.12.3 (the current once on Tumbleweed) and I couldn't reproduce the bug anymore. Would updating Tracker be enough, is it acceptable to do so? (In reply to Adrien Plazas from comment #29) > I updated Tracker on 42.3 from 1.8.3 to 1.12.3 (the current once on > Tumbleweed) and I couldn't reproduce the bug anymore. Would updating Tracker > be enough, is it acceptable to do so? > lookup423 ^tracker: tracker: SUSE:SLE-12-SP3:GA Good luck :) I produced a patch which seems to work just fine for me: https://build.opensuse.org/package/show/home:aplazas:branches:openSUSE:Leap:42.3:Update/tracker Feel free to double-check it before I submit it. (In reply to Adrien Plazas from comment #31) > I produced a patch which seems to work just fine for me: > https://build.opensuse.org/package/show/home:aplazas:branches:openSUSE:Leap: > 42.3:Update/tracker > > Feel free to double-check it before I submit it. Hi Just an observation, I re-installed 42.3 and unable to duplicate without the ~/Music directory (and others) as softlinks to a separate partition/folder when copying in mp3's. These are just the default directories in my ~/. I also note that it doesn't occur on SLES/SLED 12 SP3 (with the same softlinks and files) as this does not included the grilo-plugin-tracker package. (In reply to Adrien Plazas from comment #31) > I produced a patch which seems to work just fine for me: > https://build.opensuse.org/package/show/home:aplazas:branches:openSUSE:Leap: > 42.3:Update/tracker > > Feel free to double-check it before I submit it. I've tested your above "tracker" package, and it appears to fix crashes on 42.3. If there's no other problems with it, please submit it. This is an autogenerated message for OBS integration: This bug (1017652) was mentioned in https://build.opensuse.org/request/show/532678 42.3 / tracker (In reply to Dominique Leuenberger from comment #30) > > lookup423 ^tracker: > tracker: SUSE:SLE-12-SP3:GA > > Good luck :) What is that supposed to mean? The fix is currently submitted to SLE maintenance. Please contact maintenance for any prioritization. > https://build.opensuse.org/request/show/532678 42.3 / tracker I have declined it for Leap maintenance at this point in expectation of a SLE maintenance update. If something else is required, please reopen the request and clearly indicate so. I also am experiencing this issue, however on LEAP 42.3 that was upgraded from 42.2. I see the same stack trace to SIGSYS in socket() from libudev. One new piece of information that I did not see reported by others in this thread - if I invoke the gnome-control-center, even without the GUI, (e.g. "gnome-control-center -l"), then tracker-extract immediately behaves and does not crash any longer. (In reply to Andreas Stieger from comment #35) > (In reply to Dominique Leuenberger from comment #30) > > > lookup423 ^tracker: > > tracker: SUSE:SLE-12-SP3:GA > > > > Good luck :) > > What is that supposed to mean? The way I read that is that Adrien was asking if we could do a version update and Dominique pointed out that tracker comes from SLE where it's much harder to do that instead of backporting the patch. > The fix is currently submitted to SLE maintenance. Please contact > maintenance for any prioritization. > > > https://build.opensuse.org/request/show/532678 42.3 / tracker > > I have declined it for Leap maintenance at this point in expectation of a > SLE maintenance update. If something else is required, please reopen the > request and clearly indicate so. Adrien - it looks like you forgot to run pre_checkin.sh so the tracker and tracker-extras spec files don't match (patch2 is missing). In this case I don't think it makes any difference but we want to keep the spec files in sync. Could you resubmit this to Devel:Desktop. (In reply to Scott Reeves from comment #37) > > The fix is currently submitted to SLE maintenance. Please contact > > maintenance for any prioritization. > > > > > https://build.opensuse.org/request/show/532678 42.3 / tracker > > > > I have declined it for Leap maintenance at this point in expectation of a > > SLE maintenance update. If something else is required, please reopen the > > request and clearly indicate so. > > Adrien - it looks like you forgot to run pre_checkin.sh so the tracker and > tracker-extras spec files don't match (patch2 is missing). In this case I > don't think it makes any difference but we want to keep the spec files in > sync. Could you resubmit this to Devel:Desktop. Good catch! It's fixed and merged on Devel:Desktop:SLE12:SP3. any update here? this is gravely affecting the usability of my openSUSE Leap 42.3 (In reply to Ailin Nemui from comment #43) > any update here? this is gravely affecting the usability of my openSUSE Leap > 42.3 (gdb) bt #0 0x00007fab10e93ab7 in symlink () at /lib64/libc.so.6 #1 0x00007fab11b23c52 in media_art_process_file () at /usr/lib64/libmediaart-2.0.so.0 #2 0x00007faae8a19381 in tracker_extract_get_metadata (info=0x7faae00095e0) at tracker-extract-mp3.c:2714 #3 0x000000000040bc9e in get_file_metadata (task=task@entry=0x24a1700, info_out=info_out@entry=0x7faae8a11d98) at tracker-extract.c:332 #4 0x000000000040bdb5 in get_metadata (task=0x24a1700) at tracker-extract.c:532 #5 0x000000000040be20 in single_thread_get_metadata (queue=0x24a1ee0) at tracker-extract.c:560 #6 0x00007fab113e3a85 in () at /usr/lib64/libglib-2.0.so.0 #7 0x00007fab1115e724 in start_thread () at /lib64/libpthread.so.0 #8 0x00007fab10e9ec1d in clone () at /lib64/libc.so.6 (In reply to Ailin Nemui from comment #43) > any update here? this is gravely affecting the usability of my openSUSE Leap > 42.3 I agree: it is really annoying that this patch is taking so long to appear. I hope that we aren't going to have to wait until openSUSE 15 to get it. I guess that the problem is that relatively few people happen to have files that trigger the bug, so backporting it into 42.3 isn't seen as a priority. I only see this for one user on one machine myself. A mitigation is to execute the command 'tracker daemon -k' after logging in, but that is hardly a fix. (In reply to Ailin Nemui from comment #43) > any update here? this is gravely affecting the usability of my openSUSE Leap > 42.3 I agree: it is really annoying that this patch is taking so long to appear. I hope that we aren't going to have to wait until openSUSE 15 to get it. I guess that the problem is that relatively few people happen to have files that trigger the bug, so backporting it into 42.3 isn't seen as a priority. I only see this for one user on one machine myself. A mitigation is to execute the command 'tracker daemon -k' after logging in, but that is hardly a fix. P.S. Am I right in thinking that I am the only person who has voted for this bug? If more people voted for it, that might help. (In reply to Andreas Stieger from comment #35) > (In reply to Dominique Leuenberger from comment #30) > > > https://build.opensuse.org/request/show/532678 42.3 / tracker > I tried to test this and it didn't seem to fix the problem, still crashing (In reply to Peter Keller from comment #46) > I agree: it is really annoying that this patch is taking so long to appear. > I hope that we aren't going to have to wait until openSUSE 15 to get it. I > guess that the problem is that relatively few people happen to have files > that trigger the bug, so backporting it into 42.3 isn't seen as a priority. > I only see this for one user on one machine myself. It will be released once the fix has been verified. So far this is not the case, see comment #47. > P.S. Am I right in thinking that I am the only person who has voted for this > bug? If more people voted for it, that might help. Not really. The determining factor would be for a fix to be available. In this case, via SLE maintenance which will then quickly be imported into Leap updates. (In reply to Andreas Stieger from comment #48) > It will be released once the fix has been verified. So far this is not the > case, see comment #47. Antonio - can you help diagnose comment #47 Problem is the same as the original report (V4L2 plugin) - Using the "fixed" package here (the request built package didn't appear to exist any longer, but I verified the patch content in the debugsource): https://download.opensuse.org/repositories/home:/ailin_nemui:/branches:/home:/aplazas:/branches:/openSUSE:/Leap:/42.3:/Update/standard/ also - looking at what that patch is doing, and the point of failure: (gdb) frame 1 #1 0x00007f734ec8af04 in udev_monitor_new_from_netlink_fd (udev=0x7f7328214e70, name=<optimized out>, name@entry=0x7f7350229edf "udev", fd=fd@entry=-1) at src/libudev/libudev-monitor.c:207 207 udev_monitor->sock = socket(PF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT); I'd say the problem is the patch doesn't allow for AF_NETLINK, but then reading this thread, and not really knowing what AF_NETLINK can do - other than what I've read today... is it safe to add it, and am I correct? https://bugzilla.gnome.org/show_bug.cgi?id=764786#c10 backtrace / gdb output chorler@linux-wbv3:~> coredumpctl gdb /usr/lib/tracker-extract PID: 6385 (tracker-extract) UID: 1000 (chorler) GID: 100 (users) Signal: 31 (SYS) Timestamp: Sat 2018-02-17 19:17:03 GMT (1 day 2h ago) Command Line: /usr/lib/tracker-extract Executable: /usr/lib/tracker-extract Control Group: / Slice: -.slice Boot ID: aba719befd134eaeb86fd667f368d472 Machine ID: 3c4618fbaec463f597ee3ced59e9e9ff Hostname: linux-wbv3 Coredump: /var/lib/systemd/coredump/core.tracker-extract.1000.aba719befd134eaeb86fd667f368d472.6385.1518895023000000.xz Message: Process 6385 (tracker-extract) of user 1000 dumped core. GNU gdb (GDB; openSUSE Leap 42.3) 8.0.1 Copyright (C) 2017 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-suse-linux". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://bugs.opensuse.org/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/lib/tracker-extract...Reading symbols from /usr/lib/debug/usr/lib/tracker-extract.debug...done. done. [New LWP 6402] [New LWP 6389] [New LWP 6387] [New LWP 6386] [New LWP 6390] [New LWP 6391] [New LWP 6392] [New LWP 6393] [New LWP 6394] [New LWP 6395] [New LWP 6396] [New LWP 6397] [New LWP 6398] [New LWP 6388] [New LWP 6400] [New LWP 6385] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/lib/tracker-extract'. Program terminated with signal SIGSYS, Bad system call. #0 0x00007f7353e08d97 in socket () at ../sysdeps/unix/syscall-template.S:84 84 ../sysdeps/unix/syscall-template.S: No such file or directory. [Current thread is 1 (Thread 0x7f7332c8e700 (LWP 6402))] (gdb) bt #0 0x00007f7353e08d97 in socket () at ../sysdeps/unix/syscall-template.S:84 #1 0x00007f734ec8af04 in udev_monitor_new_from_netlink_fd (udev=0x7f7328214e70, name=<optimized out>, name@entry=0x7f7350229edf "udev", fd=fd@entry=-1) at src/libudev/libudev-monitor.c:207 #2 0x00007f734ec8afba in udev_monitor_new_from_netlink (udev=<optimized out>, name=name@entry=0x7f7350229edf "udev") at src/libudev/libudev-monitor.c:253 #3 0x00007f7350227362 in g_udev_client_constructed (object=0x7f73281ff1a0) at gudev/gudevclient.c:196 #4 0x00007f7354601982 in g_object_new_internal (class=class@entry=0x7f7328214b00, params=params@entry=0x7f7332c8d260, n_params=1) at gobject.c:1821 #5 0x00007f7354603814 in g_object_new_valist (object_type=object_type@entry=140132571236848, first_property_name=first_property_name@entry=0x7f7350229e9e "subsystems", var_args=var_args@entry=0x7f7332c8d3b8) at gobject.c:2040 #6 0x00007f7354603bf4 in g_object_new (object_type=object_type@entry=140132571236848, first_property_name=first_property_name@entry=0x7f7350229e9e "subsystems") at gobject.c:1624 #7 0x00007f73502274f7 in g_udev_client_new (subsystems=subsystems@entry=0x7f733248dba0 <subsystems>) at gudev/gudevclient.c:332 #8 0x00007f733227caca in gst_v4l2_iterator_new () at v4l2-utils.c:51 #9 0x00007f733225aaf4 in gst_v4l2_probe_and_register (plugin=0x7f7328153e70) at gstv4l2.c:123 #10 plugin_init (plugin=0x7f7328153e70) at gstv4l2.c:228 #11 0x00007f73336ccff3 in gst_plugin_register_func (plugin=0x7f7328153e70, desc=0x7f733248db00 <gst_plugin_desc>, user_data=0x0) at gstplugin.c:523 #12 0x00007f73336cee04 in _priv_gst_plugin_load_file_for_registry ( filename=filename@entry=0x7f7328209e30 "/usr/lib64/gstreamer-1.0/libgstvideo4linux2.so", registry=0x1774750, error=error@entry=0x0) at gstplugin.c:826 #13 0x00007f73336db796 in gst_registry_scan_plugin_file (context=context@entry=0x7f7332c8da30, filename=filename@entry=0x7f7328209e30 "/usr/lib64/gstreamer-1.0/libgstvideo4linux2.so", file_size=250896, file_mtime=1496003829) at gstregistry.c:1180 #14 0x00007f73336dc8ef in gst_registry_scan_path_level (context=context@entry=0x7f7332c8da30, path=path@entry=0x7f7333731a3c "/usr/lib64/gstreamer-1.0", level=level@entry=10) at gstregistry.c:1338 #15 0x00007f73336dcafb in gst_registry_scan_path_internal (context=context@entry=0x7f7332c8da30, path=path@entry=0x7f7333731a3c "/usr/lib64/gstreamer-1.0") at gstregistry.c:1365 #16 0x00007f73336de54c in scan_and_update_registry (write_changes=1, error=0x7f7332c8da28, registry_file=0x7f732802cd30 "/home/chorler/.cache/gstreamer-1.0/registry.x86_64.bin", default_registry=0x1774750) at gstregistry.c:1660 #17 ensure_current_registry (error=0x7f7332c8da28) at gstregistry.c:1752 #18 gst_update_registry () at gstregistry.c:1828 #19 0x00007f733367d545 in init_post (context=<optimized out>, group=<optimized out>, data=<optimized out>, error=<optimized out>) at gst.c:720 #20 0x00007f7354332a78 in g_option_context_parse (context=context@entry=0x7f7328009280, argc=argc@entry=0x0, argv=argv@entry=0x0, error=error@entry=0x7f7332c8dbf8) at goption.c:2159 #21 0x00007f733367dedf in gst_init_check (argc=argc@entry=0x0, argv=argv@entry=0x0, err=err@entry=0x7f7332c8dbf8) at gst.c:354 #22 0x00007f733367df27 in gst_init (argc=argc@entry=0x0, argv=argv@entry=0x0) at gst.c:400 #23 0x00007f733809e74d in tracker_extract_gstreamer (uri=uri@entry=0x7f7328009240 "file:///home/chorler/Videos/screen1.mkv", info=info@entry=0x7f732c005140, type=type@entry=EXTRACT_MIME_VIDEO, graph=<optimized out>) at tracker-extract-gstreamer.c:1636 #24 0x00007f73380a071b in tracker_extract_get_metadata (info=0x7f732c005140) at tracker-extract-gstreamer.c:1763 #25 0x000000000040bc9e in get_file_metadata (task=task@entry=0x7f73340086a0, info_out=info_out@entry=0x7f7332c8dd98) at tracker-extract.c:332 #26 0x000000000040bdb5 in get_metadata (task=0x7f73340086a0) at tracker-extract.c:532 #27 0x000000000040be20 in single_thread_get_metadata (queue=0x1786150) at tracker-extract.c:560 #28 0x00007f735434ca85 in g_thread_proxy (data=0x7f7344003e30) at gthread.c:780 #29 0x00007f73540c7724 in start_thread (arg=0x7f7332c8e700) at pthread_create.c:457 #30 0x00007f7353e07c1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 also, that call is in systemd in this branch the gstv4l2 plugin issue disappears https://build.opensuse.org/repositories/home:chorler:branches:REQUEST_532678 - the "cost" is bind, setsockopt, AF_NETLINK socket / (and possibly not necessary socketpair) ... it then crashes in execve when attempting to launch gst-plugin-scanner (just added execve to the above to test if that is the "last" problem) My feeling is proceeding like this we're undoing the intent of the security model implemented in tracker. On the otherhand, if the rest of the system is incompatible with that... I'd say either a way to disable plugins is required, or a more permissive approach is required. no more crashes on my system after adding execve I would guess the gst-plugin-scanner can be disabled by passing "--gst-disable-registry-fork" to gst_init() this works for me: https://download.opensuse.org/repositories/home:/chorler:/branches:/REQUEST_532678/standard changes: allow setsockopt and bind allow socket for AF_NETLINK pass "--gst-disable-registry-fork" to gst_init + https://build.opensuse.org/request/show/532678 tested via $ tracker daemon -k $ tracker reset $ tracker daemon -s in parallel watching coredumpctl for new crashes (none observed) I think this is the minimum possible change please can other people test? (built for 42.3) This is an autogenerated message for OBS integration: This bug (1017652) was mentioned in https://build.opensuse.org/request/show/579654 42.3 / tracker This is an autogenerated message for OBS integration: This bug (1017652) was mentioned in https://build.opensuse.org/request/show/579781 42.3 / tracker.home_aplazas_branches_openSUSE_Leap_42.3_Update https://build.opensuse.org/request/show/579783 42.3 / tracker.home_aplazas_branches_openSUSE_Leap_42.3_Update https://build.opensuse.org/request/show/579784 42.3 / tracker.home_aplazas_branches_openSUSE_Leap_42.3_Update This is an autogenerated message for OBS integration: This bug (1017652) was mentioned in https://build.opensuse.org/request/show/579795 42.3 / tracker.home_aplazas_branches_openSUSE_Leap_42.3_Update This is an autogenerated message for OBS integration: This bug (1017652) was mentioned in https://build.opensuse.org/request/show/579798 42.3 / tracker https://build.opensuse.org/request/show/579800 42.3 / tracker https://build.opensuse.org/request/show/579801 42.3 / tracker openSUSE-RU-2019:1238-1: An update that has two recommended fixes can now be installed. Category: recommended (low) Bug References: 1017652,1038829 CVE References: Sources used: openSUSE Leap 42.3 (src): tracker-1.8.3-2.3.1, tracker-extras-1.8.3-2.3.1 (In reply to Swamp Workflow Management from comment #63) > openSUSE-RU-2019:1238-1: An update that has two recommended fixes can now be > installed. > > Category: recommended (low) > Bug References: 1017652,1038829 > CVE References: > Sources used: > openSUSE Leap 42.3 (src): tracker-1.8.3-2.3.1, tracker-extras-1.8.3-2.3.1 That actually all seems released - and from what I get from the feedbacks, they were helping at the time |