|
Bugzilla – Full Text Bug Listing |
| Summary: | Clementine always crashing | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Michael Hirmke <opensuse> |
| Component: | Other | Assignee: | Dave Plater <davejplater> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | EtherealTouch, jonaski, opensuse |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | SUSE Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
Clementine.conf
log from clementine gdb session log from latest clementine gdb session log from latest clementine gdb session with breakpoint dmidecode output |
||
|
Description
Michael Hirmke
2019-06-10 17:39:01 UTC
Assigned to davejplater@gmail.com as suggested in the mailing list. Because qt4 is about to be dropped, I use the qt5 branch of clementine from git and apply patches from the main branch and update when these patches are merged. The last update was 4 June. Please make sure your system is Tumbleweed 20190607 (In reply to Dave Plater from comment #2) > Because qt4 is about to be dropped, I use the qt5 branch of clementine from > git and apply patches from the main branch and update when these patches are > merged. > The last update was 4 June. > Please make sure your system is Tumbleweed 20190607 I installed clementine-qt5 1.3.1.698.g36cc5b82f. It is still crashing, though: KCrash: Application 'clementine' crashing... KCrash: Attempting to start /usr/lib64/libexec/drkonqi from kdeinit pa_write() failed while trying to wake up the mainloop: Bad file descriptor pa_write() failed while trying to wake up the mainloop: Bad file descriptor pa_write() failed while trying to wake up the mainloop: Bad file descriptor Invalid write to eventfd: Bad file descriptor Code should not be reached at pulsecore/fdsem.c:199, function pa_fdsem_post(). Aborting. Unable to start Dr. Konqi Re-raising signal for core dump handling. (In reply to Michael Hirmke from comment #3) > (In reply to Dave Plater from comment #2) > > Because qt4 is about to be dropped, I use the qt5 branch of clementine from > > git and apply patches from the main branch and update when these patches are > > merged. > > The last update was 4 June. > > Please make sure your system is Tumbleweed 20190607 > > I installed clementine-qt5 1.3.1.698.g36cc5b82f. > It is still crashing, though: > > KCrash: Application 'clementine' crashing... > KCrash: Attempting to start /usr/lib64/libexec/drkonqi from kdeinit > pa_write() failed while trying to wake up the mainloop: Bad file descriptor > pa_write() failed while trying to wake up the mainloop: Bad file descriptor > pa_write() failed while trying to wake up the mainloop: Bad file descriptor > Invalid write to eventfd: Bad file descriptor > Code should not be reached at pulsecore/fdsem.c:199, function > pa_fdsem_post(). Aborting. > Unable to start Dr. Konqi > Re-raising signal for core dump handling. You misunderstood, clementine from Tumbleweed is the from the qt5 branch of clementine git with patches from the main branch. I'm busy testing clementine-131+git20190423-2.1 after a zypper dup to the latest Tumbleweed. I don't recognize clementine-qt5 1.3.1.698.g36cc5b82f and it is definitely not supported. When you have installed the correct clementine run it in konsole then copy and post the screen information when it crashes. I misunderstood that, you're right. Is there a ready to install rom somewhere or do I have to compile it myself? TIA! (In reply to Michael Hirmke from comment #5) > I misunderstood that, you're right. > Is there a ready to install rom somewhere or do I have to compile it myself? > TIA! rpm, sry (In reply to Michael Hirmke from comment #6) > (In reply to Michael Hirmke from comment #5) > > I misunderstood that, you're right. > > Is there a ready to install rom somewhere or do I have to compile it myself? > > TIA! > > rpm, sry Do you use plain rpm to install things? You need to use zypper at least or yast2 gui. execute: "zypper ref" "zypper -v in -f --from http://download.opensuse.org/tumbleweed/repo/oss/ clementine gstreamer-plugins-base gstreamer-plugins-libav" The above commands will make sure that clementine and gstreamer-plugins-base come from the correct repository and gstreamer-plugins-libav will make sure that you only need the ffmpeg libs libavcodec58 and friends from Packman although mp3's are supported by official openSUSE libavcodec. Tumbleweed needs to be updated frequently when you install new software. Clementine has been playing non stop for 3+ hours so far. I can't reproduce the crash, will leave it on overnight. You need to run clementine from the command line and post the output when it crashes. I installed clementine-1.3.1+git20190423-2.1.x86_64 from Tumbleweed OSS, as you suggested. But this is the same version, I had installed before, I believe. Because it also crashed, I installed clementine-qt5. Ok, I just started clementine now - lets see, how long it runs :) Crashed again, but with additional error messages:
KCrash: Application 'clementine' crashing...
KCrash: Attempting to start /usr/lib64/libexec/drkonqi from kdeinit
=================================================================
==9617==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f08af7fc24f in operator new(unsigned long) (/usr/lib64/libasan.so.5+0x10c24f)
#1 0x5614c623e913 in TagReader::TagReader() (/usr/bin/clementine-tagreader+0x7b913)
#2 0x7f08ae9d7f67 in __new_exitfn_called (/lib64/libc.so.6+0x1c2f67)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s).
=================================================================
==9613==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7fd24b20824f in operator new(unsigned long) (/usr/lib64/libasan.so.5+0x10c24f)
#1 0x56154a965913 in TagReader::TagReader() (/usr/bin/clementine-tagreader+0x7b913)
#2 0x7fd24a3e3f67 in __new_exitfn_called (/lib64/libc.so.6+0x1c2f67)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s).
=================================================================
==9616==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7fc8f054d24f in operator new(unsigned long) (/usr/lib64/libasan.so.5+0x10c24f)
#1 0x55ab7e5b5913 in TagReader::TagReader() (/usr/bin/clementine-tagreader+0x7b913)
#2 0x7fc8ef728f67 in __new_exitfn_called (/lib64/libc.so.6+0x1c2f67)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s).
=================================================================
==9615==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f0b5c4e524f in operator new(unsigned long) (/usr/lib64/libasan.so.5+0x10c24f)
#1 0x5651426cf913 in TagReader::TagReader() (/usr/bin/clementine-tagreader+0x7b913)
#2 0x7f0b5b6c0f67 in __new_exitfn_called (/lib64/libc.so.6+0x1c2f67)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s).
=================================================================
==9618==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7fb35c15124f in operator new(unsigned long) (/usr/lib64/libasan.so.5+0x10c24f)
#1 0x5593386c3913 in TagReader::TagReader() (/usr/bin/clementine-tagreader+0x7b913)
#2 0x7fb35b32cf67 in __new_exitfn_called (/lib64/libc.so.6+0x1c2f67)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s).
=================================================================
=================================================================
==9614==ERROR: LeakSanitizer: detected memory leaks
==9612==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8 byte(s) in 1 object(s) allocated from:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f8fd484b24f in operator new(unsigned long) (/usr/lib64/libasan.so.5+0x10c24f)
#0 0x7f60086d524f in operator new(unsigned long) (/usr/lib64/libasan.so.5+0x10c24f)
#1 0x5645bf3ff913 in TagReader::TagReader() (/usr/bin/clementine-tagreader+0x7b913)
#1 0x556fba0e0913 in TagReader::TagReader() (/usr/bin/clementine-tagreader+0x7b913)
#2 0x7f8fd3a26f67 in __new_exitfn_called (/lib64/libc.so.6+0x1c2f67)
#2 0x7f60078b0f67 in __new_exitfn_called (/lib64/libc.so.6+0x1c2f67)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s).
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s).
=================================================================
==9619==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f00dd76124f in operator new(unsigned long) (/usr/lib64/libasan.so.5+0x10c24f)
#1 0x55a620275913 in TagReader::TagReader() (/usr/bin/clementine-tagreader+0x7b913)
#2 0x7f00dc93cf67 in __new_exitfn_called (/lib64/libc.so.6+0x1c2f67)
SUMMARY: AddressSanitizer: 8 byte(s) leaked in 1 allocation(s).
pa_write() failed while trying to wake up the mainloop: Bad file descriptor
pa_write() failed while trying to wake up the mainloop: Bad file descriptor
pa_write() failed while trying to wake up the mainloop: Bad file descriptor
Invalid write to eventfd: Bad file descriptor
Code should not be reached at pulsecore/fdsem.c:199, function pa_fdsem_post(). Aborting.
Unable to start Dr. Konqi
Re-raising signal for core dump handling.
The LeakSanitizer messages confirm that you now have the latest version installed, you can ignore them. Please post the output of "zypper se -si pulse" zypper se -si pulse Loading repository data... Reading installed packages... S | Name | Type | Version | Arch | Repository ---+-----------------------------+---------+-------------+--------+--------------------- i+ | alsa-plugins-pulse | package | 1.1.9-1.2 | x86_64 | (System Packages) i+ | alsa-plugins-pulse-32bit | package | 1.1.9-1.1 | x86_64 | (System Packages) i+ | libpulse-devel | package | 12.2-5.3 | x86_64 | (System Packages) i+ | libpulse-mainloop-glib0 | package | 12.2-5.3 | x86_64 | (System Packages) i+ | libpulse0 | package | 12.2-5.3 | x86_64 | (System Packages) i+ | libpulse0-32bit | package | 12.2-5.2 | x86_64 | (System Packages) i+ | libxine2-pulse | package | 1.2.9-149.4 | x86_64 | packman - Tumbleweed i+ | mpg123-pulse | package | 1.25.10-2.3 | x86_64 | (System Packages) i+ | pulseaudio | package | 12.2-5.3 | x86_64 | (System Packages) i+ | pulseaudio-esound-compat | package | 12.2-5.3 | x86_64 | (System Packages) i+ | pulseaudio-lang | package | 12.2-5.3 | noarch | (System Packages) i+ | pulseaudio-module-bluetooth | package | 12.2-5.3 | x86_64 | (System Packages) i+ | pulseaudio-module-gsettings | package | 12.2-5.3 | x86_64 | (System Packages) i+ | pulseaudio-module-jack | package | 12.2-5.3 | x86_64 | (System Packages) i+ | pulseaudio-module-lirc | package | 12.2-5.3 | x86_64 | (System Packages) i+ | pulseaudio-module-x11 | package | 12.2-5.3 | x86_64 | (System Packages) i+ | pulseaudio-module-zeroconf | package | 12.2-5.3 | x86_64 | (System Packages) i+ | pulseaudio-utils | package | 12.2-5.3 | x86_64 | (System Packages) i+ | pulseaudio-utils-32bit | package | 12.2-5.2 | x86_64 | (System Packages) Maybe it's a configuration difference, the "save statistics in file tags when possible" feature puts a strain on the computer but although I can't use it on my Leap:15.1 machine the Tumbleweed laptop doesn't crash with it enabled. Can you attach ~/.config/Clementine/Clementine.conf and ~/.config/Clementine/Clementine.db Have you tried another music player, you could install nulloy and see if you get the same error, the error you get comes from a routine that isn't called by clementine but internally by pulseaudio. I run qmmp, VLC, Amarok and a few other players regularily. None of them is crashing. Created attachment 807679 [details]
Clementine.conf
clemetine.db is way too big to attach it here, i.e. ~ 50 MB. I see you have both "Save ratings in file tags when possible" and "Save statistics in file tags when possible" checked, maybe I can get my machine to crash with both enabled. The quickest way to fix this is supply the gdb backtrace. From: https://download.opensuse.org/repositories/home:/plater/Tumbleweed install clementine, clementine-debugsource, clementine-debuginfo, pulseaudio-debugsource, pulseaudio-debuginfo, libpulse0 and libpulse-debuginfo. Then execute "gdb clementine" Then execute "run" and when you get the crash execute "bt" and post the backtrace you get. zypper in --from Clementine_Plater clementine clementine-debuginfo pulseaudio-debuginfo libpulse0-debuginfo Loading repository data... Reading installed packages... 'libpulse0-debuginfo' not found in package names. Trying capabilities. 'libpulse0-debuginfo' is already installed. 'pulseaudio-debuginfo' not found in package names. Trying capabilities. 'pulseaudio-debuginfo' is already installed. Resolving package dependencies... The following 2 packages are going to be upgraded: clementine clementine-debuginfo The following 2 packages are going to change vendor: clementine openSUSE -> obs://build.opensuse.org/home:plater clementine-debuginfo openSUSE -> obs://build.opensuse.org/home:plater 2 packages to upgrade, 2 to change vendor. gdb clementine ... Reading symbols from clementine... Reading symbols from /usr/lib/debug/usr/bin/clementine-1.3.1+git20190423-135.2.x86_64.debug... (gdb) run ... bt No stack. But why did you say, that one can ignore the AddressSanitizer messages? Isn't heap-use-after-free on address 0x612000739e40 at pc 0x555555aeca8c bp 0x7fffe4025060 sp 0x7fffe4025058 a sufficient error message? (In reply to Michael Hirmke from comment #19) > > But why did you say, that one can ignore the AddressSanitizer messages? > Isn't > heap-use-after-free on address 0x612000739e40 at pc 0x555555aeca8c bp > 0x7fffe4025060 sp 0x7fffe4025058 > a sufficient error message? Because it is not the reason for the crash, I have the same output on quit and no crash. This is why I enabled -fsanitize=address in the build. (In reply to Michael Hirmke from comment #19) > gdb clementine > ... > Reading symbols from clementine... > Reading symbols from > /usr/lib/debug/usr/bin/clementine-1.3.1+git20190423-135.2.x86_64.debug... > (gdb) run > ... > bt > No stack. > It seems that no stack is a result of stack corruption before the crash. I'm going to try find some breakpoints before the assert at pulsecore/fdsem.c:199 Can you please attach at least some of the console output which shows the songs actually playing in a file before the crash happens. So far I have no useful information and I can't reproduce the bug. pa_write() is not called by clementine. You mean the console output, when running clementine in the debugger? Created attachment 807685 [details]
log from clementine gdb session
#!/bin/sh
exec gdb -q >cl.log 2>&1 <<EOF
file clementine
run
bt
quit
EOF
There seem to be no information about played songs or something like that in the log. Should I run with --verbose? (In reply to Michael Hirmke from comment #24) > There seem to be no information about played songs or something like that in > the log. Should I run with --verbose? No this clementine outputs debug information when it's run without --verbose Meanwhile I've discovered that -fsanitize=address and gdb don't mix, that's why there's no backtrace. I'll notify you when clementine's finished building again and you can install. If you just run clementine without gdb meanwhile and post the console output it may help speed things up. clementine-1.3.1+git20190423-138.1 is published, you should be able to: "zypper in clementine* to update the program and debug packages and gdb should give a back trace. Created attachment 807691 [details]
log from latest clementine gdb session
This time we got a stack trace.
(In reply to Michael Hirmke from comment #27) > Created attachment 807691 [details] > log from latest clementine gdb session > > This time we got a stack trace. Try this command to set a break point where things start to go wrong : (gdb) b /usr/src/debug/pulseaudio-12.2-14.2.x86_64/src/pulse/mainloop.c:773 and post the back trace. Created attachment 807692 [details]
log from latest clementine gdb session with breakpoint
#!/bin/sh
exec gdb -q >cl.log 2>&1 <<EOF
file clementine
set breakpoint pending on
b /usr/src/debug/pulseaudio-12.2-14.2.x86_64/src/pulse/mainloop.c:773
run
bt
quit
EOF
Hope I did it the right way. (In reply to Michael Hirmke from comment #30) > Hope I did it the right way. You followed instructions perfectly, unfortunately your pulseaudio debug packages have a different release number: (gdb) (gdb) No source file named /usr/src/debug/pulseaudio-12.2-14.2.x86_64/src/pulse/mainloop.c. The breakpoint won't work then: Use find "/usr/src/debug/ -name mainloop.c" to get the correct path and execute: "(gdb) directory <enter the path from find without mainloop.c>" Then you only need to enter "(gdb) b mainloop.c:773" You should also run until the crash then "(gdb) ib" to check the breakpoint is: Num Type Disp Enb Address What 1 breakpoint keep y 0x00007ffff18821c0 in pa_mainloop_wakeup at pulse/mainloop.c:773 Under the Disp column it must not say pending at this stage. Then (gdb) run --verbose If it doesn't hit the breakpoint like your: log from "latest clementine gdb session with breakpoint" Try setting: "(gdb) b mainloop.c:771" It must at least get here otherwise something else has gone wrong. The breakpoint I gave you is the point in Comment 1 where it says: pa_write() failed while trying to wake up the mainloop: Bad file descriptor find /usr/src/debug/ -name mainloop.c /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c gdb ... (gdb) directory /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/ Source directories searched: /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse:$cdir:$cwd (gdb) b mainloop.c:773 No source file named mainloop.c. Make breakpoint pending on future shared library load? (y or [n]) y Breakpoint 1 (mainloop.c:773) pending. ... ??? (In reply to Michael Hirmke from comment #33) > find /usr/src/debug/ -name mainloop.c > /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c > > gdb > ... > (gdb) directory /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/ > Source directories searched: > /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse:$cdir:$cwd > (gdb) b mainloop.c:773 > No source file named mainloop.c. > Make breakpoint pending on future shared library load? (y or [n]) y > Breakpoint 1 (mainloop.c:773) pending. > ... > > ??? Don't understand the ??? but the debug symbols are only loaded when clementine is started. Hopefully it can reach the breakpoint and the back trace will show me what goes wrong. I've written the ??? because of this message: "No source file named mainloop.c." Because of this I get the same behaviour as before. (In reply to Michael Hirmke from comment #35) > I've written the ??? because of this message: > "No source file named mainloop.c." > Because of this I get the same behaviour as before. But the program never reaches this point: pa_write() failed while trying to wake up the mainloop: Bad file descriptor pa_write() failed while trying to wake up the mainloop: Bad file descriptor pa_write() failed while trying to wake up the mainloop: Bad file descriptor Invalid write to eventfd: Bad file descriptor Code should not be reached at pulsecore/fdsem.c:199, function pa_fdsem_post(). Aborting. Something else has gone wrong. Sorry, I don't understand what is going on here: ls -l /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c -rw-r--r-- 1 root root 21856 Jul 16 2018 /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c But: gdb) Reading symbols from clementine... Reading symbols from /usr/lib/debug/usr/bin/clementine-1.3.1+git20190423-138.2.x86_64.debug... (gdb) (gdb) No source file named /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c. Breakpoint 1 (/usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c:773) pending. (gdb) Starting program: /usr/bin/clementine Why does it refuse to use this source file? I tried a few things, but didn't succeed in providing you with a useful stacktrace 8-< gdb only reads the source files after you have given the run command. A good test breakpoint is: b /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c:771 gdb should stop on this before the gui, then set the mainloop:773 breakpoint and execute delete 1 to remove the mainloop:771 breakpoint. The first breakpoint you set will be pending the second one, after run will be accepted immediately. Please edit Clementine.conf and change the yes to no in these lines: [LibraryBackend] save_ratings_in_file=true save_statistics_in_file=true Change to: [LibraryBackend] save_ratings_in_file=false save_statistics_in_file=false It might make things easier. This way: #!/bin/sh exec gdb -q >cl.log 2>&1 <<EOF file clementine set breakpoint pending on b /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c:771 run b mainloop:773 delete 1 continue bt quit EOF ?? This gives: (gdb) Reading symbols from clementine... Reading symbols from /usr/lib/debug/usr/bin/clementine-1.3.1+git20190423-138.2.x86_64.debug... (gdb) (gdb) No source file named /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c. Breakpoint 1 (/usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c:771) pending. (gdb) Starting program: /usr/bin/clementine ... Thread 5 "Thread (pooled)" hit Breakpoint 1, pa_mainloop_wakeup (m=0x555557f538e0) at pulse/mainloop.c:771 771 if (pa_write(m->wakeup_pipe[1], &c, sizeof(c), &m->wakeup_pipe_type) < 0) (gdb) No source file named mainloop. Breakpoint 2 (mainloop:773) pending. (gdb) (gdb) Continuing. ... Still says "no source file". Besides that, with save_ratings_in_file=false save_statistics_in_file=false Clementine is now running for two hours without crashing. Stay tuned ... crashed again:
Thread 10 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe9c62700 (LWP 20156)]
0x00007ffff535edf8 in vtable for __cxxabiv1::__si_class_type_info () from /usr/lib64/libstdc++.so.6
(gdb) #0 0x00007ffff535edf8 in vtable for __cxxabiv1::__si_class_type_info () at /usr/lib64/libstdc++.so.6
#1 0x00005555558a43a1 in MessageReply<pb::tagreader::Message>::SetReply(pb::tagreader::Message const&)
(this=this@entry=0x555559216000, message=...) at /usr/include/qt5/QtCore/qdebug.h:125
#2 0x00005555558a44fd in AbstractMessageHandler<pb::tagreader::Message>::RawMessageArrived(QByteArray const&)
(this=this@entry=0x555556e5c600, data=...) at /usr/include/qt5/QtCore/qmap.h:276
#3 0x0000555555df19ff in _MessageHandlerBase::DeviceReadyRead() (this=0x555556e5c600)
at /usr/src/debug/clementine-1.3.1+git20190423-138.2.x86_64/ext/libclementine-common/core/messagehandler.cpp:76
#4 0x00007ffff77b0a18 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5
#5 0x00007ffff77b0a18 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5
#6 0x00007ffff7b35944 in () at /usr/lib64/libQt5Network.so.5
#7 0x00007ffff7b359db in () at /usr/lib64/libQt5Network.so.5
#8 0x00007ffff7b4a661 in () at /usr/lib64/libQt5Network.so.5
#9 0x00007ffff6ec1c32 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5
#10 0x00007ffff6ecaea0 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5
#11 0x00007ffff7785e92 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5
#12 0x00007ffff77dca05 in () at /usr/lib64/libQt5Core.so.5
#13 0x00007ffff6119b33 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
#14 0x00007ffff6119dc0 in () at /usr/lib64/libglib-2.0.so.0
#15 0x00007ffff6119e4f in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#16 0x00007ffff77dbe1b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
at /usr/lib64/libQt5Core.so.5
#17 0x00007ffff7784bdb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5
#18 0x00007ffff75c6751 in QThread::exec() () at /usr/lib64/libQt5Core.so.5
#19 0x00007ffff75c78d2 in () at /usr/lib64/libQt5Core.so.5
#20 0x00007ffff5aeefaa in start_thread () at /lib64/libpthread.so.0
#21 0x00007ffff4f6471f in clone () at /lib64/libc.so.6
(gdb) A debugging session is active.
Inferior 1 [process 20143] will be killed.
(In reply to Michael Hirmke from comment #40) > Besides that, with > > save_ratings_in_file=false > save_statistics_in_file=false > > Clementine is now running for two hours without crashing. > Stay tuned ... Maybe this is actually a duplicate of Robins Leap:15 bug - Bug 1138261, I can duplicate that bug in 15.1 but under Tumbleweed, on my laptop, clementine just keeps on running. This must be hardware related, my laptop is from mid 2018 but my pc is old. I've updated clementine will let you know when it's ready, something else is happening with clementine since we started. Along with everything else, post the output of "sudo dmidecode" Created attachment 808065 [details]
dmidecode output
No hardware problem, my laptop only has 4G ram and an i3 cpu. When did this problem start, sometime after 5 June? Do you have apple music files using aac codec in m4a containers or similar? Please check if the crash happens on specific songs. I'll inform you when you can update clementine. (In reply to Dave Plater from comment #44) > No hardware problem, my laptop only has 4G ram and an i3 cpu. > When did this problem start, sometime after 5 June? > > Do you have apple music files using aac codec in m4a containers or similar? > Please check if the crash happens on specific songs. > > I'll inform you when you can update clementine. I started using Clementine only a few weeks ago, because Amarok was dropped due to missing QT5 support. So I had the problem from the beginning. Mainly I have mp2, mp3, flac and ogg files. There are a few aac files, too, but when the crash occurs, only flac files are played. I've updated clementine, removed all the extra git patches and set it not to use the systems taglib. It's ready to install from home:plater I'm also looking at patching out the save statistics and ratings to the music files functions. I've never had it enabled in the past because I don't want clementine writing to my music. I really can't understand what it achieves anyway. Your new version crashed again:
(gdb) Reading symbols from clementine...
Reading symbols from /usr/lib/debug/usr/bin/clementine-1.3.1+git20190609-141.1.x86_64.debug...
(gdb) (gdb) No source file named /usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c.
Breakpoint 1 (/usr/src/debug/pulseaudio-12.2-5.4.x86_64/src/pulse/mainloop.c:771) pending.
(gdb) Starting program: /usr/bin/clementine --verbose
...
Thread 10 "QThread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe9d68700 (LWP 29216)]
0x00007ffff5464df8 in vtable for __cxxabiv1::__si_class_type_info () from /usr/lib64/libstdc++.so.6
(gdb) #0 0x00007ffff5464df8 in vtable for __cxxabiv1::__si_class_type_info () at /usr/lib64/libstdc++.so.6
#1 0x00005555558f2b11 in MessageReply<pb::tagreader::Message>::SetReply(pb::tagreader::Message const&)
(this=this@entry=0x555557d6e660, message=...) at /usr/include/qt5/QtCore/qdebug.h:125
#2 0x00005555558f2c6d in AbstractMessageHandler<pb::tagreader::Message>::RawMessageArrived(QByteArray const&)
(this=this@entry=0x555556ea60b0, data=...) at /usr/include/qt5/QtCore/qmap.h:276
#3 0x0000555555e3cc4f in _MessageHandlerBase::DeviceReadyRead() (this=0x555556ea60b0)
at /usr/src/debug/clementine-1.3.1+git20190609-141.1.x86_64/ext/libclementine-common/core/messagehandler.cpp:76
#4 0x00007ffff77b0a18 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5
#5 0x00007ffff77b0a18 in QMetaObject::activate(QObject*, int, int, void**) () at /usr/lib64/libQt5Core.so.5
#6 0x00007ffff7b35944 in () at /usr/lib64/libQt5Network.so.5
#7 0x00007ffff7b359db in () at /usr/lib64/libQt5Network.so.5
#8 0x00007ffff7b4a661 in () at /usr/lib64/libQt5Network.so.5
#9 0x00007ffff6ec1c32 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5
#10 0x00007ffff6ecaea0 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5
#11 0x00007ffff7785e92 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5
#12 0x00007ffff77dca05 in () at /usr/lib64/libQt5Core.so.5
#13 0x00007ffff6119b33 in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0
#14 0x00007ffff6119dc0 in () at /usr/lib64/libglib-2.0.so.0
#15 0x00007ffff6119e4f in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0
#16 0x00007ffff77dbe1b in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) ()
at /usr/lib64/libQt5Core.so.5
#17 0x00007ffff7784bdb in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5
#18 0x00007ffff75c6751 in QThread::exec() () at /usr/lib64/libQt5Core.so.5
#19 0x00007ffff75c78d2 in () at /usr/lib64/libQt5Core.so.5
#20 0x00007ffff5bf4faa in start_thread () at /lib64/libpthread.so.0
#21 0x00007ffff506a71f in clone () at /lib64/libc.so.6
(gdb) A debugging session is active.
Inferior 1 [process 29199] will be killed.
Does it crash with mp3 and ogg files or only flac? (In reply to Dave Plater from comment #48) > Does it crash with mp3 and ogg files or only flac? Also happens with at least mp3. Hey folks, It seems I'm getting the same behavior. I opened up a ticket with the Clementine issue tracker but I'm not sure if this would fall within their jurisdiction: https://github.com/clementine-player/Clementine/issues/6366 Some details: - OpenSuSE Tumbleweed with latest packages (zypper dup'd/up'd - A few packages I left as taboo to ensure they don't get updated, mostly to do with LVM2 and the kernel - long story) - Running Cinnamon from repos - Configuration file already has the following (always had- never had to change it from true to false): [LibraryBackend] save_ratings_in_file=false save_statistics_in_file=false - Clementine version: Information for package clementine: ----------------------------------- Repository : openSUSE-Tumbleweed-Oss Name : clementine Version : 1.3.1+git20190423-2.2 Arch : x86_64 Vendor : openSUSE Installed Size : 37.9 MiB Installed : Yes Status : up-to-date Source package : clementine-1.3.1+git20190423-2.2.src Let me know if there's anything else I could do to provide additional info/debugs/etc. Just be gentle- I'm still cutting my teeth on this whole bug reporting business. Any new status for this crash? It still happens with latest Tumbleweed snapshot - not astonishing, though, because Clementine still has version 1.3.1+git20190423. The latest version from your repo also is still crashing. (In reply to Michael Hirmke from comment #51) > Any new status for this crash? > It still happens with latest Tumbleweed snapshot - not astonishing, though, > because Clementine still has version 1.3.1+git20190423. > > The latest version from your repo also is still crashing. Is that "clementine-1.3.1+git20190609-146.1"? There isn't just one bug here we're dealing with three different crashes. (In reply to Dave Plater from comment #52) > (In reply to Michael Hirmke from comment #51) > > Any new status for this crash? > > It still happens with latest Tumbleweed snapshot - not astonishing, though, > > because Clementine still has version 1.3.1+git20190423. > > > > The latest version from your repo also is still crashing. > > Is that "clementine-1.3.1+git20190609-146.1"? > > There isn't just one bug here we're dealing with three different crashes. clementine-1.3.1+git20190609-146.1.x86_64 - yes. Would it be helpful, if I'd upload a certain flac somewhere, where Clementine is always crashing here? (In reply to Michael Hirmke from comment #54) > Would it be helpful, if I'd upload a certain flac somewhere, where > Clementine is always crashing here? Anything that can help me to duplicate the bug will help. (In reply to Dave Plater from comment #55) > (In reply to Michael Hirmke from comment #54) > > Would it be helpful, if I'd upload a certain flac somewhere, where > > Clementine is always crashing here? > > Anything that can help me to duplicate the bug will help. Any preferred location? (In reply to Michael Hirmke from comment #56) > Any preferred location? Compress it and attach it to the bug. (In reply to Dave Plater from comment #57) > (In reply to Michael Hirmke from comment #56) > > Any preferred location? > > Compress it and attach it to the bug. It is a flac - it can't be compressed much. And it has 33 MB! Not quite sure how it works but I have got access to google drive. I've bundled all my flacs together and will try playing only flacs. I see that my flacs have jpeg images and lyrics embedded in them, maybe it has something to do with that. "There isn't just one bug here we're dealing with three different crashes." Sorry- did I muddy the water by adding my two cents to the pot? Do I need to open a separate issue/ticket? The log output is very similar for me and Michael Hirmke, so I thought I would reply here. What makes it a separate crash? Although- I will point out that for me it seems to crash when I try and load/maximize the window itself, rather than when I play anything (flac or otherwise). Either way- let me know and I'll act accordingly. Besides your and my bug there were two others metioned in the mailing list. One of them has already been opened here on bugzilla. I guess, Dave meant them. But your bug indeed seems to be different from mine, so I would suggest to open a separate bug report for it. But wait for Dave's opinion on that. (In reply to Konrad Krzewinski from comment #60) > "There isn't just one bug here we're dealing with three different crashes." > > Sorry- did I muddy the water by adding my two cents to the pot? Do I need to > open a separate issue/ticket? Might as well address all the bugs here, the original fail in comment #1 seems to have gone away. > > The log output is very similar for me and Michael Hirmke, so I thought I > would reply here. > > What makes it a separate crash? > > Although- I will point out that for me it seems to crash when I try and > load/maximize the window itself, rather than when I play anything (flac or > otherwise). > > Either way- let me know and I'll act accordingly. I've spotted a clementine issue relating to a window resizing crash but I deleted the email I will look for it. If you have Tumbleweed then stay with this bug. I've had a bit of help in fixing some of the memory hog issues. A patched and updated clementine-1.3.1+git20190713-148.1 should fix some problems. I tested with only my 132 flac files and I am still unable to get a crash in Tumbleweed (In reply to Dave Plater from comment #63) > I've had a bit of help in fixing some of the memory hog issues. A patched > and updated clementine-1.3.1+git20190713-148.1 should fix some problems. > I tested with only my 132 flac files and I am still unable to get a crash in > Tumbleweed Still crashing - in even shorter intervals than before. Just installed the RPM from your home repo. It works like a charm. This fixed it. You magnificent person, you. I can maximize, minimize, and see the player without crashing. In addition, I've tested multiple things including playing .mp3, .wma and .flac tracks without any problems whatsoever. I imagine this is something that will be upstreamed into the regular Tumbleweed repos? Michael- are you sure you're not running into a codec issue? My buddy (some eons ago) had a similar problem which was causing some of his players to barf on him. (In reply to Konrad Krzewinski from comment #65) > Just installed the RPM from your home repo. It works like a charm. This > fixed it. You magnificent person, you. > > I can maximize, minimize, and see the player without crashing. > > In addition, I've tested multiple things including playing .mp3, .wma and > .flac tracks without any problems whatsoever. > > I imagine this is something that will be upstreamed into the regular > Tumbleweed repos? > > Michael- are you sure you're not running into a codec issue? My buddy (some > eons ago) had a similar problem which was causing some of his players to > barf on him. The window resize issue was fixed in the last git snapshot. (In reply to Konrad Krzewinski from comment #65) > Just installed the RPM from your home repo. It works like a charm. This > fixed it. You magnificent person, you. > > I can maximize, minimize, and see the player without crashing. > > In addition, I've tested multiple things including playing .mp3, .wma and > .flac tracks without any problems whatsoever. > > I imagine this is something that will be upstreamed into the regular > Tumbleweed repos? > > Michael- are you sure you're not running into a codec issue? My buddy (some > eons ago) had a similar problem which was causing some of his players to > barf on him. Can you get me two separate gdb back traces please and if possible at least the output of ffprobe on the music file that caused the crash. (In reply to Konrad Krzewinski from comment #65) [...] > Michael- are you sure you're not running into a codec issue? My buddy (some > eons ago) had a similar problem which was causing some of his players to > barf on him. The same files can be played with every other player besides Clementine - and I tried about 10 different players. (In reply to Dave Plater from comment #67) [...] > Can you get me two separate gdb back traces please and if possible at least > the output of ffprobe on the music file that caused the crash. Every other player can play these songs - Clementine is the only one to crash. I tried qmmp, amarok, elisa, cantata, musique, yarock, ... And with the latest version Clementine is crashing on about every second song, no matter if it is flac or mp3. I don't believe it has anything to do with the songs. I can create backtraces, but that's what I did before. What should I change, so that they would be more helpful than the ones before? I've grabbed a patch that limits the number of threads used by machines with lots of cores, this could be the reason why I can't get my laptop to crash at all. When it's published clementine-1.3.1+git20190713-154.1 contains the patch. The reason I've asked for more backtraces is because your original crash in Comment 1 seems to have disappeared. (In reply to Dave Plater from comment #70) > I've grabbed a patch that limits the number of threads used by machines with > lots of cores, this could be the reason why I can't get my laptop to crash > at all. > When it's published clementine-1.3.1+git20190713-154.1 contains the patch. > > The reason I've asked for more backtraces is because your original crash in > Comment 1 seems to have disappeared. Oops. I see all attachements as "log from ...". They are containing the crash information. But if you need more dumps, I can provide them. There are enough crashes left over :) clementine-1.3.1+git20190713-155.1 with the upstream patch from Comment 72 is built in my home repo, hopefully it will solve this bug. (In reply to Dave Plater from comment #73) > clementine-1.3.1+git20190713-155.1 with the upstream patch from Comment 72 > is built in my home repo, hopefully it will solve this bug. No more chrashes since installation of this version yesterday. Thx a lot! If I don't get crashes the next two days, I'll close the bug as fixed. Is this ok for you? Is it the intended behaviour, that notifications don't show covers any longer? Covers are shown in the main windows, though. No, but that's unrelated to my fix (In reply to Jonas Kvinge from comment #76) > No, but that's unrelated to my fix Ok. (In reply to Michael Hirmke from comment #77) > (In reply to Jonas Kvinge from comment #76) > > No, but that's unrelated to my fix > > Ok. Found the appropriate option - now notifications are showing album art again. I will submit to Factory when I've updated the changes file, there are also fresh memory leak fixes from Bug 1141444 loaded this morning. This is an autogenerated message for OBS integration: This bug (1137785) was mentioned in https://build.opensuse.org/request/show/717812 Factory / clementine The fix is in Factory and should be in the next snapshot. No crashes in the last days. Closing the bug as fixed. Thx again! |