Description of problem: Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Sorry ... too quick on the buttons :) Description Easytag will crash when adding cover art. Version: rpm -qa | grep easytag easytag-2.2.0-1.fc20.x86_64 How reproducible: Crashes every time I add cover art to an album that doesnt have any artwork Steps to reproduce: 1. Open easytag, and choose an album that doesnt have any cover art 2. Attempt to add cover art Actual results: Easytag crashes with: process 16282: arguments to dbus_message_unref() were incorrect, assertion "message->generation == _dbus_current_generation" failed in file dbus-message.c line 1617. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Aborted
I guess I should add that these are MP3 files that have been generated by ripping an album using sound juicer.
Can you get a stack trace of the crash and attach it to this report?
GDB gives Missing separate debuginfos, use: debuginfo-install easytag-2.2.0-1.fc20.x86_64 (gdb) run Starting program: /usr/bin/easytag Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3800.2-gdb.py", line 9, in <module> from gobject import register File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module> import gdb.backtrace ImportError: No module named backtrace Traceback (most recent call last): File "/usr/share/gdb/auto-load/usr/lib64/libgobject-2.0.so.0.3800.2-gdb.py", line 9, in <module> from gobject import register File "/usr/share/glib-2.0/gdb/gobject.py", line 3, in <module> import gdb.backtrace ImportError: No module named backtrace [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". [New Thread 0x7ffff7fa0700 (LWP 20677)] [New Thread 0x7fffe2f3a700 (LWP 20678)] [New Thread 0x7fffe251c700 (LWP 20681)] [New Thread 0x7fffe190c700 (LWP 20682)] [New Thread 0x7fffe110b700 (LWP 20683)] [New Thread 0x7fffe090a700 (LWP 20684)] [Thread 0x7fffe110b700 (LWP 20683) exited] [Thread 0x7fffe251c700 (LWP 20681) exited] [New Thread 0x7fffe251c700 (LWP 20688)] process 20673: Array or variant type requires that type struct be written, but object_path was written. The overall signature expected here was 'lP' and we are on byte 26 of that signature. D-Bus not built with -rdynamic so unable to print a backtrace Program received signal SIGABRT, Aborted. 0x000000358e435c39 in raise () from /lib64/libc.so.6 (I can install the debuginfo versions of the packages, but this will take some time since there is almost 2G to download, since it pulls in all the gcc debug packages)
Some more information: If I select a single track from the album, I can load the cover art for that single track and then select all the tracks and apply the cover art to all tracks. If, however, I select all the tracks first and then attempt to load the cover art, easytag will display the file chooser to let me attempt to load an image, but when I select the image and click on 'open' then easytag will crash. This is a change in behaviour from the unofficial version that was in the COPR repository.
I do not seem able to reproduce the crash. If you file the crash report using ABRT, you should not need to download the debug symbols. Please try doing that, and if it does not work, get a stack trace after installing the debug symbols.
I came across a couple of cover art crashes in the retrace server: https://retrace.fedoraproject.org/faf/problems/1661056/ https://retrace.fedoraproject.org/faf/problems/1662964/ They both seems to be triggered when adding cover art. I will look into both crashes over the next few days.
This might be fixed by the 2.2.1-1 update that is heading to F20 and F19: https://admin.fedoraproject.org/updates/easytag-2.2.1-1.fc20 Can you try that and see whether it fixes the crash? If not, a stack trace of the crash would be very useful.
*** This bug has been marked as a duplicate of bug 1092814 ***