Version-Release number of selected component: strawberry-1.0.18-1.fc38 Additional info: reporter: libreport-2.17.11 type: CCpp reason: strawberry killed by SIGSEGV journald_cursor: s=924a50fff1d040049bf1ff431a0c1579;i=3a7474;b=4b7ba36e2ce14a4eb48ab688805dbca3;m=be932f9b7;t=6029fdecc41b7;x=7e4557a042b5d782 executable: /usr/bin/strawberry cmdline: /usr/bin/strawberry cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-gnome-org.strawberrymusicplayer.strawberry-221313.scope rootdir: / uid: 1000 kernel: 6.4.7-200.fc38.x86_64 package: strawberry-1.0.18-1.fc38 runlevel: N 5 backtrace_rating: 4 crash_function: getenv Truncated backtrace: Thread no. 1 (11 frames) #0 getenv at getenv.c:84 #1 guess_category_value at dcigettext.c:1573 #2 __dcigettext at dcigettext.c:647 #3 __dcgettext at dcgettext.c:47 #4 g_dgettext at ../glib/ggettext.c:404 #5 _priv_gst_tag_initialize at ../gst/gsttaglist.c:217 #6 init_post at ../gst/gst.c:781 #8 g_option_context_parse at ../glib/goption.c:2219 #9 gst_init_check at ../gst/gst.c:420 #10 gst_init at ../gst/gst.c:459 #11 GstStartup::InitializeGStreamer at /usr/src/debug/strawberry-1.0.18-1.fc38.x86_64/src/engine/gststartup.cpp:80
Created attachment 1982913 [details] File: proc_pid_status
Created attachment 1982914 [details] File: maps
Created attachment 1982915 [details] File: limits
Created attachment 1982916 [details] File: environ
Created attachment 1982917 [details] File: open_fds
Created attachment 1982918 [details] File: mountinfo
Created attachment 1982919 [details] File: os_info
Created attachment 1982920 [details] File: cpuinfo
Created attachment 1982921 [details] File: core_backtrace
Created attachment 1982922 [details] File: exploitable
Created attachment 1982923 [details] File: dso_list
Created attachment 1982924 [details] File: var_log_messages
Created attachment 1982925 [details] File: backtrace
This looks like a glibc related crash (getenv), maybe a rebuild has fixed it. Unless this is still an issue still in the latest Fedora / strawberry version, this can probably be closed.
It seems to be still happening: https://retrace.fedoraproject.org/faf/problems/bthash/?bth=5c04bf59e2f17a9522fb7d67430b12c211d8c0c1&bth=85e69ce88e0a6a3ed069459bb47e34583db75863&bth=fe089c4f0059f7e86b70bf17d915055a7fa2babf&bth=63b415729a721d2a06fbfa13082ce0ae2f3887c9 But indeed it's probably not a bug in strawberry. Reassigning to glibc, maybe the maintainers will know more...
Looks like something corrupted the environ vector, perhaps by calling setenv in a multi-threaded program. Without more data, it is impossible to tell whether this is a glibc bug. Is there a way to reproduce the crash reliably?
I can't reproduce it on openSUSE, and I've never seen this crash occur before now, not heard of it from any other distro either. gst_init is what's calling setenv(). Strawberry call's gst_init() in a another thread to avoid blocking the GUI on startup, this is something that is inherited from Clementine dating back to 2010 (https://github.com/clementine-player/Clementine/commit/75b70b4acb1749a9b91d5219b0de8855e3ff7347) (even though much of the gst code in strawberry is rewritten). As far as I know this should be safe, I found this: http://www.eel.is/c++draft/support.runtime.general#2 However, if it's not safe, we should call gst_init() directly from the main thread, it's not a big deal anyway, gst_init() takes like 10ms when testing here.
> gst_init is what's calling setenv(). Strawberry call's gst_init() in a I mean getenv().
Passing this back to strawberry. We don't see any indication that this is a glibc bug with getenv() or setenv(). We expect this is an application bug related to environ corruption. This needs to be debugged at the application layer.
Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.